• Save
MySQL 5.1 Replication
Upcoming SlideShare
Loading in...5
×
 

MySQL 5.1 Replication

on

  • 6,170 views

 

Statistics

Views

Total Views
6,170
Views on SlideShare
5,981
Embed Views
189

Actions

Likes
14
Downloads
0
Comments
0

17 Embeds 189

http://192.168.1.4 48
http://nomyself.info 24
http://randomwrites.com 23
http://www.technicaltunes.com 21
http://www.slideshare.net 19
http://jamyy.dyndns.org 19
http://178.79.146.129 13
http://192.168.1.178 5
http://www.randomwrites.com 5
http://learn.thruhere.net 4
http://mutahir.me 2
http://192.168.1.220 1
http://192.168.1.68 1
http://www.linkedin.com 1
http://192.168.1.3 1
http://www.lmodules.com 1
http://mail.myvspherelab.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • - Replication is the concept of taking data from one machine and copying it over to one or more separate machines. - Why would we want that? It can be used for a multitude of tasks including as part of a foundation to build larger high performance systems, keeping a “hot” spare of your server, provide a place to generated backups away from the production system, providing a development area with real data .
  • -
  • Who knows what the binary log is? Who knows what the relay log is? Replication is based on - master server keeping track of all changes in its binary log. - binary log serves as a written record of all events that modify database structure or content (data) - relay log is a log kept on the slave that consists of the events read from the binary log of the master. - implementation is one-way, asynchronous. * slaves pull the information from the master * they do not have to be connected to the master all the time. So updates can occur over long-distance connections and even over temporary or intermittent connections such as a dial-up service. Not too bad. pretty easy to understand. But each step is actually multiple complex steps.
  • bullet 1 sub-bullet 1: Right before a transaction on the master that alters data commits... bullet 1 sub-bullet 1 sub-sub-bullet 2: even if the transactions are interwoven on the master during execution - Can you see any problems with this? Potentially you could have a binary log entry written but never run on the master... How? (Answer: server crash between the writing to the binary log and the commit of the transaction. When the server comes back up the transaction will be rolled back, even though it is already in the binary log. Potential to get master/slave out of sync. )
  • Slave pulls the data from the master, rather than the master pushing the data to the slave. This will happen for each slave. bullet 1: The state of this thread is shown as Slave_IO_running in the output of SHOW SLAVE STATUS or as Slave_running in the output of SHOW STATUS. bullet 3: thread identified in the output of SHOW PROCESSLIST on the master as the Bin log Dump thread. It acquires a lock on the master's binary log for reading each event that is to be sent to the slave. As soon as the event has been read, the lock is released, even before the event is sent to the slave.
  • bullet 4: need to know about this for security concerns. If it makes it into the relay log - it will happen. bullet 5: master server can be writing to the binary log with N threads (parallel) but the slave only has the one thread to repeat all the commands done on the master (serial). Slave should be more powerful then the master - it will be doing everything the master does *and* it’s own workload
  • -
  • also called logical replication bullet 1: replicates entire SQL statements bullet 2 sub-bullet 2: the SQL is written to the log - not all the rows changed and how they are changed bullet 2 sub-bullet 3: contain all statements that made any changes bullet 3 sub-bullet 1: Def deterministic: guaranteed output with a given input - unfortunately there are quite a few Examples: 1) DELETE and UPDATE state ments that use a LIMIT clause without an ORDER BY 2) using any of the following functions: UUID(), UUID _SHORT (), USER (), FOUND_RO WS(), LOAD_FILE(), MASTER_POS_WAIT() , SLEEP(), VERSION(), et c. bullet 3 sub-b ullet 2: Examples: INSERT ... SELECT requires a greater number of row-level l ocks, UPDATE statements that require a table scan (because no index is used in th e WHER E clause) must lock a greater number of rows
  • bullet 1: Row-based binary logging logs changes in individual table rows. The master writes events to the binary log that indicate how individual table rows are changed. bullet 2 sub-bullet 4: - On the Master: INSERT ... SELECT , INSERT statements with AUTO_INCREMENT, UPDATE or DELETE statem ents w ith WHERE clause s that do not use keys or do not change most of the examined rows. - On the Slave: INSERT, UPDATE, or DELETE statement s bull et 3 sub -bulle t 1: SBR lo gs jus t the UPDATE statement. RBR logs each row changed by that UPDATE. - More data means it may take longer to use the binary logs to recover the server and the binary log will be locked for the writing of the data to it bullet 3 sub-bullet 2: - Examples: - Until 5.1.29 you couldn’t read the actual statements that caused changes. After that you can use --base64-output=DECODE-ROWS and --verbose. with mysql binlog - Prior to 5. 1.24, it was possible to get dif ferent re sults on the slave then from on the master. Caused by a bug that handled locking of rows as they were accessed. Corrected now.
  • bullet 3: Some examples: UUID() one or more tables with AUTO_INCREMENT columns are updated and a trigger or stored function is invoked any INSERT DELAYED is ex ecuted. call to a UDF is involved individual engines can also determine the logging format used when information in a table is updated
  • -
  • - slaves should be more powerful from Master since they have to do all the work from the master and all the reads for the slave - master can only expand so much. For each slave it has it will have to handle the connection and the sending of the binlog - multiple layouts - Master/Slave, Master/Master (not recommended unless Hot Master/Cold Master), Pyramid etc.
  • Having a copy of the data on the master: bullet 2: you can stop the slave to get a clean backup of the master without interfering with the availability of public facing system bullet 3: using MMM you can handle failover to a “hot swap” system that has been updating to keep up with the original. No single point of failure. bullet 4: allows you to test with real world data to have a better idea of your applications interaction with it bullet 5: have a different storage engines between the master and the slave on tables to take advantage of a specific storage engines abilities (full-text searching, support of transactions
  • Reporting queries tend to be very different then the queries that are run by the application. This also gives the DBA an area to query the data to learn what about it - helps with query tuning or learn about trends in the data (data mning). All separate from the Master production server so it doesn’t interfere with its work.
  • - take into account latency on the network, so it will not be able to be completely “up-to-date” but something may be better then nothing. - Office/branch/developers/contractors can have a local copy without having access to the master
  • -
  • bullet 1: If this has not already been done, this part of master setup requires a server restart. bullet 2: If this has not already been done, this part of slave setup requires a server restart. bullet 3: Each slave must connect to the master using a MySQL user name and password, so there must be a user account on the master that the slave can use to connect. Does not require a specific replication account - but be aware that user name and password will be stored in plain text within the master.info file - SQL account solely for the purposes of replication
  • bullet1 sub-bullet 1: Look for File and Position in MASTER STATUS bullet1 sub-bullet 2: Pick your poison for how you want to do this. Both methods have manual pages for how to do to it. Maybe a want to test your backup procedures to see if it works... bullet 2 step 4: mysql> UNLOCK TABLES;
  • Bold is all that is really required. [] are optional configs if you need them not all options are shown
  • -
  • Known Gotcha: default database and qualified tables (database.table) can cause a query to not be replicated when you think it should.
  • -
  • Slave_IO_State: A copy of the State field of the SHOW PROCESSLIST output for the slave I/O thread. Master_Log_File: master binlog file from which the I/O thread is currently reading. Read_Master_Log_Pos: position in the current master bin log file that I/O thread has read to. Relay_Log_File: relay log file from which the SQL thread is currently *reading* and executing. Relay_Log_Pos: position in relay log file up to which the SQL thread has read and executed. Relay_Master_Log_File: name of the master binlog containing the most recent event executed by the SQL thread.
  • Exec_Master_Log_Pos: position in the binlog up to which the SQL thread has read and executed. - The coordinates given by (Relay_Master_Log_File, Exec_Master_Log_Pos) in the master's binary log correspond to the coordinates given by (Relay_Log_File, Relay_Log_Pos) in the relay log. Relay_Log_Space: total combined size of all existing relay log files. Seconds_Behind_Master: In essence, this field measures the time difference in seconds between the slave SQL thread and the slave I/O thread. This field is an indication of how “late” the slave is: - When the slave SQL thread is actively processing updates, this field is the number of seconds that have elapsed since the timestamp of the most recent event on the master executed by that thread. - When the SQL thread has caught up to the slave I/O thread and is idle waiting for more events from the I/O thread, this field is zero. Gotcha: If the network is slow, this is not a good approximation; the slave SQL thread may quite often be caught up with the slow-reading slave I/O thread, so Seconds_Behind_Master often shows a value of 0, even if the I/O thread is late compared to the master. In other words, this column is useful only for fast networks . Last_IO_Errno/Last_IO_Error: error number and error message of the last error that caused the I/O thread to stop. Last_SQL_Errno/Last_SQL_Error: error number and error message of the last error that caused the SQL thread to stop.

MySQL 5.1 Replication MySQL 5.1 Replication Presentation Transcript

  •  
  • Replication with MySQL 5.1
    • Ligaya Turmelle
    • Senior Technical Support Engineer - MySQL
    • [email_address]
    • http://joind.in/1573
    <Insert Picture Here>
  • Agenda
    • What it is
    • How it Works
    • Types
    • Use Cases
    • Setting it up
    • Filtering Rules
    • Monitoring
    <Insert Picture Here>
  • What is it? <Insert Picture Here>
  • How does it work? <Insert Picture Here>
  • 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
  • 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.
  • 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
  • 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
  • Types <Insert Picture Here>
  • 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
  • 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.
  • 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
  • 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
  • Use Cases <Insert Picture Here>
  • 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
  • Data Redundancy
    • Another common usage
    • backups
    • Failover
    • Use as a testing system
      • test queries
      • application interaction
    • Use different storage engine abilities
  • Analytics
    • Reporting
      • different queries
      • long running
      • locking
      • caches
    • DBA can query to learn about their data
      • distribution
      • trends
  • Long Distance Data Distribution
    • Geographically separate locations
      • disaster recovery
      • Office wants to work on a local copy
  • Setting it up <Insert Picture Here>
  • 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';
  • 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
  • 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}] ;
  • Filtering rules <Insert Picture Here>
  • Filtering Rule Basics
    • 2 levels of filtering
      • On the Master
        • Not recommended
      • On the slave
        • preferred
        • Can be confusing
  • Filtering on the Master
    • How it works:
      • binlog-do-db
      • binlog-ignore-db
    • Not recommended - ever!
      • Reasons:
        • audit
        • point in time recovery
        • crash recovery
  • 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
  • Database Filters Filters
  • Table Filters 1 Start (Following DB options) Any replicate-*-table options? execute UPDATE and Exit Which logging format? Statement Row For each statement that performs an update.. For each update of a table row... No Yes
  • Table Filters 2 (do/ignore) Any replicate-do-table options? execute UPDATE and Exit Any replicate-ignore-table options? Does the table match any of them? Yes No Yes No ignore UPDATE and Exit Does the table match any of them? Yes Yes No No
  • Table Filters 3 (wild do/wild ignore) Any replicate-wild-do-table options? execute UPDATE and Exit Any replicate-wild-ignore-table options? Does the table match any of them? Yes No Yes No ignore UPDATE and Exit Does the table match any of them? Yes Yes No No
  • Table Filters 4 Is there another table to be tested? Any replicate-do-table or replicate-wild-do-table options? Yes No No ignore UPDATE and Exit Yes execute UPDATE and Exit
  • Monitoring <Insert Picture Here>
  • On the Master
    • Not much info here
    • Provides the File and Position
    • Shows any filtering being done on the master
    • Lists the binary logs on the server
    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 | +---------------+-----------+
  • mysql> SHOW SLAVE STATUSG *************************** 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: On the Slave
  • 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:
  • Questions? <Insert Picture Here>
  •