MySQL之复制(二)

复制

配置复制

为MySQL服务器配置复制非常简单。但由于场景不同，基本的步骤还是有所差异的。最基本的场景是新安装的主库和备库，总的来说分为以下几步:

• 1.在每台服务器上创建复制账号
• 2.配置主库和备库
• 3.通知备库连接到主库并从主库复制数据

这里我们假定大部分配置采用默认值即可，在主库和备库都是全新安装并且拥有同样的数据(默认MySQL数据库)时这样的假设时合理的。假设有服务器server1(IP地址192.168.0.1)和服务器server2(IP地址192.168.0.2).

创建复制账号

MySQL会赋予一些特殊的权限给复制线程。在备库运行的IO线程会建立一个到主库的TCP/IP连接，这意味着必须在主库创建一个用户，并赋予其合适的权限。备库IO线程以该用户名连接到主库并读取其二进制日志。通过如下语句创建用户账号:

mysql>GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@'192.168.0.%' IDENTIFIED BY 'p4ssword';

我们在主库和备库都创建该账号。注意我们把这个账户限制在本地网络，因为这是一个特权账号(尽管该账号无法执行select或修改数据，但仍然能从二进制日中获得一些数据)。复制账户事实上只需要有主库上的REPLICATION SLAVE权限，并不一定需要每一端服务器都有REPLICATION CLIENT权限，那为什么我们要把这两种权限给主/备库都赋予呢？这有两个原因:

• 1.用来监控和管理复制的账号需要REPLICATION CLIENT权限，并且针对这两种目的的使用同一个账号更加容易(而不是为某个目的单独创建一个账号)
• 2.如果在主库上建立了账号，然后从主库将数据克隆到备库上时，备库也就设置好了——变成主库所需要的配置。这样后续有需要可以方便地交换主备库的角色

配置主库和备库

下一步需要在主库上开启一些设置，假设主库是服务器server1,需要打开二进制日志并指定一个独一无二的服务器ID(serverID)，在主库的my.cnf文件中增加或修改如下内容:

log_bin = mysql-bin
server_id = 10

实际取值由你决定，这里只是为了简单起见，当然也可以设置更多需要的配置。必须明确地指定一个唯一的服务器ID,默认服务器ID通常为1(这和版本相关，一些MySQL版本根本不允许使用这个值)。使用默认值可能会导致和其他服务器的ID冲突，因此这里选择10来作为服务器ID.一种通用的做法是使用服务器IP地址的末8位，但要保证它是不变且唯一的(例如，服务器都在一个子网里)。最好选择一些有意义的约定并遵循。
如果之前没有在MySQL的配置文件中指定log_bin选项，就需要重新启动MySQL.为了确认二进制日志吻技安是否已经在主库上创建，使用SHOW MASTER STATUS命令，检查输出是否与如下的一直。MySQL会为文件名增加一些数字，所以这里看到的文件名和你定义的会有点不一样:

mysql>SHOW MASTER STATUS;
File:mysql-bin.000001
Position:98
Binlog_Do_DB:
Binlog_Ignore_DB:

备库上也需要在my.cnf中增加类似的配置，并且同样需要重启服务器。

log_bin = mysql-bin
server_id = 2
relay_log = /var/lib/mysql/mysql-relay-bin
log_slave_updates = 1
read_only =1

从技术上来说，这些选项并不总是必要的。其中一些选项只是显式地列出了默认值。事实上只有server_id是必需地。这里我们同样也使用了log_bin，并赋予一个明确的名字。默认情况下，它是根据机器名来命名的，但如果机器名变化了可能会导致问题。为了简便起见，将主库和备库上的log-bin设置为相同的值。当然如果你愿意的化，也可以设置成别的值。另外我们还增加了两个配置选项:relay_log(指定中继日志的位置和命名)和log_salve_updates(允许备库将其重放的事件也记录到自身的二进制日中中)，后一个选项会给备库增加额外的工作，但正如后面将会看到的，我们有理由为每个备库设置该选项。
有时候只开启了二进制日志，但却没有开启log_slave_updates,可能会碰到一些奇怪的现象，例如，当配置错误时可能会导致备库数据被修改。如果可能的化，最好使用read_only配置选项，该选项会阻止任何没有特权权限的线程修改数据(所以最好不要给予用户超出需要的权限)。但read_only选项常常不是很使用，特别是对于那些需要在备库建表的应用。
(不要再配置文件my.cnf中设置master_port或master_host这些选项，这是老的配置方式，已经被废弃，它只会导致问题，不会有任何好处)

启动复制

下一步是告诉备库如何连接到主库并重放其二进制日志。这一步要通过修改my.cnf来配置，而是使用CHANGE MASTER TO语句，该语句完全替代了my.cnf中相应的设置，并且允许以后指向别的主库时无须重启备库。下面时开始复制的基本命令:

mysql> CHANGE MASTER TO MASATER_HOST = 'server1', MASTER_USER='repl',MASTER_PASSWORD='p4ssword',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=0;

MASTER_LOG_POS参数被设置为0，因为要从日志的开头独起。当执行完这条语句后，可以通过SHOW SLAVE STATUS语句来检查复制是否正确执行

mysql>SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host:server1
Master_User:repl
Master_Port:3306
Connect_Retry:60
Master_Log_File:mysql-bin.000001
Read_Master_Log_Pos:4
Relay_Log_File:mysql-relay-bin.000001
Relay_Log_Pos:4
Relay_Master_Log_File:mysql-bin.000001
Slave_IO_Running:No
Slave_SQL_Running:No
.......
Seconds_Behind_Master:NULL

Slave_IO_State、Slave_IO_Running和Slave_SQL_Running这三列显示当前备库复制尚未运行。可鞥已经注意到日志的开头是4而不是0，这是因为0其实不是日志真正开始的位置，它仅仅意味着"在日志文件头"，MySQL知道第一个事件从文件的第4位(事实上，正如之前从SHOW MASTER STAUS看到的，真正的日志起始位置是98，一旦备库连接到主库就开始工作，现在连接还未发生)开始读。

运行下面的命令开始复制:

mysql> START SLAVE;

执行该命令没有显示错误，现在我们再用SHOW SLAVE STATUS命令检查:

mysql>SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host:server1
Master_User:repl
Master_Port:3306
Connect_Retry:60
Master_Log_File:mysql-bin.000001
Read_Master_Log_Pos:164
Relay_Log_File:mysql-relay-bin.000001
Relay_Log_Pos:164
Relay_Master_Log_File:mysql-bin.000001
Slave_IO_Running:Yes
Slave_SQL_Running:Yes
.......
Seconds_Behind_Master:0

从输出可以看到IO线程和SQL线程都已经开始运行，Seconds_Behind_Master的值也不再为NULL。IO线程正在等待从主库传递过来的事件，这意味着IO线程已经读取了主库所有的事件。日志位置发生了变化，表明已经从主库获取和执行了一些事件.如果在主库上做一些数据更新，就会看到备库的文件或者日志位置都可能会增加。备库的数据同样会随之更新。我们还可以从线程列表中看到复制线程。在主库上可以看到由备库IO线程向主库发起的连接:

mysql>SHOW PROCESSLIST\G
*************************** 1. row ***************************
Id:55
User:repl
Host:replica1.webcluster_1:54813
db:NULL
Command:Binlog Dump
Time:610237
State:Has sent all binlog to slave;waiting for binlog to be updated
Info:NULL

同样，在备库也可以看到两个线程，一个是IO线程，一个是SQL线程:

mysql>SHOW PROCESSLIST\G
*************************** 1. row ***************************
Id:1
User:system user
Host:
db:NULL
Command:Connect
Time:611116
State:Waiting for master to send event
Info:NULL
*************************** 2. row ***************************
Id:2
User:system user
Host:
db:NULL
Command:Connect
Time:33
State:Has read all relay log; waiting for the slave I/O thread to update it
Info:NULL

这些简单的输出来自一台已经运行了一段时间的服务器，所以IO线程在主库和备库上的Time列的值较大，SQL线程已经空闲了33秒。这意味着33秒内没有重放任何事件。这些线程总是运行在"system user"账号下，其他列的值则不相同。例如，在SQL线程回放事件时，Info列可能显示正在执行的查询。