MySQL Replication是MySQL一个非常重要的功能，主要用于主服务器和从服务期之间的数据复制操作。本章主要学习MySQL Replication的基本概念、Windows环境下的复制操作、Linux环境下的复制操作、如何查看Slave的复制进度、日常管理和维护、切换主从服务器的方法等。

1、MySQL Replication概述

MySQL从3.25.15版本开始提供数据库复制（replication）功能。MySQL复制是指从一个MySQL主服务器（master）将数据复制到另一台或多台MySQL从服务器（slaves）的过程，将主数据库的DDL和DML操作通过二进制日志传到从服务器上，然后在从服务器上对这些日志重新执行，从而使得主从服务器的数据保持同步。

在MySQL中，复制操作是异步进行的，slaves服务器不需要持续地保持连接接收master服务器的数据。

MySQL支持一台主服务器同时向多台从服务器进行复制操作，从服务器同时可以作为其他从服务器的主服务器，如果MySQL主服务器访问量比较大，可以通过复制数据，然后在从服务器上进行查询操作，从而降低主服务器的访问压力，同时从服务器作为主服务器的备份，可以避免主服务器因为故障数据丢失的问题。

MySQL数据库复制操作大致可以分成3个步骤：

1. 主服务器将数据的改变记录到二进制日志（binary log）中。
2. 从服务器将主服务器的binary log events复制到它的中继日志（relay log）中。
3. 从服务器重做中继日志中的事件，将数据的改变与从服务器保持同步。

首先，主服务器会记录二进制日志，每个事务更新数据完成之前，主服务器将这些操作的信息记录在二进制日志里面，在事件写入二进制日志完成后，主服务器通知存储引擎提交事务。

Slave上面的I/O进程连接上Master，并发出日志请求，Master接收到来自Slave的IO进程的请求后，根据请求信息添加位置信息后，返回给Slave的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置。

Slave的I/O进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到Master端的bin-log文件名和位置记录到master-info文件中。

Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时的那些可执行内容，并在自身执行。

MySQL复制环境90%以上都是一个Master带一个或者多个Slave的架构模式。如果Master和Slave的压力不是太大的话，异步复制的延时一般都很少。尤其是Slave端的复制方式改成两个进程处理之后，更是减小了slave端的延时。

对于数据实时性要求不是特别严格的应用，只需要通过廉价的电脑服务器来扩展Slave的数量，将读压力分散到多台Slave的机器上面，即可解决数据库端的读压力瓶颈。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在使用类似方案解决数据库瓶颈。

2、Windows环境下的MySQL主从复制

2.1、复制前的准备工作

在Windows环境下，如果想实现主从复制功能，需要准备操作环境。

2.2、Windows环境下实现主从复制

准备好两台安装MySQL 8.0的计算机后，即可实现两台MySQL服务器主从复制备份操作。具体操作步骤如下。

1. 在Windows操作系统下安装好两台主机的MySQL服务器，配置好两台主机的IP地址，实现两台计算机可以网络连通。

2. 配置Master的相关信息，在Master主机上开启binlog日志。首先，看一下datadir的具体路径。

3. 此时需要打开在C:\Documents and Settings\All Users\Application Data\MySQL\MySQLServer 8.0目录下面的配置文件my.ini，添加如下代码，开启binlog功能。

[mysqld] log_bin="D:/MySQLlog/binlog" expire_logs_days = 10 max_binlog_size = 100M

此时我们需要在D盘下面创建MySQLlog文件夹，binlog日志记录在该文件夹里面，该配置中其他参数的含义如下所示。

• - expire_logs_days表示二进制日志文件删除的天数。
• - max_binlog_size表示二进制日志文件最大的大小。

4. 登录MySQL之后，可以执行show variables like’%log_bin%'命令来测试log_bin是否成功开启：

如果log_bin参数的值为ON，那么表示二进制日志文件已经成功开启；如果为OFF，那么表示二进制日志文件开启失败。

5. 在master上配置复制所需要的账户，这里创建一个repl的用户，%表示任何远程地址的repl用户都可以连接master主机，语句执行如下所示。

6. 在my.ini配置文件中配置Master主机的相关信息，如下所示。

这些配置语句的含义如下：

• - server-id表示服务器标识id号，master和slave主机的server-id不能一样。
• - binlog-do-db表示需要复制的数据库，这里以test数据库为例。
• - binlog-ignore-db表示不需要复制的数据库。

7. 重启Master主机的MySQL服务，然后输入show master status命令查询Master主机的信息。

8. 将Master主机的数据备份出来，然后导入到Slave主机中去，具体执行语句如下：

将c:/a.txt复制到slave主机上面去，然后执行以下操作：

9. 配置Slave主机（192.168.0.206）在C:\Documents and Settings\All Users\ApplicationData\MySQL\MySQL Server 8.0目录下面的配置文件my.ini，具体配置信息如下所示。

配置Slave主机my.ini文件时，需要将server-id = 2写到[MySQLd]后面。另外，如果配置文件中还有log_bin的配置，可以将它注释掉。例如：

# Binary Logging. # log-bin # log_bin = "D:/MySQLlog/mysql-bin.log"

10. 重启Slave主机（192.168.0.206）​，在Slave主机（192.168.0.206）的MySQL中执行如下命令，关闭slave服务。

mysql> stop slave; Query OK, 0 rows affected (0.05 sec)

11. 设置Slave从机实现复制相关的信息，命令如下：

各个参数所代表的具体含义如下：

• -master_host表示实现复制的主机的IP地址。
• -master_user表示实现复制的登录远程主机的用户。
• -master_password表示实现复制的登录远程主机的密码。
• -master_log_file表示实现复制的binlog日志文件。
• -master_log_pos表示实现复制的binlog日志文件的偏移量。

12. 继续执行操作，显示slave从机的状况，如下所示。

在上述执行show slave status \G命令中很显然存在一些问题，具体如下：

Last_IO_Error: Got fatal error 1236 from master when reading dat a from binary log: 'Could not find first log file name in binary log index file'

下面给出解决该问题的方法。

1. 重启Master（192.168.0.208）主机，执行showmaster status \G命令，记下File和Position的值，后面 Slave主机会用到。命令执行如下：

2. 在Slave（192.168.0.206）主机上重新设置信息，命令执行如下所示。

由此可见，问题完全解决，接下来可以进行Window环境下主从复制的测试。

2.3、Windows环境下主从复制测试

在Windows环境中测试主从复制操作，具体操作步骤如下。

1. 在Master主机的MySQL环境下，执行如下命令。

2. 在Slave主机的MySQL环境下，查看主机刚才添加的表和数据是否成功同步到从机上，命令执行如下所示。

测试表明数据已经成功地同步到Slave主机上了，实验中只是用到主从同步，在实际生产环境中MySQL架构可能会用到一主多从的架构，这里不再叙述。

3、Linux环境下的MySQL复制

在现实的生产环境中单机实现的主从复制比较少，通常会使用一主多从的架构体系。为了读者朋友更好地实现本机主从复制，需要在Linux环境下面通过MySQLd_multi实现单机的主从复制。本节使用的是Fedora操作系统。

3.1、下载并安装MySQL 8.0

很多熟悉MySQL的用户都喜欢使用源码包来进行安装，因为在安装源码的过程中可以非常方便地进行性能的优化。下面就源码安装过程中涉及的优化项进行简单的介绍。

1. 下载MySQL-8.0.13.tar.gz源文件。可以在下载页面http://dev.mysql.com/downloads/mysql/中选择【Source Code】平台，然后选择下载MySQL-8.0.13.tar.gz源码，如图所示。

2. 下载完MySQL-8.0.13.tar.gz后，创建MySQL安装程序的目录和数据文件的目录：

3. 解压缩MySQL源代码，这里使用cmake 2.8.4来编译MySQL源代码：

4. 创建MySQL安装程序的目录和数据文件的目录：

5. 安装MySQL 8.0的源码：

6. 启动MySQL 8.0服务：

7. 在Fedora操作系统中登录MySQL 8.0，默认用户root，密码为空，命令如下所示。

3.2、单机主从复制前的准备工作

MySQL服务器可以采用主从机制进行备份。一对一进行备份对于生成环境而言比较浪费资源，主服务器把数据变化记录到主日志，然后从服务器通过I/O线程读取主服务器的日志，并将它写入到从服务器的中继日志中，接着SQL线程读取中继日志，并且在从服务器上重放，从而实现MySQL复制，具体如图所示。

MySQL具有可以运行多个实例的功能，这个功能是通过MySQLd_multi实现的。当一台机器上需要运行多个MySQL服务器时，MySQLd_multi是管理多个MySQLd的服务进程，用不同的unix socket或是监听不同的端口，通过命令来启动、关闭和报告所管理的服务器的状态。

下面介绍如何在一台服务器上使用MySQLd_multi管理多个MySQL服务进程，具体操作步骤如下。

1. 初始化多实例数据库时，首先要停止MySQL服务器：

此时可以采用netstat命令查看3306关闭了没有，如果没有查询出结果，就说明MySQL服务器已经成功关闭。

2. 把常用到的工具添加到/usr/bin目录：

3. 初始化3个数据目录并安装3个MySQL服务：

4. 从MySQL的源码中把MySQLd_multi.server复制到/etc/init.d/目录下：

5. 配置数据库文件。直接配置/etc/my.cnf，修改相应的属性：

6. 查看数据库的状态：

此时，发现MySQL服务器不能够打开所需的文件，程序发生错误。

7. 使用MySQLd_multi启动MySQL服务器：

8. 测试MySQL服务器的状态：

[root@localhost ~]# netstat -an|grep 330

此时发现端口同时开启3306、3307、3308端口，在进程里面可以发现同时开启了两个MySQL_safe进程。

9. 登录查看MySQL数据库：

此时可以顺利登录到数据库，通过ps命令可以发现后台产生了3个MySQLd进程的实例。

10. 直接登录MySQL服务器，执行show variable命令，发现3个MySQL服务器的pid_file、socket参数都一样，命令执行如下：

此时，可以通过登录MySQL服务器自带参数解决以上的问题，命令执行如下所示。

由测试结果可知，问题已经解决了。接下来启动3个数据库，可以直接使用了：

[root@localhost ~]# mysqld_multi --defaults-extra-file=/etc/my.cnf stop 1-3[root@localhost ~]# mysqld_multi --defaults-extra-file=/etc/my.cnf star 1-3

3.3、MySQLd_multi实现单机主从复制

MySQL的复制至少需要两个MySQL服务，这些MySQL服务可以分布在不同的服务器上，也可以在一台服务器上启动多个服务。

MySQL的复制（Replication）是一个异步的复制过程，从Master复制到Slave。在Master和Slave中的整个复制过程由3个线程完成，其中两个线程（Sql线程和IO线程）在Slave端，另一个线程（IO线程）在Master端。要实现复制过程，Master必须打开Binary Log功能，复制过程其实就是Slave从Master端获取bin日志，然后在自己服务器上完全顺序执行日志中所记录的各种操作。

在Fedora操作系统中使用MySQLd_multi单机实现主从复制的具体配置，如表所示。

下面采用MySQLd_multi实现单机MySQL服务器主从复制。

1. 使用MySQLd_multi开启上一节已经设定好的3个MySQL服务：

2. 登录Master主服务器，设置一个复制使用的账户，并授予REPLICATION SLAVE权限。这里创建一个复制用户rep1。

3. 修改Master主数据库服务器的配置文件my.cnf，开启BINLOG，并设置server-id的值。需要重启服务器之后才生效。

4. 在Master主服务器上，设置锁定有效。这个操作是为了确保没有数据库操作，以便获得一致性的快照。

5. 用show master status命令查看日志情况，查询得到主服务器上当前的二进制日志名和偏移量值。这个操作的目的是为了从数据库启动以后，从这个点开始进行数据的恢复。

6. 主数据库服务此时可以做一个备份，在服务器停止的情况下直接使用系统复制命令。

[root@localhost mysql1]#tar –cvf data.tar data

7. 主数据库备份完成后，主数据库恢复写操作。

mysql>unlocktables;Query OK,0rowsaffected(0.00sec)

8. 接下来继续编辑/etc/my.cnf文件，具体配置项如下：

9. 重启Master主服务器。

10. 对从数据库服务器做相应设置，此时需要指定复制使用的用户、主数据的IP地址、端口以及开始复制的日志文件和位置等，具体设置如下：

11. 在从服务器上执行show slave status\G命令查询从服务器的状态。


12. 此时发现从服务器已经成功设置，同时也可以执行show processlist \G命令查询从服务器的进程状态。

结果表明Slave已经连接上Master，开始接受并执行日志。

13. 此时可以测试复制服务的正确性。在Master主数据库上执行一个更新操作，观察是否在从服务器上同步。下面在主数据库的test库上创建一个测试表，然后插入数据。

14. 在从服务器上检测新的表是否被创建、数据是否同步。

从结果可以看出，端口为3306 Master主机上的数据已经可以正确地同步到端口为3307的Slave主机的数据库上，复制服务配置成功完成。另外一个端口为3308的从机的配置跟端口为3307的一样操作，这里不再重复叙述。

3.4、不同服务器之间实现主从复制

在大多数情况下，采用不同的MySQL主从复制比较常见。不同IP地址的服务器上的MySQL服务器实现一对一复制跟上一节比较相似，具体的配置步骤如下。

1. 确保主从服务器上安装了相同版本的数据库，设定主服务器的IP是192.168.1.100，从服务器的IP是192.168.1.101。

2. 登录主服务器，设置一个复制使用的账户，并授予REPLICATION SLAVE权限。这里创建一个复制用户rep1。

3. 修改主数据库服务器的配置文件my.cnf，开启BINLOG，并设置server-id的值。需要重启服务器之后才生效。

在my.cnf中修改配置项如下：

[mysqld] log-bin = /usr/local/var/mysql1/mysql-bin server-id = 1

4. 在主服务器上，设置锁定有效。这个操作是为了确保没有数据库操作，以便获得一致性的快照。

mysql>flush tables withreadlock;Query OK,0rows affected(0.00sec)

5. 查询主服务器上当前的二进制日志名和偏移值。这个操作的目的是为了在从数据库启动以后，从这个点进行数据库的恢复。

6. 主数据库停止更新操作，生成数据库的备份。可以通过MySQLdump导出数据或者使用ibbackup工具进行数据库的备份。如果主数据库停止，那么可以直接使用cp命令将数据文件复制到从数据库服务器上。

主数据库备份完成后，主数据库恢复写操作，命令执行如下：

mysql>unlock tables;Query OK,0rows affected(0.00sec)

7. 修改从数据库的配置文件my.cnf，增加server-id参数。server-id的值是唯一的，不能和主数据库的配置相同，如果有多个从数据库，那么每个从数据库都必须有自己唯一的server-id值。

my.cnf [mysqld] Server-id = 2

8. 在从服务器上，使用–skip-slave-start选项启动从数据库，这样不会立即启动从数据服务上的复制进程，方便我们对从数据库的服务进行进一步的配置。

[root@localhost ~]# mysqld_safe --skip-slave-start &

9.对从数据库服务器做相应的设置，指定复制使用的用户、主数据库服务器的IP和端口，以及开始执行复制的日志文件和位置。

10. 在从服务器上启动slave线程。

mysql>start slave;Query OK,0rows affected(0.00sec)

11. 在从服务器上执行show slave status\G命令，查询从服务器的状态。

mysql>show slave status\G;

此时也可以执行show processlist \G命令查询从服务器的进程状态。

mysql>show processlist\G;

接下来可以测试复制服务的正确性，在主数据库上执行一个更新操作，观察是否在从数据库上同步。具体方法与上一节相似，这里不再重复讲述。

3.5、MySQL主要复制启动选项

MySQL安装配置的时候，已经介绍了几个启动时的常用参数，其中包括MASTER_HOST、MASTER_PORT、MASTER_USER、MASTER_PASSWORD、MASTER_LOG_FILE和MASTER_LOG_POS。这几个参数需要在从服务器上配置，下面介绍几个常用的启动选项，如log-slave-updates、master-connect-retry、read-only和slave-skip-errors等。

• log-slave-update：slog-slave-updates参数主要用来配置从服务器的更新是否写入二进制日志，该选项默认是不打开的，如果这个从服务器同时也作为其他服务器的主服务器，搭建一个链式的复制，那么就需要开启这个选项，这样从服务器才能获取它的二进制日志进行同步操作。
• master-connect-retry：master-connect-retry参数是用来设置在和主服务器连接丢失的时候重试的时间间隔，默认是60秒。
• read-onlyread-only用来限制普通用户对从数据库的更新操作，以确保从数据库的安全性，不过如果是超级用户，依然可以对从数据库进行更新操作。如果主数据库创建了一个普通用户，在默认情况下，该用户可以更新从数据库中的数据；使用read-only选项启动从数据库以后，该用户对从数据库的更新会提示错误。
  使用read-only选项启动的语法如下：

[root@localhost ~]#mysqld_safe –read-only&

• slave-skip-errors在复制的过程中，从服务器可能会执行BINLOG中错误的SQL语句，此时如果不忽略错误，从服务器将会停止复制进程，等待用户处理错误。这种错误如果不能及时发现，将会对应用或者备份产生影响。slave-skip-errors的作用就是用来定义复制过程中从服务器可以自动跳过的错误号。设置该参数后，MySQL会自动跳过所配置的一系列错误，直接执行后面的SQL语句。该参数可以定义多个错误号，如果设置成all，就表示跳过所有的错误，具体语法如下：

vi/etc/my.cnf slave-skip-errors=1007,1051,1062

如果从数据库主要是作为主数据库的备份，那么不应该使用这个启动参数，设置不当的话很可能会造成主从数据库的数据不同步。如果从数据库仅仅是为了分担主数据库的查询压力，并且对数据的完整性要求不是很严格，那么这个选项可以减轻数据库管理员维护从数据库的工作量。

3.6、指定复制的数据库或者表

MySQL数据库可以指定需要复制到从数据库上的数据库或者表，有时候用户只需要将主数据库中的某些关键表复制到从服务器上，或者只需要将某些提供查询的表复制到主数据库上，经常可以使用replicate-do-db、replicate-do-table、replicate-ignore-db、replicate-ignore-table或replicate-while-do-table来指定复制的数据或者表。

3.6.1、replicate-do-table和replicate-ignore-table的用法

1. 启动主从数据库，首先在主数据库test库中创建两个表——rep_t1和rep_t2。

2. 关闭数据库服务器，编辑从数据库配置参数，replicate-do-table=test.rep_t1指定test数据库中的rep_t1表被复制，replicate-ignore-table=test.rep_t2指定test库中的rep_t2表不会被复制。

3. 启动从服务器线程。

4. 主从服务器都成功启动后，开始更新主数据库test库中的rep_t1表和rep_t2表，具体数据如下：

5. 登录从数据库，查询test库中的表rep_t1和rep_t2的数据更新情况，具体查询语句如下：

从测试的结果可以看到，主表中的rep_t1数据已经复制到从服务器上了，而rep_t2中的数据没有被复制。

3.6.2、replicate-do-db和replicate-ignore-db的用法

1. 启动主从数据库服务器，查询主数据库中主要有哪些数据库。

2. 使用MySQLdump工具将主数据库中的所有信息导出到all.sql脚本文件中。

[root@localhost ~]# mysqldump -u root -P 3306 -S /tmp/mysql.sock --all-databases>all.sql

3. 登录从数据库，导入all.sql中的数据，保持从服务器与主数据库数据一致。

4. 关闭从数据库，然后编辑数据库的配置文件。replicate-do-db表示从服务器可以复制的数据库的名字，如果有多个数据库，那么可以重复写多个replicate-do-db配置。replicate-ignore-db表示在从服务器复制过程中忽略复制该配置设置的数据库名称。

5. 启动主从数据库，然后在主数据库cc库中增加表cc_t1表，在tt库中增加表tt_t1表。

6. 登录从数据库，查询数据库cc库和tt库相应的数据是否更新。

4、查看Slave的复制进度

很多情况下，用户都想知道从服务器复制的进度，从而判断从服务器上复制数据的完整性，同时判断是否需要手工来做主从的同步工作。事实上，用户可以通过SHOWPROCESSLIST列表中的Slave_SQL_Running线程的Time值得到，它记录了从服务器当前执行的SQL时间戳与系统时间之间的差距。下面通过例子测试一下这个时间的准确性。

1. 在主服务器上插入一个包含当前时间戳的记录。

2. 从服务器的IO线程停止，使得从数据库服务器暂时不写中继日志，停止时执行的SQL就是最后执行的SQL，命令执行如下：

3. 在从数据库服务器上执行show processlist查看SQL线程的时间。这个时间说明了主服务器最后执行的更新操作大概是主服务器46秒前的更新操作。

5、日常管理和维护

数据复制环境配置完成后，数据库管理员需要进行日常的监控和管理维护工作，以便能够及时发现和解决问题，从而保证主从数据库能够正常工作。有时候会因为主服务器的更新过于频繁而造成从服务器更新速度较慢。当然，问题是多种多样的，有可能是网络搭建的结构不好或者硬件的性能较差，从而使得主从服务器之间的差距越来越大，最终对某些应用产生了影响，在这种情况下，用户需要定期进行主从服务器的数据同步操作。

5.1、了解服务器的状态

一般使用show slave status命令来检查从服务器，如下所示。

在从服务器信息中，首先要查看“Slave_IO_Running”和“Slave_SQL_Running”这两个进程状态是否是“yes”​。Slave_IO_Running表明此进程是否能够由从服务器到主服务器上正确地读取BINLOG日志，并写入到从服务器的中继日志中。Slave_SQL_Running表明能否读取并执行中继日志中的BINGOG信息。

5.2、服务器复制出错的原因

在某些情况下，会出现从服务器更新失败，此时首先需要确定是否是主从服务器的表不同造成的。如果是表结构不同导致的，就修改从服务器上的表与主服务器上的表一致，然后重新执行START SLAVE命令。服务器复制出错的常见问题如下。

问题一：出现“log event entry exceededmax_allowed_pack”错误。

如果在应用中使用大的BLOG列或者长字符串，那么在从服务器上回复时可能会出现“log event entry exceededmax_allowed_pack”错误，这是因为含有大文本的记录无法通过网络进行传输，解决方法是在主从服务器上添加 max_allowed_packet参数（默认设置是1MB）​，具体如下：

同时，在my.cnf里设置max_allowed_packet=16MB，数据库重新启动之后该参数将有效。

问题二：多主复制时的自增长变量冲突问题。

大多数情况下使用一台主服务器对一台或者多台从服务器，但是在某些情况下可能会将多个服务器配置为复制主服务器，所以使用auto_increment时应采取特殊步骤以防止键值冲突，否则插入行时多个主服务器会试图使用相同的auto_increment值。

服务器变量auto_increment_increment和auto_increment_offset可以协调多主服务器复制和auto_increment列。

在多主服务器复制到从服务器过程中，迟早会发生主键冲突，为了解决这种情况，可以重新设置不同主服务器的这两个参数，比如在A数据库服务器上设置auto_increment_increment=1、auto_increment_offset=1，在B数据库服务器上设置auto_increment_increment=1、auto_increment_offset=0。

下面的例子演示修改这两个参数后的效果。

1. 创建表auto_t，系统默认的auto_increment_increment和auto_increment_offset参数都是1，增加数据默认的也是增加幅度为1，命令执行如下：

2. 重新设置参数auto_increment_increment的值为10，然后插入数据。

从测试效果看，每次递增值是10。下面看参数auto_increment_offset的用法。

3. 重新设置参数auto_increment_offset的值为5，再插入数据。

从插入的记录可以看出，auto_increment_increment参数是每次增加的量，而参数auto_increment_offset参数设置的是每次增加后的偏移量，也就是每次按照10累加后，还需要增加5个偏移量。

6、切换主从服务器

在实际工作环境中，有时候遇到这样的问题：在一个工作环境中，有一个主数据库服务器A，两个从数据库服务器B、C同时指向主数据库服务器，当主数据库服务器A发生故障时，需要将其中的一个从数据库B服务器切换成主数据库，同时修改数据库C服务器的配置，使其指向新的主数据库B。

下面介绍一下切换主从服务器的具体操作步骤。

1. 首先要确保所有的从数据库都已经执行了relaylog中的全部更新，查看从数据库的状态是否是Has readall relay log（是否更新都已经执行完成）​。

2. 在从数据库B上停止slave服务，然后执行resetmaster，重置成主数据库。

此时报错Binlog没有设置，不能够执行reset master命令。下面关闭数据库服务，然后修改/etc/my.cnf，在[MySQL2]后面的配置选项中添加log-bin选项。

[mysqld2] … log-bin = /usr/local/var/mysql2/mysql-bin

配置完成后，重启数据库服务，登录数据库B，然后执行如下命令开启主数据库功能。

此时从数据库B已经成功切换成为主数据库，下面接着设置从数据库。

3. 在从数据库B上添加具有replication权限的用户rep1，查询主数据库状态。

4. 在从数据库C上配置复制的参数。

5. 在从数据库C上执行show slave status命令，查看从数据库服务是否成功启动。

6. 在主数据库B和从数据库C上面测试数据库是否成功设置复制功能。首先，查看主数据库B中test库中表的情况。

然后，查询从数据库C中test库中表的情况。

mysql>usetest;Database changed mysql>show tables;Emptyset(0.01sec)

7. 在主数据库B中增加表rep_t3。

mysql>create table rep_t3(data int);Query OK,0rows affected(0.01sec)

8. 在从数据库C中查询，看看表是否成功复制到从数据库。

至此，主从数据库成功地发生切换。最后，如果主数据库A可以修复，可以考虑采用以上方法将A数据库配置成为B数据库的从数据库。

7、多源复制的改进

在早期的版本中，MySQL服务器的复制只能在一个主服务器和多个从服务器之间实现。图中所示为一个主服务器和多个从服务器的复制情况。

MySQL 8.0添加了多源复制功能，可以实现多主服务器和一从服务器的复制。下图所示为一个从服务器和多个主服务器的复制情况。

多源复制功能的优势如下：

1. 如果在主服务器进行了分库分表的操作，可以在从服务器进行数据汇总。为了实现后期的一些数据统计功能，往往需要把数据汇总在一起再统计。
2. 在从服务器时对主服务器的数据进行备份，在MySQL 8.0之前每一个主服务器都需要一个从服务器，很容易造成资源浪费，同时也加大了数据库管理员的维护成本；MySQL 8.0则引入了多源复制，可以把多个主服务器的数据同步到一个从服务器进行备份。

下面举例说明。首先，配置两个主服务器和一个从服务器：

• 主服务器Master1: 192.168.10.101。
• 主服务器Master2: 192.168.10.102。
• 从服务器Slave: 192.168.10.103。

1. 在Master1上导出需要同步的数据库：

2. 在Master2上导出需要同步的数据库：

3. 分别在Master1和Master2上把备份文件复制到Slave上：

4. 在Master1上创建复制账号：

5. 在Master2上创建复制账号：

6. 后续操作将把Master1和Master2的数据导入Slave服务器。在导入前先修改MySQL存储master-info和relay-info的方式，即从文件存储改为表存储，在my.cnf里添加以下设置：

master_info_repository=TABLE relay_log_info_repository=TABLE

7. 在Slave上进行数据导入：

8. 分别找出Master1和Master2的binlog位置和Pos位置：

9. 登录Slave进行同步操作，分别执行CHANGEMASTER到两台Master服务器：

10. 通过start slave的方式去启动所有的复制：

正常启动后，可以查看复制源Master1和Master2的同步状态，命令如下：

SHOWSLAVESTATUSFORCHANNEL'Master1'\GSHOWSLAVESTATUSFORCHANNEL'Master2'\G

MySQL 8.0的多源复制能有效地解决分库分表的数据统计问题，同时也可以实现在一台从服务器对多台主服务器的数据备份。