1. 介绍
MySQL复制可以让用户经济有效地提供应用程序的性能,扩展性和高可用。
世界上许多最繁忙的网络站点 像eBay，Facebook,Tumblr,Twitter 和YouTube 依赖MySQL 的复制来弹性的扩大,
越过单实例的约束
在实例间镜像数据,MySQL 复制是最常用的方法,提供高可用性。此外, MySQL 复制功能可以自动检测和recover from failures
让用户保持服务由于
停电或计划的维护。
在5.6版本里,增强了mysql的复制,提供更高水平的数据完整性，性能,灵活性和自动化应用
本文提供了一个简单的一步一步的指导如何安装和配置一个主从拓扑:以及处理故障转移事件（手动和自动）.
他将展示如何容易的设置和使用新的service 使用最新的复制功能和 Global
Transaction IDs (GTIDs) - introduced in MySQL 5.6.
2. 自动复制 配置 使用MySQL 复制功能 GTIDs
Mysql 5.6的复制特性 GTIDs ，配置,监控和管理复制 变得更加简单和稳健。举个例子,
它介绍了自动提升一个slave 为master 在原来的master fails的时候
最简单的方式来访问这些功能是通过点击pocket-knife 按钮在MySQL WorkBench
支持failover 和恢复是更广泛的MySQL的功能 简化了MySQL 的维护和管理
包括提供了复制的校验, 比对和cloning 数据库, 诊断。
这个部分介绍如何使用这些工具来:
1. 设置复制从单一的master 到多个slaves
2.自动检测到master 的failure 提升其中的一个slaves 成为新的master
3.介绍老的master 回归到拓扑作为一个新的slave， 提升它为master
至少我们需要增加哪些选项到[mysqld] 部分,（注意有些是指定给master的或者slave的,包括他们所有的server，
使得角色切换变的简单)
1.binlog-format: 基于行的复制被选为了测试所有的MySQL 5.6
优化
2.log-slave-updates, gtid-mode, enforce-gtid-consistency, report-port and
report-host:
用于让 Global Transaction IDs ,满足相关的条件。
3.master-info-repository and relay-log-info-repository: 设置为TABLE 来启用crash-safe binlog/slave 功能（
存储信息到事务表里相比文件)
mysql> show variables like '%master%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| master_info_repository | FILE |
mysql> show variables like '%relay%';
+---------------------------+----------------+
| Variable_name | Value |
+---------------------------+----------------+
| relay_log_info_repository | FILE
4.sync-master-info: set to 1 to ensure that no information is lost
注意:为最大可能的耐久性和一致性，在使用InnoDB复制设置
事务,你需要设置
innodb_flush_log_at_trx_commit=1,sync_binlog=1 选项。
mysql> show variables like '%innodb_flush_log_at_trx_commit%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1 |
+--------------------------------+-------+
1 row in set (0.02 sec)
mysql> show variables like '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 0 |
+---------------+-------+
1 row in set (0.00 sec)
sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决
定什么时候来做同步，或者cache满了之后才同步到磁盘。
sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘
。
一般设置为1
MySQL 5.6包括的按组提交的功能用于binlog 显著降低了master的负载
功能事迹上是从运行在远端的host , 需要访问每个MySQL Servers. 因此用户必须被授予远程访问权限
[billy@black ~]$ mysql -h 127.0.0.1 -P3306 -u root -e "GRANT ALL ON *.* TO root@'%' WITH
GRANT OPTION;"
[billy@blue ~]$ mysql -h 127.0.0.1 -P3306 -u root -e "GRANT ALL ON *.* TO root@'%' WITH
GRANT OPTION;"
[billy@green ~]$ mysql -h 127.0.0.1 -P3306 -u root -e "GRANT ALL ON *.* TO root@'%' WITH
GRANT OPTION;"
[billy@brown ~]$ mysql -h 127.0.0.1 -P3306 -u root -e "GRANT ALL ON *.* TO root@'%' WITH
GRANT OPTION;"
[billy@red ~]$ mysql -h 127.0.0.1 -P3306 -u root -e "GRANT ALL ON *.* TO root@'%' WITH
GRANT OPTION;"
在这个例子中, root 访问被授予了所有的远程主机(root@'%") 为了方便,对于一个安全生产环境 你需要有所选择。
设置复制:
当这里有额外的选项(比如 指定用户名/密码 用于复制用户 或者提供root 用户的密码)
mysqlreplicate --master=root@black:3306 --slave=root@blue:3306
# master on black: ... connected.
# slave on blue: ... connected.
# Checking for binary logging on master...
# Setting up replication...
# ...done.
mysqlreplicate --master=root@black:3306 --slave=root@green:3306
# master on black: ... connected.
# slave on green: ... connected.
# Checking for binary logging on master...
# Setting up replication...
# ...done.
mysqlreplicate --master=root@black:3306 --slave=root@brown:3306
# master on black: ... connected.
# slave on brown: ... connected.
# Checking for binary logging on master...
# Setting up replication...
# ...done.
mysqlreplicate --master=root@black:3306 --slave=root@red:3306
# master on black: ... connected.
# slave on red: ... connected.
# Checking for binary logging on master...
# Setting up replication...
# ...done.
复制已经被设置了 一个master 4个slaves
我们可以验证复制拓扑匹配使用mysqlrplshow实用设计：
mysqlrplshow --master=root@black --discover-slaves-login=root@black
# master on utils1: ... connected.
# Finding slaves for master: black:3306
# Replication Topology Graph
black:3306 (MASTER)
|
+--- blue:3306 - (SLAVE)
|
+--- green:3306 - (SLAVE)
|
+--- brown:3306 - (SLAVE)
|
+--- red:3306 - (SLAVE)
此外, 你也可以检查 复制环境是否配置正确:
mysqlrplcheck --master=root@black --slave=root@brown:3306 --discover-slaves-
login=root@black
# master on black: ... connected.
# slave on brown: ... connected.
Test Description Status
---------------------------------------------------------------------------
3. 手动配置MySQL 复制
在这个章节 我们描述一个替代,更加手工的方法用于设置MySQL replication.
你可能使用这个,例如，如果GTIDs不是一种选择，因为你将使用MyISAM表,
约束使用MySQL pre-5.6版本或需要额外的控制水平。
尽管, 本程序是用建立一个slave的条款。
有关示例说明。
Master
Host Name: black
IP: 192.168.0.31
Slave
Host Name: blue
IP: 192.168.0.34
图2应用程序配置为例
我们假设你将要使用InnoDB 存储引擎(GTIDs的使用受到限制
否则）
为了包括更复杂的用例, 例子假设 MySQL Server 用于master的已经在使用和包含数据,如果启动一个空的数据库
If
starting with an empty database then Step 3: and Step 4: can be skipped
兼容性
如果你尝试设置复制 在两个MySQL Server 已经安装好的机器，确保 MySQL master和slave 的版本是兼容的
请注意，本节介绍了如何进行收到配置，参考2节看
这可以大大简化和自动化使用MySQL复制工具
Step 1: Configure the master & slave cnf files
第一步是设置复制编辑my.cnf文件 在server上, 我们必须提供master 和slave的配置文件
现在,重新启动Mysql servers 使用service manager 或者直接从命令行启动
[billy@black ~]$ mysqladmin -u root shutdown # only needed if MySQL already running
[billy@black ~]$ mysqld --defaults-file=/home/billy/mysql/black.cnf &
[billy@blue ~]$ mysqladmin -u root shutdown # only needed if MySQL already running
[billy@blue ~]$ mysqld --defaults-file=/home/billy/mysql/blue.cnf&
注意:如果slave 已经先前被复制了, 启动slave server 带上--skip-slave-start 选项
它不会理解去连master， 你也需要启动slave server 带上--log-warnings 选项来捕捉和得到更多额外的错误信息。
这个选项默认是启用的
Step 2: Create Replication User
下面的步骤是设置用于复制的在master 上创建一个账户用于复制。我们强烈推荐专用的复制用户为了更好的安全性,
我们不需要赋额外的权限。 在master上创建一个账户用于slave连接,如前所述，这个账户必须授予REPLICATION SLAVE 权限。
你可以执行GTANT 在mysql客户端或者MySQL WorkBench:
[billy@black ~]$ mysql -u root --prompt='master> '
master> CREATE USER repl_user@192.168.0.34;
master> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.34 IDENTIFIED BY 'billy';
Step 3: Lock the Master, Note Binlog Position and Backup Master
Database
锁住master，记录Binlog 的Posistion 和备份Master 数据库
这是一个可选的步骤,只有在如果新的master 先前已经接收更新 启用了binary logs或者
由于时间久了 一些binary logs 已经被删除了,在master 上flush 所有的表阻塞写 通过FLUSH TABLES
WITH READ LOCK 语句。
master> FLUSH TABLES WITH READ LOCK;
当read lock 生效后, 记录master 的binary log 和 offset 使用下面的语句:
master> SHOW MASTER STATUS;
+-------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+------------------------------------------+
| black1-bin.000006 | 1174 | | | A0F7E82D-3554-11E2-9949-080027685B56:1-5 |
+-------------------+----------+--------------+------------------+------------------------------------------+
文件显示binlog 的名字和posisiton the binary log file is black1-bin.000006 and the Position is 1174
在设置slave的时候 你需要这些值(除非你使用GTIDs, GTIDs不需要).
它们藐视了 slave开始处理从master 接收新的更新的起点
注意:如果master 已经之前运行了但是没有启动binlog，log name 和position 值显示为空的 在show master status
下一步, 在先前执行FLUSH TABLE WITH READ 的窗口,你需要dump master的数据,在我们的例子中,我们dump clusterdb数据库的内
容。
注意：你可能不需要复制mysql 系统数据库,如果slave 有不同于Master的用户密码设置。
在这种情况下,你需要在备份的时候排除。
[billy@black ~]$ mysqldump -u root clusterdb > /home/billy/mysql/clusterdb.sql
You can re-enable write activity on the master with the following statement:
master> UNLOCK TABLES;
Step 4: Load the Dump File on the Slave ( 在Slave上加载Dump 文件)
下一步,加载数据
[billy@blue ~]$ mysql -u root –e ‘create database clusterdb;’
[billy@blue ~]$ mysql -u root clusterdb < /home/billy/mysql/slave/clusterdb.sql
Step 5: Initialize Replication
你现在可以开始在slave上初始化复制, 执行下面的语句 如果已经作为slave运行了
slave> STOP SLAVE;
下一步,你需要使用一个CHANGE MASTER 语句,如果你使用GTIDs那么binary log 的position 信息是可选的
使用MASTER_AUTO_POSITION会确认 正确的复制events 从master 发送到slave
slave> CHANGE MASTER TO MASTER_HOST='black', MASTER_USER='repl_user',
MASTER_PASSWORD='billy', MASTER_AUTO_POSITION=1;
Where:
MASTER_HOST: the IP or hostname of the master server, in this example black or 192.168.0.31
If not using GTIDs then you must provide positioning information for the master’s binary log:
slave> CHANGE MASTER TO MASTER_HOST='192.168.0.31',
-> MASTER_USER='repl_user',
-> MASTER_PASSWORD='billy',
-> MASTER_LOG_FILE='black-bin.000006',
-> MASTER_LOG_POS=1174;
Where:
MASTER_LOG_FILE: is the file name we determined in Step 3:
MASTER_LOG_POS: is the position we determined in Step 3:
Finally, start replication on the slave:
slave> START SLAVE;
5. 复制管理和Troubleshooting
在这一节中我们将如何执行一些基本的管理和故障排除任务
MySQL复制。
1.检查复制状态:
最常见的任务在管理复制的时候是确保复制是在运行的 ,在master 和slave 上没有任何的错误:
slave> SHOW SLAVE STATUSG
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.31
Master_User: repl_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: black-bin.000006
Read_Master_Log_Pos: 1655
Relay_Log_File: blue-relay-bin.000004
Relay_Log_Pos: 1867
Relay_Master_Log_File: black-bin.000006
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:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1655
Relay_Log_Space: 2235
Until_Condition: None
Until_Log_File:
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: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 5c9a887f-3983-11e2-b48f-080027685b56
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
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 5C9A887F-3983-11E2-B48F-080027685B56:1-6
Executed_Gtid_Set: 5C9A887F-3983-11E2-B48F-080027685B56:1-6,
5FB9D4B7-3983-11E2-B48F-0800274BDCE7:1-2
1.Slave_IO_State 表明当前slave的状态
Slave_IO_State: Waiting for master to send event
2. Slave-IO-Running 显示 IO thread 读取master的binary log 是否运行
Slave_IO_Running: Yes
3.Slave_SQL_Running 显示SQL thread 是否执行relay log里的events
Slave_SQL_Running: Yes
4.Last_Error: 显示处理relay log 最后的错误日志，空表示没有错误
Last_Error:
5.Seconds_Behind_Master： 显示 salve 的SQL thread 是落后master binary log 多少秒了,
一个比较大的值 表明slave五福应付大量的master的更新语句。 值为0说明slave已经追上了master,
但是某些情况下这不是完全正确的。
Seconds_Behind_Master: 0
注意 当使用GTIDs的时候,Retrieved_Gtid_Set and Executed_Gtid_Set提供了 信息干预GTIDs已经接收和处理
Suspending Replication 复制挂起
你可以停止和启动复制 使用STOP SLAVE 和START SLAVE
停止执行binary log 使用STOP SLAVE;
slave> STOP SLAVE;
当执行被停止, slave不从master 读取binary log 通过IO_THREAD
停止从relay log 处理events通过SQL_THREAD
你可以单独停止IO或者SQL thread通过下面的命令：
slave> STOP SLAVE IO_THREAD;
停止SQL thread 可能是有用的 ,如果你需要执行一个office backup 或者其他任务在slave上 只处理master 的event
IO thread 会继续读取master，但是改变不会被应用,
这将使slave更容易追上,当你再次启用slave的时候 ，这个是重要的 当你让这个slave 成为新得master的时候。
停止IO thread 允许relay log里的语句被执行直到 中继日志停止接收新的events.
使用这个选项是有用的,当你需要允许slave 来追赶master，当你需要在slave上执行管理任务
但是不确定是否更新到一个特定的点。
6 Manual Failover and Recovery
手动Failover 和Recovery
会有些时候,master fails或者需要进行维护,这个章节需要的步骤:
步骤1 ：先决条件
在章节2和章节4 我们配置了复制有2个MySQL Server 在一个master-slave 配置
1.所有的关系被改变 --一个server 表现为slave 可以变为Master(例子 当你需要shutdown 原来的master用于维护)
原来的master 可以随后变为slave
2.我们开始更加复杂的配置 一个单独的master 和2个slave