2. Baruch osoveskiy
Senior Consultant in dbaces.com
Linux-Unix SYSADMIN form 1997
DBA on Oracle and MySQL Since 2000
Working with unstructured Data (“big data”)
since 2000 like text and spatial
3. Oracle and Microsoft Partners
Oracle Aces and Ace Directors
What we do
◦ Remote DBA services
◦ Database consulting and projects
◦ Oracle identity and access management
◦ Training
Platforms
◦ Oracle DB
◦ Microsoft SQL Server
◦ MySQL
◦ PostgreSQL
4.
5. One webinar each week
Webinar recording will be available on site a few
days after webinar
Check our webinars schedule @
http://www.dbaces.com/training/upcoming-webinars
subscribe to get updates @ www.dbaces.com
6. MySQL replication Introduction
New features in MySQL 5.6 replication
How to Create MySQL replication with hot-
backups
How To monitor MySQL replication
9. • High availability – can promote
slave to master
• Scale Out – add multiple read slaves
• Analytics – can run Analytics on live
data.
• Backup – run cold backup on slave.
• For DEV and Pre-Prod
10. Replication Formats
• SBR - Statement Based Replication
• Nondeterministic function problem
• RBR - Row Based Replication
• High network usage
• Higher IO usage
• Mixed Mode
11. Not safe Nondeterministic function
FOUND_ROWS(), GET_LOCK(), IS_FREE_LOCK(),
IS_USED_LOCK(), LOAD_FILE(),
MASTER_POS_WAIT(), RELEASE_LOCK(),
ROW_COUNT(), SESSION_USER(), SLEEP(),
SYSDATE(), SYSTEM_USER(), USER(), UUID(),
and UUID_SHORT().
12. Where the Changes Stored
• Binary Log – Master (blue-bin.000002)
• Relay Log – Slave (white-relay-bin.000003)
27. Pros
• data integrity
• Commit ensure the transaction will copy to
slave
Cons
• Performance Implications
• The transaction need to Wait for the slave to
commit
• Problematic in high DML load
28. What's New
• Multi threaded Slave
• Relay log recovery
• Binary Log Group Commit
• Crash-safe Replication – Binlog Checksums
• Global Transaction ID
You can read more in:
http://dev.mysql.com/tech-resources/articles/whats-new-in-mysql-5.6.html
29. Replication performance is improved by using
multiple execution threads to apply replication
events
slave-parallel-workers=2
You can read more in:
http://dev.mysql.com/tech-resources/articles/whats-new-in-mysql-5.6.html
30. • slave can automatically recover from a failure and
resume replicating DML updates
• the slave can roll back replication to the last
successfully committed transaction
relay-log-recovery =1
You can read more in:
http://dev.mysql.com/tech-resources/articles/whats-new-in-mysql-5.6.html
And in
Bug #13893363
31. • Commit a group of transactions to the binary log.
• Ensures durability with good performance.
• Designed to handle seamlessly temporary peeks
on the workload.
enable by default in 5.6
You can read more in:
http://dev.mysql.com/tech-resources/articles/whats-new-in-mysql-5.6.html
32.
33. Master and slave can have different data
• Non deterministic queries.
• Wrong use of replication filters.
• Write executed on slave outside the.
replication (slave is not read only)
• Binlogs or relay log corruption.
34. How to check ?
Before 5.6 you can use only :
• show slave status
• pt-table-checksum
• utilty from precona that can check table
checksum
35. • First enable checksum on the master
binlog_checksum = CRC32;
master_verify_checksum = on;
• Then start binlog verify on the slave
slave_sql_verify_checksum = on;
* From >= 5.6.6 enable by default
36. mysql> show slave status
…
Last_Error : 1538
Last_Error : relay log read error……
…..
# mysqlbinlog --verify-binlog-checksum mysql_18676-relay-bin.000002
[...]
ERROR: Error in Log_event::read_log_event(): 'Event crc check failed!
Most likely there is event corruption.', data_len: 103, event_type: 2
ERROR: Could not read entry at offset 283: Error in log format or read
error.
[...]
37. Pros
• Can help to find error in the bin log/relay log
• Notify on a bin log corruption
Cons
• More CPU for the CRC
• The MySQL will keep writing to the corrupt bin log
38.
39. • Transactions are not guaranteed to execute in
the order of the Binary logs
• The show slave status is not accurate
41. • The same event can have different Binary log file
and position on different slaves
• Hard to find inconsistency in replication
• Very problematic to reconfigure replication
42. • Unique identifier of a transaction across all servers in
replication topology
The GTID look like :
GTID = source_id:transaction_id
Where
transaction_id = transaction_start-transaction_stop
eg :
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
44. How to enable GUID on MySQL replication
• Enable read only mode on Slaves
set global read_only=1
• Compare the binlog position on master and slave
show slave status
show master status
• Change configuration on all servers and restart
bin-log
guid_mode=ON
Enforce-guid-consistency
• Initialize GUID on all servers
change master to MASTER_AUTO_POSITION = 1;
• Disable read only mode on Slaves
52. we need to create the replication user on master
mysql> GRANT REPLICATION SLAVE ON *.* TO
replication@192.168.1.111 IDENTIFIED BY 'reppwd';
FLUSH PRIVILEGES;
53. create Hot backup with * Oracle Enterprise Backup
#mysqlbackup --port=3306 --protocol=tcp --
user=root --password --backup-dir=/data/backup
backup-and-apply-log
* Also can use Percona XtraBackup
54. • copy the backup directory to the slave via scp or
other method
on the master:
#tar –cvfZ /data/backup.taz /data/backup
#scp /data/backup.taz 192.168.1.111:/data/
on the slave:
#tar –xvfZ /data/backup.taz
55. • Start the Slave
#service start mysql
• Start the replication process that will start the
io_Thread and the sql_Thread
mysql>CHANGE MASTER TO
MASTER_HOST='192.168.1.110',
MASTER_USER='replication',
MASTER_PASSWORD='reppwd',
MASTER_AUTO_POSITION=1;
START SLAVE;
