mysql replication for beginners
TRANSCRIPT
MySQL Replication for Beginners
Dave StokesMySQL Community Manager
Oracle Corporation
[email protected]@Stoker
Slideshare.net/davestokesOpensourcedba.wordpress.com
https://joind.in/13740
Safe Harbor
The following is intended to outline our
general product direction. It is intended
for information purposes only, and may
not be incorporated into any contract. It is
not a commitment to deliver any material,
code, or functionality, and should not be
relied upon in making purchasing
decision. The development, release, and
timing of any features or functionality
described for Oracle’s products remains
at the sole discretion of Oracle. Take anything I say about future products 'with a grain of salt' until it reaches GA status!
Happy Birthday MySQL!!!
● MySQL is 20 years old!
● InnoDB is 10!
So, what is replication?
Harcort Fenton Mudd
● I, Mudd first broadcast November 3rd, 1967
● Second story featuring Harry Mudd
● Roger C. Carmel's most remembered roll
● Idea: Replicas who service all your needs
The Basics – Start with Two Servers With The Same data
● Server 1
– The 'master'
– Changes made to table kept in a log file BINLOG
● Server 2
– The 'slave'
– Has a 'copy' of the master's data
– Slave reads BINLOG from the master and creates its own copy of those changes
– Another process reads BINLOG copy and applies changes to databases
– Everyone happy
Pictorial Overview – Async Replication
Seem Simple Enough?
● The concept of MySQL Replication is simple
● Implementation can be simple or … complex
● Much easier than other databases
● Problems:
– Network contention
– Less able hardware on slave that can not keep pace
– SQL issues like Duplicate Keys
– Oddities in schema● Customer_ID is BIGINT on master, INT on SLAVE
– Log files may not equate
So what do we need for setup?
● Servers
– Master
– Slave(s)● Network connectivity
● Databases
● Proper grants and permissions
Servers – Requirements
● Each server needs a unique server id!!!
– /etc/mysql/mysql.cnf: server-id=10● IP address, also unique
● BINARY log enabled on Master(s)
– Use TABLE instead of file● Permissions and Grants
– A user for replication● Root level access on servers
● About 5-10 minutes
GLOBAL Transaction Identifiers
● GTIDs provide an easy way to manage replication as each change has its own unique identifier
● Slaves can quickly ID statements and act on them.
● Previously depended on information on log position offsets.
– Log files may be corrupt after server crash
– Log info kept in tables allows InnoDB to rebuild (5.6??) after crash, better consistency
GTID
● 3E11FA47-71CA-11E1-9E33-C80AA9429562:23
– Server UUID – 3E11FA47-71CA-11E1-9E33-C80AA9429562
– Transaction ID - 23
● More common to see as a range:
– 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
A reading from the Book of MySQL
● GTIDs are always preserved between master and slave. This means that you can always determine the source for any transaction applied on any slave by examining its binary log. In addition, once a transaction with a given GTID is committed on a given server, any subsequent transaction having the same GTID is ignored by that server. Thus, a transaction committed on the master can be applied no more than once on the slave, which helps to guarantee consistency.
– https://dev.mysql.com/doc/refman/5.6/en/replication-gtids-concepts.html
Step 0
● Get hardware ready
– OS
– MySQL (latest and greatest you can run)
– Network connection
Step 1
● Copy data from master to slave(S)
– Mysqldump or similar program
– Mysqldbcopy from MySQL utilities
● mysqldbcopy --source=user:pass@host:port:socket --destination=user:pass@host:port:socket orig_db:new_db
– Your favorite way of transference
Step 2 – Permissions
● Create user for replication
● Use mysqldbgrants to copy from an existing serverOR
● As root:
– Create 'replication' user
– Grant privileges
– Both master and slave
Step 4 – Config /etc/mysql/my.cnf
● Master
– SERVER-ID=1
– Log-bin=mysql-bin
– Gtid-mode=ON
– Enforce-gtid-consistency
– Log-slave-updates
– Binlog_format=mixed
● Slave
– SERVER-ID=5
Setup a user for Replication on all servers
CREATE USER 'replicate'@'10.10.10.%' \IDENTIFIED BY 'wordpass';
GRANT REPLICATION SLAVE ON *.* \TO 'replicate'@'10.10.10.%';
Step 5 – Restart server, Start Slave
● CHANGE MASTER_TO \MASTER_HOST = '10.10.10.1', \MASTER_PORT = 3306, \MASTER_USER = 'replicate', \MASTER_PASSWORD = 'wordpass', \MASTER_AUTO_POSTION = 1;
● START SLAVE
Step 6 SHOW MASTER STATUS\G
mysql> SHOW MASTER STATUS\G*************************** 1. row *************************** File: master-bin.000002 Position: 1307 Binlog_Do_DB: test Binlog_Ignore_DB: manual, mysqlExecuted_Gtid_Set: 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-51 row in set (0.00 sec)
Step 6 continued - Show Slave Status
mysql> SHOW SLAVE STATUS\G
...
Master_UUID: 3e11fa47-71ca-11e1-9e33-c80aa9429562
Master_Info_File: /var/mysqld.2/data/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: 3e11fa47-71ca-11e1-9e33-c80aa9429562:1-5
Executed_Gtid_Set: 3e11fa47-71ca-11e1-9e33-c80aa9429562:1-5
Step 6b – Or use mysqlrplcheckmysqlrplcheck --master=root@host1:3310 --slave=root@host2:3311
# master on host1: ... connected.
# slave on host2: ... connected.
Test Description Status
------------------------------------------------------------------------
Checking for binary logging on master [pass]
Are there binlog exceptions? [pass]
Replication user exists? [pass]
Checking server_id values [pass]
Is slave connected to master? [pass]
Check master information file [pass]
Checking InnoDB compatibility [pass]
Checking storage engines compatibility [pass]
Checking lower_case_table_names settings [pass]
Checking slave delay (seconds behind master) [pass]
# ...done.
Step 6c - Or use mysqlrplsync
The mysqlrplsync utility is designed to check if replication servers with GTIDs enabled are synchronized. In other words, it checks the data consistency between a master and a slave or between two slaves.
The utility permits you to run the check while replication is active. The synchronization algorithm is applied using GTID information to identify those transactions that differ (missing, not read, etc.) between the servers. During the process, the utility waits for the slave to catch up to the master to ensure all GTIDs have been read prior to performing the data consistencycheck.
Mysqlrplsync examplemysqlrplsync --master=user:pass@localhost:3310 \ --slaves=rpl:pass@localhost:3311,rpl:pass@localhost:3312## GTID differences between Master and Slaves:# - Slave 'localhost@3311' is 15 transactions behind Master.# - Slave 'localhost@3312' is 12 transactions behind Master.## Checking data consistency.## Using Master 'localhost@3310' as base server for comparison.# Checking 'test_rplsync_db' database...# - Checking 't0' table data...# [OK] `test_rplsync_db`.`t0` checksum for server 'localhost@3311'.# [OK] `test_rplsync_db`.`t0` checksum for server 'localhost@3312'.# - Checking 't1' table data...# [OK] `test_rplsync_db`.`t1` checksum for server 'localhost@3311'.# [OK] `test_rplsync_db`.`t1` checksum for server 'localhost@3312'.# Checking 'test_db' database...# - Checking 't0' table data...# [OK] `test_db`.`t0` checksum for server 'localhost@3311'.# [OK] `test_db`.`t0` checksum for server 'localhost@3312'.# - Checking 't1' table data...# [OK] `test_db`.`t1` checksum for server 'localhost@3311'.# [OK] `test_db`.`t1` checksum for server 'localhost@3312'.##...done.## SUMMARY: No data consistency issue found.
Step 5 – No GTIDs (pre 5.6)
● What do you need to do if you are running a non-GTID version of MySQL (besides hang you head in shame)?
Non GTID Replication – 5.5 and earlier
● MASTER
– Unique server-id
– Log-bin=mysql-bin● Replication account as
before
● Get bin-log position
● SLAVE
– Unique server-id● Copy data from slave● CHANGE MASTER TO \
MASTER_HOST='10.10.10.1', \MASTER_USER = 'replicate', \MASTER_PASSWORD='wordpass', \MASTER_LOG_FILE='mysql-bin', \MASTER_LOG_POSITION=X;
Replication: Test it out
● Create a table on the master, see if it shows up on the slave.
● Looking at the 'tracks'
Test it some more!
● Add, delete, and update rows.
When things go bad!
● Yes, on occasion something will go bad.
– Updating a record mission on slave
– Schema changes not flushed
– Record on slave that is not on master
– And many, many more
Easy way of skipping two transactions
mysqlslavetrx --gtid-set=ce969d18-7b10-11e4-aaae-606720440b68:1-5 \
--slaves=dba:pass@slave2:3312,dba:pass@slave3:3313
WARNING: Using a password on the command line interface can be insecure.
#
# GTID set to be skipped for each server:
# - slave2@3312: ce969d18-7b10-11e4-aaae-606720440b68:1-5
# - slave3@3313: ce969d18-7b10-11e4-aaae-606720440b68:1-5
#
# Injecting empty transactions for 'slave2:3312'...
# Injecting empty transactions for 'slave3:3313'...
#
#...done.
#
Harder way
● Skip transaction by hand
● SET GTID_NEXT='aaa-bbb-ccc-ddd:N';
● BEGIN;
● COMMIT;
● SET GTID_NEXT='AUTOMATIC';
Pre GTID way to skip
SET GLOBAL sql_slave_skip_counter = N
This statement skips the next N events from the master. This is useful for recovering from replication stops caused by a statement.
This statement is valid only when the slave threads are not running. Otherwise, it produces an error.
When using this statement, it is important to understand that the binary log is actually organized as a sequence of groups known as event groups. Each event group consists of a sequence of events.
Using Replication for backup
● Turning off applier thread on slave
– It is still reading data from master and applying to log, just not committing to database
● Flush tables and lock (maybe kick off users)
● Run backup
● Unlock table, bring back users
● Start applier thread
● Live happy, productive life
– (after you heck backup is good)
Various Example Topologies
Scale out for reads
Various Example Topologies
Various Example Topologies
Multi Master (Not recommended)
● It is not recommend to run multi master
● Yes, you can do it but there is no built in key collision
– Do at own risk● MySQL Group Replication on way
– Probably not in initial 5.7 GA, maybe later or 5.8
Muti-source – MySQL 5.7
Details – Row versus Statement
● Row based (RBR) versus Statement based (SBR)
– Row → results of query
– Statement → the query
– Mixed → Combination● Row +/-
● Statement +/-
● Smart replication
– Row based send only key and changed columns
– binlog_row_image_type=[full|minimal|noblob]
Safe & Unsafe Statements
17.1.2.3 Determination of Safe and Unsafe Statements in Binary Logging
The “safeness” of a statement in MySQL Replication, refers to whether the statement and its effects can be replicated correctly using statement-based format. If this is true of the statement, we refer to the statement as safe; otherwise, we refer to it as unsafe.
In general, a statement is safe if it deterministic, and unsafe if it is not. However, certain nondeterministic functions are not considered unsafe In addition, statements using results from floating-point math functions—which are hardware-dependent—are always considered unsafe
Statements considered unsafe
Statements considered unsafe. Statements with the following characteristics are considered unsafe:
● Statements containing system functions that may return a different value on slave. These functions include FOUND_ROWS(), GET_LOCK(), IS_FREE_LOCK(), IS_USED_LOCK(), LOAD_FILE(), MASTER_POS_WAIT(), PASSWORD(), RAND(), RELEASE_LOCK(), ROW_COUNT(), SESSION_USER(), SLEEP(), SYSDATE(), SYSTEM_USER(), USER(), UUID(), and UUID_SHORT().
● Nondeterministic functions not considered unsafe. Although these functions are not deterministic, they are treated as safe for purposes of logging and replication: CONNECTION_ID(), CURDATE(), CURRENT_DATE(), CURRENT_TIME(), CURRENT_TIMESTAMP(), CURTIME(),, LAST_INSERT_ID(), LOCALTIME(), LOCALTIMESTAMP(), NOW(), UNIX_TIMESTAMP(), UTC_DATE(), UTC_TIME(), and UTC_TIMESTAMP().
Statements considered unsafe Continued
● References to system variables. Most system variables are not replicated correctly using the statement-based format.
● User Defined Functions. Since we have no control over what a UDF does, we must assume that it is executing unsafe statements.
● Trigger or stored program updates a table having an AUTO_INCREMENT column. This is unsafe because the order in which the rows are updated may differ on the master and the slave.
● In addition, an INSERT into a table that has a composite primary key containing an AUTO_INCREMENT column that is not the first column of this composite key is unsafe.
● INSERT DELAYED statement. This statement is considered unsafe because the insertion of the rows may interleave with concurrently executing statements.
● INSERT ... ON DUPLICATE KEY UPDATE statements on tables with multiple primary or unique keys. When executed against a table that contains more than one primary or unique key, this statement is considered unsafe, being sensitive to the order in which the storage engine checks the keys, which is not deterministic, and on which the choice of rows updated by the MySQL Server depends.
● An INSERT ... ON DUPLICATE KEY UPDATE statement against a table having more than one unique or primary key is marked as unsafe for statement-based replication beginning with MySQL 5.6.6.
● Updates using LIMIT. The order in which rows are retrieved is not specified, and is therefore considered
Please read 17.1.2.3 Determination of Safe and Unsafe Statements in Binary Logging in the MySQL Manual
Details – Some Recent Changes
● InnoDB recovers very well from crashes while log files do not. Storing BINLOG data in a InnoDB is a an obvious way of adding crash robustness. New default!
● Checksum on transaction
– Bad packets not getting into the data stream
– binlog_checksum=[NONE|CRC32]
Details – Semi-syncronous replication
The slave acknowledges receipt of a transaction's events only after the events have been written to its relay log and flushed to disk.
Things you can't do with GTIDs
● CREATE TABLE .. SELECT
– Not sate statement based replication (SBR)
– Row based – Processed as two separate transactions● Temporary tables
● Both of the above fail with an ERROR if server started with –enforce-gtid-consistency
MySQL Fabric
● MySQL Fabric allows you to create server farms
– For High Availability and/or sharding
– Automatic failover
– Easy to scale, re-shard without changing application
– `smarts' are in the connector
MySQL Fabric – High Availability
MySQL Fabric – Redundant HA Group
MySQL Fabric Sharding
MySQL Fabric – Setup Overview
● Setup slaves for replication up but stop before CHANGE MASTER. Setup separate Fabric controller(s)
● MYSQLFABRIC MANAGE START
● Have Fabric initialize it's own database
● Setup group(s)
● Assign servers to group, start group
● Activate group (for automatic fail over)
● For sharding: Determine initial shard key and where to break data
● Have app connect to controller for initial connection, connector software handles the rest!
MySQL Utilities
● 28 Pythons scripts (and growing)
– Grep for bad processes and kill them
– Clone a server for replication
– Check permissions/grants
– Find redundant indexes
– Disk usage
– Automatic failover
– Diff tables
– And more
Blogs on GTID Upgrading to 5.6/7
● Enabling Global Transaction Identifiers Without Downtime in MySQL 5.7.6
– http://mysqlhighavailability.com/enabling-gtids-without-downtime-in-mysql-5-7-6/
● Even Easier Master Promotion (and High Availability) for MySQL (no need to touch any slave)
– http://jfg-mysql.blogspot.com/2015/04/even-easier-master-promotion-and-high-availability.html
● Check Planet.MySQL.com for latest blogs on subject
MySQL Central @ Oracle Open World
● October 25-29th in San Francisco
● 180+ talks submitted for ~54 speaking slots
● Tutorials and Workshops
