MySQL 5.6 复制教程

最新推荐文章于 2021-05-09 18:45:02 发布

cizhuoouyong8699

最新推荐文章于 2021-05-09 18:45:02 发布

阅读量131

点赞数

文章标签：数据库

1、介绍

MySQL复制使得用户能够经济高效地提高应用性能、可扩展性以及高可用性。许多全球流量最大的网站，例如eBay、Facebook、Tumblr、Twitter以及YouTube，依赖MySQL复制轻松地扩展，超越单实例容量的限制，支持了数亿、呈指数增长的用户。

通过在实例之间镜像数据，MySQL复制也是实现MySQL数据库高可用性（HA）最常用的方法。此外，MySQL复制工具能够自动检测和恢复失败，使得用户能够在故障或者计划维护时维持服务。

MySQL 5.6引入了许多复制增强功能，实现了更高级别的数据完整性、性能、自动化以及应用灵活性。

本文提供了一个简单的安装与配置主/从拓扑结构，以及处理故障转移事件的逐步操作指南。它将演示如何容易地使用MySQL 5.6引入的最新MySQL复制全局事务ID（GTIDs）实现和扩展新服务。

在学习本教程之前，可以首先阅读相关的文章“MySQL 5.6 复制介绍”，了解MySQL复制和MySQL 5.6中的新特性。

2、配置MySQL复制

随着MySQL 5.6中引入了全局事务ID（GTIDs），复制的配置、监控以及管理都变得更加容易和健壮。

本节逐步介绍如何使用MySQL 5.6中的GTIDs建立单个主数据库到单个从数据库的复制。本节还指出了没有使用GTIDs时的替换步骤，例如由于大量使用MyISAM表或者使用了MySQL 5.6之前的版本导致不能使用该选项。

步骤1：配置主从数据库cnf文件

至少需要在每个MySQL服务器的配置文件的[mysqld]部分添加以下选项（某些选项单独用于主数据库或者从数据库，但是在所有服务器中添加这些选项能够简化角色转换）：

binlog-format：为了测试所有的MySQL 5.6优化，选择基于行的复制
log-slave-updates、gtid-mode、enforce-gtid-consistency、report-port以及report-host：用于启用全局事务IDs以及满足相关先决条件
master-info-repository以及relay-log-info-repository：打开以启用崩溃安全的二进制日志/从服务器功能（在事务表而不是平面文件中存储信息）
sync-master-info：设置为1以确保不会丢失信息
slave-parallel-workers：设置当该服务器作为从服务器时，应用接收到的复制事件的并发线程数。设置为0将会关闭多线程从服务器功能。如果该机器拥有多核，并且使用了多个数据库，可以增加该值以更好地利用多线程功能
binlog-checksum、master-verify-checksum以及slave-sql-verify-checksum：用于启用所有的复制校验和校验
binlog-rows-query-log-events：使用基于行的复制时启用二进制日志中的信息日志事件（尤其是原始SQL查询），简化故障排除
log-bin：服务器必须启用二进制日志才能作为复制的主服务器。如果想要在将来某种情况下（例如发生故障转移或者正常切换时）使得从服务器担任主服务器的角色，从服务器也需要配置二进制日志。使用全局事务ID时也必须在从服务器上启动二进制日志。
server-id：该变量必须在复制拓扑的所有服务器之间唯一，并且使用一个1到4294967296之间的正整数表示。

以下是测试中服务器使用的.cnf文件，除了用于运行实用工具的主机之外。

black.cnf：

[mysqld]
binlog-format=ROW
log-slave-updates=true
gtid-mode=on # GTID only
enforce-gtid-consistency=true # GTID only
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
server-id=1
report-port=3306
port=3306
log-bin=black-bin.log
datadir=/home/billy/mysql/data
socket=/home/billy/mysql/sock
report-host=black

blue.cnf：

[mysqld]
binlog-format=ROW
log-slave-updates=true
gtid-mode=on # GTID only
enforce-gtid-consistency=true # GTID only
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
server-id=2
report-port=3306
port=3306
log-bin=blue-bin.log
datadir=/home/billy/mysql/data
socket=/home/billy/mysql/sock
report-host=blue

注意：为了在使用带事务处理的InnoDB的复制环境中达到最大可能的持久性和一致性，需要指定innodb_flush_log_at_trx_commit=1，sync_binlog=1选项。MySQL 5.6包含新的二进制日志分组提交功能，显著减少了最大数据安全配置时的主服务器负载。

假设使用InnoDB存储引擎（GTIDs的使用受到其他限制）。

为了包含更复杂的用例，假设MySQL主服务器已经使用并且包含需要复制到新建从服务器的数据。如果从一个空的数据库开始，可以跳过步骤3和步骤4。

兼容性

如果打算使用两个已经安装的MySQL服务器配置复制，确认主服务器和从服务器的MySQL版本能够兼容。查看http://dev.mysql.com/doc/refman/5.6/en/replication-compatibility.html了解当前的兼容版本列表。

图1描述了本节将会使用的主从复制体系结构。

图1 简单的主从配置

步骤2：创建复制用户

下一步在主服务器上创建一个复制专用的账户。为了安全性，强烈建议创建一个专用的复制用户，这样就不需要授予除了复制权限之外的任何权限。在主服务器上创建一个用户，从服务器能够使用它进行连接。如前所述，该账户必须被授予REPLICATION SLAVE权限。可以在MySQL客户端或者使用MySQL WorkBench执行GRANT：

[billy@black ~]$ mysql -h 127.0.0.1 -P3306 -u root -e "GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.34 IDENTIFIED BY 'billy';" # 192.168.0.34 = “blue”

步骤3：锁定主数据库、记录Binlog位置以及备份主数据库

该步骤（以及步骤4）是可选的，只有当主服务器在启用二进制日志之前接收了更新，或者一些二进制日志被删除时需要执行。在主服务器上执行FLUSH TABLES WITH READLOCK语句刷新所有表并阻塞写语句：

[billy@black ~]$ mysql -h 127.0.0.1 -P3306 -u root --prompt='master> '

master> FLUSH TABLES WITH READ LOCK;

当读锁定生效后，使用以下语句读取主服务器当前的二进制日志名称和偏移量：

master> SHOW MASTER STATUS;

其中，File列显示了日志名称，Position列显示了文件中的偏移量。该例中，二进制日志文件为black-bin.000006，Position为1174。记录这些值，随后配置从服务器时需要用到（除非使用GTIDs，这种情况下不再需要这些值）。它们代表了复制坐标，从服务器将会从复制坐标开始处理主服务器上的更新。

注释：如果主服务器之前运行时没有启用二进制日志，日志名称和偏移量为空。此时，在从服务器上指定的日志文件和偏移量需要设置为空字符串（''）和4（如果使用GTIDs不需要指定）。

接下来，将执行FLUSH TABLES WITH READ LOCK的MySQL客户端窗口保持打开，需要将主服务器的数据库内容转储处理，复制到从服务器中。本文示例将会转储数据库clusterdb的内容。

注意：如果从服务器和主服务器的用户账户配置不同，可能不想复制系统数据库mysql。此时，应该在转储进程中排除该数据库。

可以从命令行或者MySQL WorkBench的图形驱动方式执行mysqldump。

[billy@black ~]$ mysqldump -h 127.0.0.1 -P3306 -u root –B clusterdb > /home/billy/mysql/clusterdb.sql

可以使用以下语句重新打开主服务器的写操作：

master> UNLOCK TABLES;

如果使用MySQL企业版，可以使用MySQL企业备份在不锁定的情况下备份InnoDB表（MySQL Cluster拥有自己内置的在线备份命令）。

步骤4：在从数据库上装载转储文件

接下来，将主服务器上的mysqldump文件装载到从服务器中（需要将clusterdb.sql文件从black复制到blue）。可以从命令行或者MySQL WorkBench的图形驱动方式装载文件。由于从服务器上还不存在clusterdb数据库，必须在装载表和数据之前创建该数据库：

[billy@blue ~]$ mysql -h 127.0.0.1 -P3306 -u root < /home/billy/mysql/clusterdb.sql

步骤5：初始化复制

现在可以在从服务器上初始化复制了。

接下来需要提交一个CHANGE MASTER语句；如果使用了GTIDs，二进制日志偏移量信息可选，因为使用MASTER_AUTO_POSITION可以确保正确的复制事件能够从主服务器发送到从服务器。

[billy@blue ~]$ mysql -h 127.0.0.1 -P3306 -u root --prompt='slave> '

slave> CHANGE MASTER TO MASTER_HOST='black', MASTER_USER='repl_user', MASTER_PASSWORD='billy', MASTER_AUTO_POSITION=1;

其中：

MASTER_HOST：主服务器的IP或者主机名，本例中为black或者192.168.0.31
MASTER_USER：在步骤2中授予REPLICATION SLAVE权限的用户，本例中为repl_user
MASTER_PASSWORD：在步骤2中为repl_user指定的口令

如果没有使用GTIDs，必须提供主服务器二进制日志的偏移量信息：

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;

其中：

MASTER_LOG_FILE：在步骤3中确定的文件名称
MASTER_LOG_POS：在步骤3中确定的偏移量

最后，在从服务器上启动复制：

slave> START SLAVE;

步骤6：基本检查

现在可以执行一些基本检查，确认复制能够生效。下例在主服务器上插入一些数据到表simples中，然后验证新行出现在从服务器中：

master> USE clusterdb;
master> CREATE TABLE simples (id INT NOT NULL PRIMARY KEY);
master> INSERT INTO clusterdb.simples VALUES (1),(2),(3),(999);

slave> SELECT * FROM clusterdb.simples;
+-----+
| id |
+-----+
| 1 |
| 2 |
| 3 |
| 999 |
+-----+

3、迁移到半同步复制

本节假设已经安装并运行异步复制，但是想要迁移到半同步复制，也就是说本节基于第2节执行。如果还没有使用异步复制，可以直接使用半同步复制。

注释：半同步复制只在MySQL 5.5及更高版本中可用。

步骤7：在主从数据库中安装插件

为每个MySQL服务器安装适当的插件：

master> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

slave> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

步骤8：激活半同步复制

要激活半同步复制，必须在主服务器以及至少一个从服务器上激活（本文示例只有一个从服务器）。可以通过在black.cnf中设置rpl_semi_sync_master_enabled为ON，并且在blue.cnf中设置rpl_semi_sync_slave_enabled为ON完成操作；也可以从MySQL命令行执行（可以避免重启MySQL服务器，但是在生产环境中还需要更新配置文件，以防服务器重启后丢失了修改）：

master> SET GLOBAL rpl_semi_sync_master_enabled = ON;

slave> SET GLOBAL rpl_semi_sync_slave_enabled = ON;
slave> STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;

如果没有正在运行复制，不需要停止并重启从属IO线程，只需要提交START SLAVE。

从主服务器检查半同步复制正在运行，并且至少有一个从服务器以半同步模式连接：

步骤9：确认复制以半同步模式运行

在主服务器上添加一个新行，然后检查状态变量确认以半同步方式复制（也就是说，从服务器在主服务器超时之前确认收到变更，并且客户端异步确认数据插入）。

master> INSERT INTO clusterdb.simples VALUES (100);
master> SHOW STATUS LIKE 'Rpl_semi_sync_master_yes_tx';
+-----------------------------+-------+
| Variable_name | Value |
+-----------------------------+-------+
| Rpl_semi_sync_master_yes_tx | 1 |
+-----------------------------+-------+

slave> SELECT * FROM clusterdb.simples;
+-----+
| id |
+-----+
| 1 |
| 2 |
| 3 |
| 100 |
| 999 |
+-----+

4、复制管理与故障排除

本节介绍如何执行一些关于MySQL复制的基本管理与故障排除任务。

检查复制状态

管理复制过程的最常见任务是确认复制正在进行并且从服务器与主服务器之间不存在任何错误。

用于该任务的主要语句是SHOW SLAVE STATUS，必须在从服务器上执行。例如：

slave> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.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

以下是一些输出结果的解释：

Slave_IO_State 指示从服务器的当前状态
Slave_IO_Running 显示读取主服务器二进制日志的IO线程是否正在运行
Slave_SQL_Running 显示执行中继日志事件的SQL线程是否正在运行
Last_Error 显示处理中继日志时记录的最后一个错误。理想情况下应该为空，表示没有错误
Seconds_Behind_Master 显示从服务器SQL线程落后主服务器二进制日志处理的秒数.一个大数值（或者一个递增的数值）表示从服务器不能处理来自主服务器的大量语句。0通常被理解为从服务器已经追赶上主服务器，但是有时候并不完全正确。例如，可能主从服务器之间的网络连接断开了，但是从服务器IO线程还没有检测到这一情况，也就是还没有到达slave_net_timeout时间。如果停止了复制（如上例所示），该值将会显示为NULL

注意，当使用GTIDs时，Retrieved_Gtid_Set与Executed_Gtid_Set分别提供了从服务器已经接收和执行的GTIDs详细信息。

在主服务器上，可以通过查看运行进程列表检查从服务器的状态。

master> SHOW PROCESSLIST \G

因为是从服务器驱动复制过程的核心，以上只显示非常少的信息。

暂停复制

可以在从服务器上使用STOP和START语句停止和启动语句的复制。

要停止从服务器二进制日志的执行，使用STOP SLAVE：

slave> STOP SLAVE;

停止执行后，从服务器不会通过IO_THREAD读取主服务器的二进制日志，并且停止处理还没有通过SQL_THREAD执行的中继日志事件。可以通过指定线程类型分别暂停IO线程或者SQL线程。例如：

slave> STOP SLAVE IO_THREAD;

停止SQL线程可以用于在从服务器上执行离线备份或者其他只处理来自主服务器的事件的任务。IO线程将会继续从主服务器读取，但是不会应用这些修改，这样当再次启动从服务器操作时能够更容易追赶上主服务器。这对于故障转移时将该从服务器用作新的主服务器时很重要。

停止IO线程允许继续执行中继日志中的语句，直到中继日志不再接收到新的事件。该选项可以用于从服务器追赶上主服务器事件；或者执行从服务器管理，同时确保拥有到指定事件点的最新更新。

使用START SALVE语句重新启动复制：

slave> START SLAVE;

如果需要，可以单独启动IO_THREAD或者SQL_THREAD线程。

查看二进制日志

如前所述，服务器二进制日志由包含描述数据库内容修改的“事件”的文件组成。服务器以二进制格式写入这些文件。要以文本格式显示这些内容，使用mysqlbinlog工具。还可以使用该工具显示从服务器写入的中继日志文件，因为中继日志与二进制日志的格式相同。

更多关于mysqlbinlog工具的信息，查看http://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html。

5、故障转移与恢复

有时候复制的主服务器会发生故障，或者由于维护需要关闭；本节讲述故障转移与恢复的步骤。

步骤1：先决条件

在第2节中，配置了一个两服务器的主从复制模式。在本节中，进行了以下2方面的扩展：

改变主从关系，使从服务器成为主服务器（例如维护时需要关闭原主服务器），并且随后原主服务器成为从服务器
从一个更复杂的配置入手，如图2所示，一个主服务器（black）与2个从服务器（blue和green）

图2 一个主服务器与两个从服务器

新加MySQL服务器的配置文件与已有服务器的配置文件非常相似：

green.cnf：

[mysqld]
binlog-format=ROW
log-slave-updates=true
gtid-mode=on # GTID only
enforce-gtid-consistency=true # GTID only
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
server-id=3
report-port=3306
port=3306
log-bin=green-bin.log
datadir=/home/billy/mysql/data
socket=/home/billy/mysql/sock
report-host=green

因为每个服务器都可以作为其他两个服务器的主服务器，必须在每个服务器上创建复制用户，每个用户都拥有从其他两个服务器连接的权限：

black> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.34 IDENTIFIED BY 'billy';
black> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.32 IDENTIFIED BY 'billy';

blue> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.31 IDENTIFIED BY 'billy';
blue> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.32 IDENTIFIED BY 'billy';

green> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.31 IDENTIFIED BY 'billy';
green> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.34 IDENTIFIED BY 'billy';

为了启动图2所示的复制结构，必须在blue和green上运行CHANGE MASTER和START SLAVE，如第2节步骤5所述。

最后，如果使用了半同步复制，需要在全部的3个服务器上安装主服务器插件和从服务器插件：

black> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
black> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
black> SET GLOBAL rpl_semi_sync_master_enabled = on;

blue> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
blue> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
blue> SET GLOBAL rpl_semi_sync_slave_enabled = on;
blue> STOP SLAVE IO_THREAD; START SLAVE;

green> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
green> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
green> SET GLOBAL rpl_semi_sync_slave_enabled = on;
green> STOP SLAVE IO_THREAD; START SLAVE;

步骤2：检测主服务器是否失败

在许多情况下，主服务器将会被故意关闭，例如执行硬件维护，该步骤不适合这种情况。其他情况下，失败将会很明显，例如硬件崩溃。但是，还存在许多更细微的失败需要进行检测并触发故障转移。

一个简单的方法是监控一个或者多个从服务器的Seconds_Behind_Master值：

blue> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.31
Master_User: repl_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: black-bin.000003
Read_Master_Log_Pos: 1655
Relay_Log_File: blue-relay-bin.000004
Relay_Log_Pos: 1867
Relay_Master_Log_File: black-bin.000003
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:
Mster_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

如果Seconds_Behind_Master逐渐增加，并且主服务器的更新数量没有显著变化，有可能是一个主服务器存在问题的信号（尤其是多个从服务器观察的结果相同）。

MySQL企业监控可以用于监控复制的状态，因此可以用于发出需要故障转移的告警。告警可以配置当主服务器状态变量超出预定义阈值时自动提醒管理员。这样使得可以在服务受到影响之前采取补救措施。

步骤3：暂停主服务器写入

如果主服务器进程失败或者底层硬件崩溃，该步骤可能不需要执行；但是对于计划维护或者更细微的失败，需要在过渡期间阻止客户端应用执行更新。

停止更新的方法有很多，通过应用程序、负载均衡器或者连接器。另外一个方法就是在所有表上执行锁定：

black> FLUSH TABLES WITH READ LOCK;

步骤4：提升从服务器为主服务器

在示例中存在2个从服务器，因此需要选择一个提升为主服务器；选择基于哪一个服务器的数据是最新的，也就是说，哪一个处理了更多的来自原主服务器的更新；这个可以通过在每个从服务器上执行show slave status \G来判断。

一旦选定，新的主服务器上的IO线程需要停止（本例中选择了“blue”）：

blue> STOP SLAVE IO_THREAD;

执行该命令之后，SQL线程将会继续运行，应用中继日志中剩余的更新。一旦应用了中继日志中的所有更新（直到Exec_Master_Log_Pos = Read_Master_Log_Pos），可以在新的主服务器上完全停止复制（如果使用GTIDs，直到Retrieved_Gtid_Set = Executed_Gtid_Set）：

blue> STOP SLAVE;

如果使用了半同步复制，此时在新的主服务器上激活服务器端插件：

blue> SET GLOBAL rpl_semi_sync_master_enabled = on;

在启动新的主服务器（blue）到剩余从服务器（green）的复制之前，需要确认新的主服务器二进制日志的当前位置（如果没有使用GTIDs的话）：

blue> SHOW MASTER STATUS \G
+-------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+------------------------------------------+
| blue-bin.000006 | 807 | | | A0F7E82D-3554-11E2-9949-080027685B56:1-5 |
+-------------------+----------+--------------+------------------+------------------------------------------+

在剩余从服务器上（green），重新指定主服务器：

green> STOP SLAVE;
green> CHANGE MASTER TO MASTER_HOST='blue', MASTER_USER='repl_user',
MASTER_PASSWORD='billy', MASTER_AUTO_POSITION=1;
green> START SLAVE;

如果没有使用GTIDs的话，执行以下命令：

green> STOP SLAVE;
green> CHANGE MASTER TO MASTER_HOST='192.168.0.34',
-> MASTER_USER='repl_user',
-> MASTER_PASSWORD='billy',
-> MASTER_LOG_FILE='blue-bin.000001',
-> MASTER_LOG_POS=807;
green> START SLAVE;

如果使用了半同步复制，查询新的主服务器，确认剩余的从服务器注册了异步复制（结果应该为1）：

blue> SHOW STATUS LIKE 'Rpl_semi_sync_master_clients';
+------------------------------+-------+
| Variable_name | Value |
+------------------------------+-------+
| Rpl_semi_sync_master_clients | 1 |
+------------------------------+-------+

此时复制再次启动并运行，如图3所示。

图3 使用新的主服务器的复制

步骤5：将写入重定向到新的主服务器

现在可以启动应用写入新的主服务器（可以同时从新的主服务器或者剩余从服务器读取）。

步骤6：将失败的主服务器与新的主服务器进行同步

在某种情况下，原主服务器（black）可能作为一个从服务器重新添加到配置拓扑中。可以采用以下两种方法：

将它作为一个全新的从服务器，遵循第2节的步骤3到步骤6。如果在原主服务器被重新引入之前产生了大量更新，或者原主服务器的部分更新没有复制到新的主服务器中（可能是没有使用半同步复制时原主服务器出现了不受控制的失败），首选这种方法。
将它作为新的主服务器的从服务器，并且追赶所有的更新。接下来介绍这种方法。

如果没有释放原主服务器上的读取锁定，执行以下操作：

black> UNLOCK TABLES;

如果使用了半同步复制，在原主服务器上（新的从服务器）激活插件：

black> SET GLOBAL rpl_semi_sync_slave_enabled = on;

启动新的从服务器：

black> CHANGE MASTER TO MASTER_HOST='blue', MASTER_USER='repl_user',
MASTER_PASSWORD='billy', MASTER_AUTO_POSITION=1;
black> START SLAVE;

如果没有使用GTIDs，使用当前主服务器（blue）上的日志文件位置：

black> CHANGE MASTER TO MASTER_HOST='192.168.0.34',
-> MASTER_USER='repl_user',
-> MASTER_PASSWORD='billy',
-> MASTER_LOG_FILE='blue-bin.000001',
-> MASTER_LOG_POS=807;
black> START SLAVE;

此时重新回到了一个主服务器和两个从服务器配置，如图4所示。

图4 新的1主2从配置

最后一个可选的步骤就是再次执行以上过程，将原主服务器重新配置为主服务器。

6、结论

MySQL复制已经被证明是一个针对最苛刻的互联网和企业环境下，最大限度扩展数据库驱动应用的有效的解决方案。

本文介绍了如何通过引入全局事务ID使用MySQL 5.6更加简单和强健地配置、监控以及持续维护复制。本文还涉及无法使用新特性时的
一些更复杂的操作。

7、资源

MySQL 5.6 复制介绍http://www.mysql.com/why-mysql/white-papers/mysql-replication-introduction。

MySQL 5.6下载：http://dev.mysql.com/downloads/mysql/。

MySQL复制用户指南：http://dev.mysql.com/doc/refman/5.6/en/replication.html。

MySQL集群复制文档：http://dev.mysql.com/doc/mysql-cluster- excerpt/5.5/en/mysql-cluster-replication.html。

Tickectmaster使用的MySQL（大量用户的MySQL复制）：http://www.mysql.com/customers/view/?id=684。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24945919/viewspace-764369/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24945919/viewspace-764369/