1 / 38

Replication with MySQL 5.1

<Insert Picture Here>. Replication with MySQL 5.1. Ligaya Turmelle Senior Technical Support Engineer - MySQL ligaya.turmelle@oracle.com http://joind.in/1573. <Insert Picture Here>. Agenda. What it is How it Works Types Use Cases Setting it up Filtering Rules Monitoring.

kassia
Download Presentation

Replication with MySQL 5.1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. <Insert Picture Here> Replication with MySQL 5.1 • Ligaya Turmelle • Senior Technical Support Engineer - MySQL • ligaya.turmelle@oracle.com • http://joind.in/1573

  2. <Insert Picture Here> Agenda • What it is • How it Works • Types • Use Cases • Setting it up • Filtering Rules • Monitoring

  3. <Insert Picture Here> What is it?

  4. <Insert Picture Here> How does it work?

  5. At a high level • On the master • makes a change to the data • writes it to the binary log • On the slave • copies the masters binary logs to the relay logs • runs the relay logs applying the changes

  6. Nitty Gritty of Master Side • Master makes a change and writes the binlog entry • Details: • it writes the the changes to the binary log • writes the transactions serially • After writing to the binary log, the master tells the storage engine to commit the transaction.

  7. Enter the Slave IO thread • Slave creates an I/O thread which connects to the master • Slave connects to the master just like any other client then starts a binlog dump process • Master then creates a thread to send the binary log contents to a slave when the slave connects • Slave IO thread writes the binary log events to the slaves relay log • Once slave catches up with master, IO thread goes to sleep and waits for the master to signal it has new events

  8. Slave SQL Thread • Separates the actual execution of the binary log events from the retrieval of it on the master • Read and replays the events from the relay log • updates the slaves data to match the masters • Has all privileges so it can run any query that is sent • potential bottleneck

  9. <Insert Picture Here> Types

  10. Basic Info • 3 binary log formats: • Statement Based Replication (SBR) • Row Based Replication (RBR) • Mixed • The format of the binary log has no relevance to how the slave handles it. The SQL thread on the slave can and will handle any binary log format given to it • controlled by setting the binlog_format • each format has its pros and cons

  11. Statement Based Replication (SBR) • Been used by all previous versions of replication • Pros: • Proven • Less data written to log files. • Can be used for audit purposes • Cons: • Some statements are unsafe • Any nondeterministic behavior is difficult to replicate • More locking may be needed then Row Based • Complex statements will have to be evaluated and executed • Deterministic UDFs must be applied on the slaves • InnoDB: INSERT statement using AUTO_INCREMENT blocks other nonconflicting INSERT statements.

  12. Row Based Replication (RBR) • Replicates only the changed rows • Pros: • All changes can be replicated • Safest form • Same as most other RDBMS • Fewer locks required • Cons: • Generally more data to be logged • Some problems with older versions but fixed now • large BLOBs can take longer to replicate

  13. Mixed Replication • Uses both SBR and RBR • Statement-based logging is used by default • Automatically switches to row-based logging in particular cases • http://dev.mysql.com/doc/refman/5.1/en/binary-log-mixed.html • Can provide best of both worlds - but requires testing

  14. <Insert Picture Here> Use Cases

  15. ScaleOut • Very common use case • Scale out load to multiple servers • Reads can be sent to slaves • Writes are done on the Master • Good for high read workloads • Some improvement to writes if Master only writes

  16. Data Redundancy • Another common usage • backups • Failover • Use as a testing system • test queries • application interaction • Use different storage engine abilities

  17. Analytics • Reporting • different queries • long running • locking • caches • DBA can query to learn about their data • distribution • trends

  18. Long Distance Data Distribution • Geographically separate locations • disaster recovery • Office wants to work on a local copy

  19. <Insert Picture Here> Setting it up

  20. Setting up Replication • On the Master config file, need to add • log-bin=mysql_bin • server_id=1 • On the Slave config file, need to add • server_id=2 • Create the Replication User • requires REPLICATION SLAVE privilege mysql> CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass'; mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.mydomain.com';

  21. Setting up Replication (con’t) • Get from Master • Obtain master server binary log coordinates • mysql> FLUSH TABLES WITH READ LOCK; • mysql> SHOW MASTER STATUS; • Copy the master (if not a new master) • mysqldump or binary copy • Finally ready! Actual steps for a new setup: • Configure Master; (re)start Master • Set up Replication User on Master • Get Master status • Release read locks on Master • Configure Slave; (re)start Slave • Execute CHANGE MASTER TO statement

  22. mysql> CHANGE MASTER TO -> MASTER_HOST='master_host_name', -> MASTER_USER='replication_user_name', -> MASTER_PASSWORD='replication_password', -> [MASTER_PORT = port_num,] -> MASTER_LOG_FILE='recorded_log_file_name', -> MASTER_LOG_POS=recorded_log_position, -> [MASTER_SSL = {0|1},] -> [MASTER_SSL_CA = 'ca_file_name',] -> [MASTER_SSL_CAPATH = 'ca_directory_name',] -> [MASTER_SSL_CERT = 'cert_file_name',] -> [MASTER_SSL_KEY = 'key_file_name',] -> [MASTER_SSL_CIPHER = 'cipher_list',] -> [MASTER_SSL_VERIFY_SERVER_CERT = {0|1}] ;

  23. <Insert Picture Here> Filtering rules

  24. Filtering Rule Basics • 2 levels of filtering • On the Master • Not recommended • On the slave • preferred • Can be confusing

  25. Filtering on the Master • How it works: • binlog-do-db • binlog-ignore-db • Not recommended - ever! • Reasons: • audit • point in time recovery • crash recovery

  26. Filtering on the Slave • How it works: • replicate-do-db • replicate-ignore-db • replicate-do-table • replicate-ignore-table • replicate-wild-do-table • replicate-wild-ignore-table • Avoid mixing “do” and “ignore” command • Avoid mixing wildcard and nonwildcard options • First checks DB level filtering and only if no matches moves on to the table level matching

  27. Database Filters

  28. Table Filters 1 For each statement that performs an update.. Statement Start (Following DB options) Any replicate-*-table options? Which logging format? Yes No Row For each update of a table row... execute UPDATE and Exit

  29. Table Filters 2 (do/ignore) Does the table match any of them? Any replicate-do-table options? Yes Yes execute UPDATE and Exit No No Any replicate-ignore-table options? Does the table match any of them? Yes Yes ignore UPDATE and Exit No No

  30. Table Filters 3 (wild do/wild ignore) Does the table match any of them? Any replicate-wild-do-table options? Yes Yes execute UPDATE and Exit No No Any replicate-wild-ignore-table options? Does the table match any of them? Yes Yes ignore UPDATE and Exit No No

  31. Table Filters 4 Is there another table to be tested? Yes No Any replicate-do-table or replicate-wild-do-table options? ignore UPDATE and Exit Yes No execute UPDATE and Exit

  32. <Insert Picture Here> Monitoring

  33. On the Master mysql> SHOW MASTER STATUS; +---------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +---------------+----------+--------------+------------------+ | mysql-bin.003 | 73 | test | manual,mysql | +---------------+----------+--------------+------------------+ mysql> SHOW BINARY LOGS; +---------------+-----------+ | Log_name | File_size | +---------------+-----------+ | binlog.000015 | 724935 | | binlog.000016 | 733481 | +---------------+-----------+ • Not much info here • Provides the File and Position • Shows any filtering being done on the master • Lists the binary logs on the server

  34. On the Slave mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: localhost Master_User: root Master_Port: 3306 Connect_Retry: 3 Master_Log_File: gbichot-bin.005 Read_Master_Log_Pos: 79 Relay_Log_File: gbichot-relay-bin.005 Relay_Log_Pos: 548 Relay_Master_Log_File: gbichot-bin.005 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table:

  35. On the Slave Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 79 Relay_Log_Space: 552 Until_Condition: None Until_Log_File: Last_SQL_Error: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 8 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error:

  36. <Insert Picture Here> Questions?

More Related