This document provides information about Baruch Osoveskiy and the services offered by dbaces.com. Baruch is a senior consultant and DBA with over 15 years of experience working with Linux, Oracle, MySQL, and unstructured data. Dbaces provides remote DBA services, consulting, training, and support for Oracle, Microsoft SQL Server, MySQL, and PostgreSQL. They host weekly webinars on database topics and offer replication monitoring and configuration services for MySQL databases.

1. baruch osoveskiy
baruch@dbaces.com

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

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

7. Master SlaveNETWORK

8. Master SlaveNETWORK
Slave
Slave
Slave
Slave

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)

13. Replication Threads
• Master Server
• Binlog Dump Thread
• Slave Server
• IO Thread
• SQL Thread

14. Method of Sending the Data (Replication Type)
• Asynchronous Replication
• Semi-Synchronous Replication (5.5 )

15. Master
TRX1
TRX2
TRX3
.
Slave
1
Binary
log
DML
+
COMMIT
Binlog Dump Thread

16. Master
TRX1
TRX2
TRX3
.
Slave
1
2
Binary
log
IO Thread
DML
+
COMMIT

17. Master
TRX1
TRX2
TRX3
.
Slave
TRX1
TRX2
TRX3
.
1
2
3
Binary
log
Relay
Log
IO Thread
DML
+
COMMIT

18. Master
TRX1
TRX2
TRX3
.
Slave
TRX1
TRX2
TRX3
.
1
2
3
4
Binary
log
Relay
Log
IO Thread
SQL Thread
DML
+
COMMIT

19. Master
TRX1
TRX2
TRX3
.
Slave
TRX1
TRX2
TRX3
.
1
2
3
4
5
Binary
log
Relay
Log
IO Thread
SQL Thread
DML
+
COMMIT

20. Pros
• Fast
• slave can be disconnected
Cons
• Potential loss of transactions and data integrity

21. Master
TRX1
TRX2
TRX3
.
Slave
1
Binary
log
DML
Binlog Dump Thread

22. Master
TRX1
TRX2
TRX3
.
Slave
1
Binary
log
DML
IO Thread

23. Master
TRX1
TRX2
TRX3
.
Slave
1
Binary
log
DML
IO Thread
2
3
4
IO Thread
TRX1
TRX2
TRX3
.
Relay
Log

24. Master
TRX1
TRX2
TRX3
.
Slave
TRX1
TRX2
TRX3
.
1
2
3
4
Binary
log
Relay
Log
IO Thread
IO Thread
DML

25. Master
TRX1
TRX2
TRX3
.
Slave
TRX1
TRX2
TRX3
.
1
2
3
4
Binary
log
Relay
Log
IO Thread
IO Thread
DML
COMMIT

26. Master
TRX1
TRX2
TRX3
.
Slave
TRX1
TRX2
TRX3
.
1
2
3
4
Binary
log
Relay
Log
IO Thread
IO Thread
DML
COMMIT
5SQL Thread

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

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

39. • Transactions are not guaranteed to execute in
the order of the Binary logs
• The show slave status is not accurate

40. Master
Slave
1
Slave
2
Binlog
File:mysql-bin.0010
Position:1238574
Binlog
File:mysql-bin.0020
Position:1043
Binlog
File:mysql-bin.0140
Position:8373

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

43. Master
Slave
1
Slave
2
Binlog
File:mysql-bin.0010
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
Binlog
File:mysql-bin.0020
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
Binlog
File:mysql-bin.0140
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

46. Master
Blue
192.168.1.110
Slave
White
192.168.1.111

47. Master
Blue
192.168.1.110
Slave
White
192.168.1.111
Data files
from
Master
Blue
TRX1
TRX2
TRX3
.
Binary
log

48. Master
Blue
192.168.1.110
Slave
White
192.168.1.111
Replication

49. blue.my.cnf
[mysqld]
...
server-id=1
report-host=blue
binlog-format=MIXED
log-bin
log-slave-updates=true
gtid-mode=on
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
binlog-checksum=CRC32
master-verify-checksum=1

50. white.my.cnf
[mysqld]
...
server-id=2
report-host=white
binlog-format=MIXED
log-slave-updates=true
log-bin
gtid-mode=on
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1

51. On Master:
[mysqld]
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000 # 1 second
On each Slave:
[mysqld]
rpl_semi_sync_slave_enabled=1

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;

56. show slave statusG
*************************** 1. row********
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.110
Master_User: replication
Master_Log_File: blue-bin.000002
Read_Master_Log_Pos: 936
Relay_Log_File: white-relay-bin.000003
Relay_Log_Pos: 1146
Relay_Master_Log_File: blue-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

57. show slave statusG
*************************** 1. row********
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Master_UUID: 2671c08b-7cf0-11e2-ac39-00163ebee7c2
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log;
waiting for the slave I/O thread to update it
Retrieved_Gtid_Set: 2671c08b-7cf0-11e2-ac39-00163ebee7c2:1-4
Executed_Gtid_Set: 2671c08b-7cf0-11e2-ac39-00163ebee7c2:1-4

59. baruch@dbaces.com