MySQL 5.5 手册17.1.1：如何设置复制（Replication）

注意：

1. 本文的原文是MySQL 5.5官方手册中的17.1.1 http://dev.mysql.com/doc/refman/5.5/en/replication-howto.html。

2. 本文的超链接全部来自于原文，超链接对应的文章没有进行翻译，但是如果超链接如果在17.1.1.1-17.1.1.10之中，那全都翻译了，继续阅读本文即可。

目录：

17.1.1.1 Setting the Replication Master Configuration

17.1.1.2 Setting the Replication Slave Configuration

17.1.1.3 Creating a User for Replication

17.1.1.4 Obtaining the Replication Master Binary Log Coordinates

17.1.1.5 Creating a Data Snapshot Using mysqldump

17.1.1.6 Creating a Data Snapshot Using Raw Data Files

17.1.1.7 Setting Up Replication with New Master and Slaves

17.1.1.8 Setting Up Replication with Existing Data

17.1.1.9 Introducing Additional Slaves to an Existing Replication Environment

17.1.1.10 Setting the Master Configuration on the Slave

这一节描述了如何完整地配置MySQL的Replication。设置复制的方法很多，具体用哪种方法取决于你如何配置，以及你的主库中是否有数据。

不管什么方法，以下这些配置是通用的，都要完成。

• 主库必须要开启二进制日志，并赋予一个唯一的服务器ID。配置好后可能需要重启MySQL。细节可查看Section 17.1.1.1, “Setting the Replication Master Configuration”.
• 要给所有的从库都赋予一个唯一（主、从库的ID全都不能相同）的服务器ID。配置好后可能需要重启MySQL。细节可查看Section 17.1.1.2, “Setting the Replication Slave Configuration”.
• 最好在主库上为从库创建一个复制专用的数据库账户。这一步是可选的。细节可查看Section 17.1.1.3, “Creating a User for Replication”.
  
• 在创建数据快照（data snapshot）或启动复制线程（replication process）之前，必须要先记录下主库的二进制日志座标。配置从库的时候，这个值可以让从库知道从主库二进制日志的什么地方开始执行事件。细节可查看Section 17.1.1.4, “Obtaining the Replication Master Binary Log Coordinates”.
• 如果主库中已经有数据，并且一并同步到从库中，这是需要创建一个数据快照（data snapshot）。可以使用mysqldump创建快照（参见Section 17.1.1.5, “Creating a Data Snapshot Using mysqldump”）或直接拷贝数据文件（参见Section 17.1.1.6, “Creating a Data Snapshot Using Raw Data Files”）。
• 最后需要配置从库如何连接到主库，包括主机名、登录认证信息、二进制日志文件名和二进制日志座标。细节可查看Section 17.1.1.10, “Setting the Master Configuration on the Slave”.

如果你配置好了以上的基本内容，就可以进行继续的配置，以下是一些可选的步骤：

• 如果你的主库是空的，且有一个或多个从库，你只需要进行以下配置：Section 17.1.1.7, “Setting Up Replication with New Master and Slaves”.
• 如果主库已经有数据但以前从未开启过二进制日志，但还需要将这些数据复制到从库，可以参考这里：Section 17.1.1.8, “Setting Up Replication with Existing Data”.注意：此种方法需要关闭主库一段时间。
• 如果需要将一个从库加入到已有的复制环境中，可以这样配置且不影响主库工作：Section 17.1.1.9, “Introducing Additional Slaves to an Existing Replication Environment”.

如果你打算管理MySQL复制服务器，我们建议你阅读整章，以及Section 13.4.1, “SQL Statements for Controlling Master Servers”和Section 13.4.2, “SQL Statements for Controlling Slave Servers”提到的内容。你还应该熟悉一些和复制有关的启动参数：Section 17.1.3, “Replication and Binary Logging Options and Variables”.

注意：
配置时的有些步骤需要超级用户SUPER的权限。如果没有这个权限，可能会导致配置失败。

17.1.1.1 配置主库（Setting the Replication Master Configuration）

主库必须要开启二进制日志，并赋予一个唯一的server ID。完成这一步最后或许需要重启MySQL。

必须要开启二进制日志的原因是：二进制日志是主、从库之间传递数据的根本。如果没有二进制日志，复制就不可能进行。

复制组（replication group）中的每一个server都必须要有一个唯一的server ID。这个ID用来区分复制组中不同server的身份，server ID的取值范围是1~2^32-1中间的任意整数（注意，在MySQL 5.6以后，用server_uuid取代了server_id，且是自动生成，无需手动配置——译者注）。怎么配置这些值完全取决于你自己。要配置二进制日志和serverid选项，需要关闭MySQL，然后编辑my.cnf或my.ini。下面的这两个参数都在[mysqld]节点下。如果这两个参数被注释掉了，那么请取消注释并按照你的需要配置相应的参数。例如，要规定二进制文件的前缀是"mysql-bin"，且server id为1，应该这么配置：

[mysqld]
log-bin=mysql-bin
server-id=1

修改参数后，重启MySQL。

注意一：
如果删除server-id或配置为0，那么主库将会拒绝任何从库的连接。

注意二：
为了保证InnoDB事务一致性的质量，建议把my.cnf中的innodb_flush_log_at_trx_commit和sync_binlog都配置为1。

注意三：
确保主库上的skip-networking参数没有被禁用。如果这个参数被禁用，主、从库之间将无法通信，导致复制失败。

17.1.1.2 配置从库（Setting the Replication Slave Configuration）

从库必须要有一个唯一的server ID。完成这一步最后或许需要重启MySQL。

如果从库没有server id，或者和主库的id冲突，需要关闭MySQL并重选一个id，例如：

[mysqld]
server-id=2

修改参数后重启MySQL。

如果要配置多个从库，则每个都要有一个唯一的server-id。且互不相同。可以把server-id类比为IP：ID就是复制组中的唯一标识码。

注意：
如果删除了server-id或配置为0，该从库将会拒绝连接任何主库。

从库可以不用开启二进制日志。不过，如果启用了从库的二进制日志，可以用来进行数据备份或崩溃后的恢复，统一可以创建更复杂的复制拓扑，如改从库是其他从库的主库。

17.1.1.3 创建复制专用账户（Creating a User for Replication）

从库连到主库必须要有MySQL的用户名和密码，因此主库上需要有一个账户用来进行复制。任何有REPLICATION SLAVE权限的账户都可以。每个从库可以有自己的用户名，也可以所有从库共用同一个用户名。

复制并不需要一个单独的用户名，但是用于复制的用户名和密码都会被以明文的方式存储在master.info中（可参见Section 17.2.2.2, “Slave Status Logs”）。因此最好为复制创建一个独立的用户名，并且仅赋予最小权限（即REPLICATION SLAVE）。

用CREATE USER可以创建新用户，之后用GRANT赋权。如果这个用户名只用来复制，那么REPLICATION SLAVE权限就足够了。例如：创建一个名为repl，密码是slavepass，可以在mydomain.com域下使用的用户语句如下：

mysql> CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.mydomain.com';

关于用户账户的更多细节，请参见Section 13.7.1, “Account Management Statements”。

17.1.1.4 获得主库的二进制日志座标（Obtaining the Replication Master Binary Log Coordinates）

在从库上配置复制时，需要配置主库的二进制日志座标。这个值可以保证从库从二进制日志的正确位置读取信息。

如果主库上有一些数据是在复制以前产生的，而且也需要同步到从库，需要先停止主库上的相关操作（stop processing statements on the master），获取二进制日志座标，转存数据（dump its data）。如果没有停止运行部分，将会导致最终从库数据的不正确。

以下步骤可以获得主库的二进制日志座标：

1. 用命令行客户端连接到主库上，并使用FLUSH TABLES WITH READ LOCK情况所有表和块，锁定所有表

          mysql> FLUSH TABLES WITH READ LOCK;

           值得注意的是InnoDB表中，FLUSH TABLES WITH READ LOCK还会锁定COMMIT操作

警告
保证你执行FLUSH TABLES的客户端一直处于激活状态，这样读锁才能一直起作用。如果你退出了客户端，那么锁就被释放了。

        2. 在另外一个连接到主库的会话中，用SHO MASTER STATUS查看二进制日志的名称和位置：

mysql > SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 73       | test         | manual,mysql     |
+------------------+----------+--------------+------------------+

File列显示了日志文件的文件名，Position则记录了日志中的位置。在这个例子中，二进制文件名为mysql-bin.000003，位置是73。记录下这些值，在一会配置从库时会用到。这些值表示从库读取日志时的起点。

如果主库在开启二进制日志前就运行了，SHOW MASTER STATUS或mysqldump --master-data将会返回空值。这种情况下，一会填写日志文件名和位置的时候，请使用空字符串（‘’）和4。

现在已经获得了二进制日志座标。

如果在复制开始前，就有数据，且需要同步到从库，保持读锁，并参见Section 17.1.1.5, “Creating a Data Snapshot Using mysqldump”或Section 17.1.1.6, “Creating a Data Snapshot Using Raw Data Files”。这么做是为了防止任何进一步的改变，以保证从库和主库同步。

如果主库什么都没有，那么可以退出最早的会话释放读锁。

17.1.1.5 使用mysqldump创建数据快照（Creating a Data Snapshot Using mysqldump）

为主库的已有数据创建快照的方法之一是使用mysqldump。一旦dump结束，可以在从库复制前导入这些数据。

下面的例子演示了将所有的数据库dump到一个叫dbdump.db的文件中，其中的--master-date参数会自动添加CHANGE MASTER TO信息。

shell> mysqldump --all-databases --master-data > dbdump.db

如果不使用--master-data，则需要在一个独立的会话（sessing）中手动的使用FLUSH TABLES WITH READ LOCK锁定所有的表再运行mysqldump，然后退出或在另外一个会话中使用UNLOCK TABLES解锁。同时需要使用SHOW MASTER STATUS，以获取从库CHANGE MASTER TO的必要参数值。

如果dump不是包含所有的数据库，那么复制的时候也要注意，不要包含所有的库。

导入数据既可以将dump文件拷到从库，也可以从主库远程连接到从库。

17.1.1.6 使用原始数据文件创建数据快照（Creating a Data Snapshot Using Raw Data Files）

如果你的数据库很大，直接拷贝原始数据文件将会比mysqldump高效得多。这种方法可以越过索引对INSERT造成的限制（This technique skips the overhead of updating indexes as theINSERT statements are replayed.）

为了能让存储引擎中的表使用这种方法与复杂的缓存和日志算法一起形成一个完美的“时间点”，还需要一些额外的步骤：即使设定了全局读锁，也可能在拷贝的时候遗漏缓存数据和日志更新。存储引擎如何响应这些，取决于它防崩溃的水平。

这种方法不太适合以下几种情况：主库和从库的ft_stopword_file、ft_min_word_len和ft_max_word_len参数不同，或者拷贝的表中有全文索引。

如果表的引擎是InnoDB，那么可以考虑使用MySQL商业版中的mysqlbackup创建快照。详情可见Section 25.2, “MySQL Enterprise Backup，

另外，可以使用冷备份方法获得InnoDB表相关的二进制快照：在MySQL慢关闭以后，拷贝所有的数据文件。

为MyISAM表创建一个原始数据快照的方法很多，可以使用标准的复制工具如cp或copy，远程复制工具如scp或rsync，压缩工具如zip或tar，或文件系统快照工具如dump。如果只备份一部分库，则只备份与这些表相关的文件即可（InnoDB的所有数据都存储在系统表空间文件中，除非你开启了innodb_file_per_table选项）。

备份的时候要记得排除以下文件：

• mysql系统库
• master.info文件
• 主库的二进制文件
• 所有的relay log文件

为了获得最准确的原始数据快照，需要关闭主库，之后按照以下描述操作：

1. 取得读锁并获得主库的状态，可参见Section 17.1.1.4, “Obtaining the Replication Master Binary Log Coordinates”

2. 在一个独立的会话关闭主库

shell> mysqladmin shutdown

3. 拷贝MySQL的数据文件。可以照后面的语句做，但你只需要执行其中一条语句即可

shell> tar cf /tmp/db.tar ./data
shell> zip -r /tmp/db.zip ./data
shell> rsync --recursive ./data /tmp/dbdata

4. 重启主库。

如果没有使用InnoDB表，则获取快照时可以不用关闭服务器，按照以下步骤操作即可：

1. 取得读锁并获得主库的状态，可参见Section 17.1.1.4, “Obtaining the Replication Master Binary Log Coordinates”

2. 拷贝MySQL的数据文件。可以照后面的语句做，但你只需要执行其中一条语句即可

shell> tar cf /tmp/db.tar ./data
shell> zip -r /tmp/db.zip ./data
shell> rsync --recursive ./data /tmp/dbdata

3. 解锁主库。

mysql> UNLOCK TABLES;

最后，将备份好的数据文件拷贝到从库。

17.1.1.7 用新主库和从库搭建复制环境（Setting Up Replication with New Master and Slaves）

搭建复制环境最简单直接的方法就是使用新的主库和从库。

这个方法还可以用于向复制环境中导入其他服务器的数据。只需要将数据导入到主库中，就会被自动同步到所有的从库。

具体步骤如下（假设主库、从库全部处于关闭状态）：

1.  修改主库配置文件。参见：Section 17.1.1.1, “Setting the Replication Master Configuration”。

2.  启动主库。

3.  配置复制用账户。参见：Section 17.1.1.3, “Creating a User for Replication”。

4.  获得主库的状态信息。参见：Section 17.1.1.4, “Obtaining the Replication Master Binary Log Coordinates”。

5.  主库释放读锁

mysql> UNLOCK TABLES;

6.  修改从库配置文件。参见：Section 17.1.1.2, “Setting the Replication Slave Configuration”。

7.  启动从库。

8.  执行CHANGE MASTER TO语句为从库配置必要的主库信息。参见Section 17.1.1.10, “Setting the Master Configuration on the Slave”。

在所有的从库上重复6-8步。

由于主库是空的，所以不用导入任何信息。

向主库导入数据的步骤如下：

shell> mysql -h master < fulldb.dump

17.1.1.8  如何配置主库非空的复制环境（Setting Up Replication with Existing Data）

当主库中有数据时，就需要选择最好的方法，使数据能够完整的全部同步到从库。

最基本的操作方法如下：

1.  配置复制用账户。参见：Section 17.1.1.3, “Creating a User for Replication”。

2.  如果没有配置server-id或没有打开二进制日志，那么停止服务器，并配置他们。参见：Section 17.1.1.1, “Setting the Replication Master Configuration”。如果服务器没有启动，这时应该趁机创建一个快照，并获得服务器的主库状态（参见Section 17.1.1.4, “Obtaining the Replication Master Binary Log Coordinates”），更新配置文件。如何使用原始文件创建快照可以参见：Section 17.1.1.6, “Creating a Data Snapshot Using Raw Data Files”。

3.  如果主库已经配置好了，就应该先获得主库的状态（参见Section 17.1.1.4, “Obtaining the Replication Master Binary Log Coordinates”），然后使用mysqldump获得快照（参见Section 17.1.1.5, “Creating a Data Snapshot Using mysqldump”）或使用原始文件创建快照可以参见：Section 17.1.1.6, “Creating a Data Snapshot Using Raw Data Files”。

4.  修改从库配置文件。参见：Section 17.1.1.2, “Setting the Replication Slave Configuration”。

5.  接下来选用哪种方法，取决于你使用那种方式创建快照。如果使用mysqldump：

     a.  启动从库，使用--skip-slave-start选项确保复制没有同时启动

     b.  导入dump文件

      shell> mysql < fulldb.dump

     如果使用原始文件的方式：

     a.  在从库的数据目录解压备份文件，如：

      shell> tar xvf dbdump.tar

           请确保当前的系统账户有足够的权限，可以对相应的文件或文件夹进行修改

      b.  启动从机，使用--ship-slave-start以确保复制没有同时启动。

6.  使用CHANGE MASTER TO配置从库的二进制日志座标。参见：Section 17.1.1.10, “Setting the Master Configuration on the Slave”。

7.  启动从库线程：

mysql> START SLAVE;

完成以上步骤后，从库就可以连接到主库同步了。

如果没有设置主库的server-id，从库将找不到主库。如果从库没有配置server-id，将会在从库的日志中看到如下信息：

Warning: You should set server-id to a non-0 value if master_host
is set; we will force server id to 2, but this MySQL server will
not act as a slave.

如果还有其他原因导致复制失败，也可以在从库的错误日志中查找原因。

如果从库开始复制操作，则可以在数据目录看到一个名为master.info和relay-log.info的文件。从库用这两个文件记录主库日志它已经处理了多少。除非你真的知道删除或修改这两个文件带来的影响，否则绝对不要这么干。如果发生这种情况，推荐使用CHANGE MASTER TO语句，让从库自动更新状态文件。

注意：
master.info会覆写一些启动参数以及my.cnf的配置，详情请参见Section 17.1.3, “Replication and Binary Logging Options and Variables”。

多个从库可以共用同一个主库快照。给从库配置相同的座标即可。

17.1.1.9  为已有复制环境增加新的从库（Introducing Additional Slaves to an Existing Replication Environment）

下面介绍了如何在不停止主库的前提下，为复制环境新增从库。大致方法是：复制一个从库，修改server-id。

大概包括以下步骤：

1.  关闭一个从库

shell> mysqladmin shutdown

2.  把已有从库的数据目录拷贝到新从库中。方法很多，如cp、rsync、tar、zip。不管什么方法，记得拷贝的时候包括日志文件和relay log文件。

增加新从库时，容易出现新从库启动失败的问题，并出现如下错误信息

071118 16:44:10 [Warning] Neither --relay-log nor --relay-log-index were used; so
replication may break when this MySQL server acts as a slave and has his hostname
changed!! Please use '--relay-log=new_slave_hostname-relay-bin' to avoid this problem.
071118 16:44:10 [ERROR] Failed to open the relay log './old_slave_hostname-relay-bin.003525'
(relay_log_pos 22940879)
071118 16:44:10 [ERROR] Could not find target log during relay log initialization
071118 16:44:10 [ERROR] Failed to initialize the master info structure

这是因为--relay-log参数没指定（可参见Section 17.1.3, “Replication and Binary Logging Options and Variables”）。要避免这个问题发生，要保证新从库和旧从库有相同的--relay-log值。如果旧从库没有配这个值，那么使用existing_slave_hostname-relay-bin。要是这也不行，那就把旧从库的relay log的索引文件拷过去，并把--relay-log-index选项的值设置为旧从库相同的值。（如果旧从库上也没有配这个值，那么使用existing_slave_hostname-relay-bin.index）。如果已经完成了后面的3-6步，启动新从库，还碰到错误，那么试试以下步骤：

    a.  使用STOP SLAVE停止新从库和旧从库。

    b.  将旧从库的relay log index文件拷贝到新从库对应位置。

    c.  执行后面的步骤

3.  将旧从库的master.info和relay-log.info拷贝到新从库。

4.  启动旧从库。

5.  给新从库赋一个唯一的server-id。

6.  启动新从库。

17.1.1.10 为从库配置主库信息（Setting the Master Configuration on the Slave）

要想从库与主库正常通信，必须给从库足够的信息。可以用下面这些语句替代配置文件里的值

mysql> CHANGE MASTER TO
    ->     MASTER_HOST='master_host_name',
    ->     MASTER_USER='replication_user_name',
    ->     MASTER_PASSWORD='replication_password',
    ->     MASTER_LOG_FILE='recorded_log_file_name',
    ->     MASTER_LOG_POS=recorded_log_position;

注意：
Unix socket files不支持Replication，只能通过TCP/IP连接到主库的MySQL

CHANGE MASTER TO还有其他选项。例如可以配置SSL。详情可参见：Section 13.4.2.1, “CHANGE MASTER TO Syntax”。