Your SlideShare is downloading. ×
Download presentation
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Download presentation


Published on

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Reliable MySQL Using Replication Issac Goldstand Mirimar Networks [email_address]
  • 2. What is replication?
    • Allows 2 or more databases to maintain state between them
    • MySQL 3.23 and up supports asynchronous replication
    • One server acts as a master for one or more slaves
    • Slaves pull data to be replicated from server’s binary logs and execute the relevant statements locally
  • 3. Replication basics…
    • One master supports multiple slaves
    • Each node on the network is assigned a unique identifying number
    • Each slave attempts to connect to the master and fetches data to be replicated
    Master Slave Slave Slave Slaves
  • 4. Replication basics…
    • Clients perform data modification on master server
    • EXECUTE in MySQL 5.0 and above
    DATA DATA INSERT INTO … Master Slave Client
  • 5. Replication basics…
    • Immediately following execution of command on master, the command is written to the local binary log
    • Additionally, the master records its unique ID (to prevent endless loops in circular replication scenarios) and the timestamp for use with statements which use NOW(), etc.
    DATA DATA INSERT INTO … Binary Log Master Slave Client
  • 6. Replication basics…
    • If the slave is online, the command is transmitted to the slave in parallel (well, immediately following) to being written in the local binary log
    • Otherwise, when the slave next connects it will receive a list of all pending statements from the master server’s binary log
    • The slave’s replication IO thread stores the command in the local relay log
    DATA DATA INSERT INTO … INSERT INTO … Relay Log Replication Thread Master Slave Client
  • 7. Replication basics…
    • Once the data is received in the slave’s relay log, the slave SQL thread executes the command locally, bringing the slave up-to-date with the master
    • In MySQL 3.23, the IO and SQL threads were just one thread. In later versions this was changed to boost performance
    DATA DATA INSERT INTO … INSERT INTO … Relay Log Replication Thread DATA Master Slave Client
  • 8. Replication Strategies
    • Load balancing – single write, distributed read
    Master Slave Slave Slave Client (SELECT) Client (SELECT) Client (SELECT) Client (SELECT) Client (SELECT) Client (SELECT) Client (INSERT)
  • 9. Replication Strategies
    • Load balancing – single write, distributed read
    • Load balancing – circular read/write
    MySQL Server MySQL Server MySQL Server Client INSERT INTO… INSERT INTO … Client
  • 10. Replication Strategies
    • Load balancing – single write, distributed read
    • Load balancing – circular read/write
    • High availability (hot failover)
    DATA DATA DATA DATA DATA Client Master Slave
  • 11. Replication Strategies
    • Load balancing – single write, distributed read
    • Load balancing – circular read/write
    • High availability (hot failover)
    • Snapshot backups
    Master Slave Backup with LOCK TABLES (or single transaction) Client INSERT / SELECT Client INSERT / SELECT
  • 12. Simple Replication Setup
    • Modify my.cnf to include a unique server-id for each node
    • On master server, ensure that log-bin (binary logging) is enabled in my.cnf
    • On slave, configure login credentials on master, either via my.cnf or CHANGE MASTER TO statement
    • Copy initial data snapshot from master to slave
    • Configure initial binary log position on slave
    • Start replication with SLAVE START command
  • 13. Configure master my.cnf ------------- [mysqld] server-id = 1 log-bin
  • 14. Configure slave my.cnf ------------- [mysqld] server-id = 2 master-user = someuser master-password = secret master-host = ip.of.master
  • 15. Initial dataset
    • Binary log provides a record of all modifications to master database starting from a fixed point: when binary logging was activated
    • If all binary logs exist on master from initial install of MySQL, the slave(s) can use these to bring themselves up-to-date
    • Otherwise, a snapshot of the master must be taken, using mysqldump –master-data , to provide an initial dataset for the slave(s)
    • If only MyISAM tables are used, the LOAD DATA FROM MASTER statement may be used on the slave(s)
  • 16. Configure log position MASTER mysql> SHOW MASTER STATUS; +---------------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +---------------------------+----------+--------------+------------------+ | vmware-mirimar-bin.000002 | 79 | | | +---------------------------+----------+--------------+------------------+ SLAVE mysql> CHANGE MASTER TO MASTER_LOG_FILE=‘ vmware-mirimar-bin.000002 ’, MASTER_LOG_POS= 79 ; SLAVE mysql> START SLAVE;
  • 17. Using CHANGE MASTER TO
  • 18. Advanced CHANGE MASTER TO
  • 19. Confirming it works SLAVE mysql> SHOW SLAVE STATUSG *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: vmware-mirimar Master_User: someuser Master_Port: 3306 Connect_Retry: 60 Master_Log_File: vmware-mirimar-bin.000002 Read_Master_Log_Pos: 79 Relay_Log_File: vmware1-mirimar-relay-bin.000002 Relay_Log_Pos: 250 Relay_Master_Log_File: vmware-mirimar-bin.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 79 Relay_Log_Space: 250 Seconds_Behind_Master: 0
  • 20. Permissions
    • Slaves need REPLICATION SLAVE permission on master for basic usage
    • If LOAD TABLE FROM MASTER or LOAD DATA FROM MASTER statements are used, slave will also need SUPER and RELOAD privileges
  • 21. Internal Threads
    • Since MySQL 4.0, replication slaves run two threads
    • IO thread continuously receives updates from master and writes to local relay log
    • SQL thread continuously executes statements in relay log
  • 22. IO thread isolation
    • Isolating IO thread means that slave won’t have to wait for long-executing statements to finish executing before retrieving data from master
    • Also, slave will continue reading data from master if a statement creates a data conflict
  • 23. SQL thread isolation
    • SQL thread isolation allows for replication in an environment without a continuous link between slave and masters
    • If master fails (or slave simply has no access), the IO thread will try to reconnect endlessly (waiting 60 seconds between attempts)
    • SQL thread will continue processing relay logs even while IO thread is unable to connect to master
  • 24. Master Thread
    • Additionally, the master server runs the Binlog Dump thread
    • This thread is simply dedicated to scanning the binary logs on the master and sending updates to the connected slave
    • If this thread isn’t running, it means that replication isn’t running – more accurately, that no slaves are currently connected
  • 25. Status files
    • 2 status files for replication’s use
    • Their use is to record the state of replication between server shutdown and startup
    • records information about the slave’s master server
    • records information about the local relay logs
  • 26. Information in
    • Master log file
    • Read master log pos
    • Master Host
    • Master User
    • Password (will not be shown in SHOW SLAVE STATUS)
    • Master Port
    • Connect Retry
    • In MySQL 4.1+, SSL options are stored if SSL is used
  • 27. Information in
    • Relay log file
    • Relay log pos
    • Relay master-log pos
    • Exec master-log pos
  • 28. Backup master
    • Master backups can be accomplished with mysqldump
    • Care must be taken to ensure the following 2 special considerations:
      • Consistent snapshot of master date (via lock tables for MyISAM or single transaction for InnoDB)
      • Recording of binary log information, for use on slaves (master-data)
  • 29. Backup master files
    • If a file-system level backup is required, care should be taken to manually record binary log name and position via SHOW MASTER STATUS statement.
    • To ensure consistency between backup and binary log position, the tables should be locked via FLUSH TABLES WITH READ LOCK immediately before backup (and SHOW MASTER STATUS)
    • After backup finishes, execute UNLOCK TABLES to release the read lock
  • 30. Backup slave
    • Same idea as master file system backup
    • Instead of recording position, it’s enough to backup the and files
    • Instead of acquiring global read lock, it’s enough to STOP SLAVE before backup and START SLAVE once backup finishes
  • 31. Live demo
    • Time permitting, we’ll show a short demonstration of a simple unidirectional replication setup
  • 32. For more information
    • MySQL documentation
    • 5.0 documentation
    • 4.1 documentation
  • 33. Thank You! For more information: Issac Goldstand