兰若寺

Chapter 7. Replication

7.1 Replication Overview
Replication 最基本的结构是由两台服务器组成，一主和一从。主服务器将所有的查询记录下来并存为二进制日志。从服务器连接到主服务器，并从二进制日志将查询提取出来，然后在本地的数据拷贝上执行查询。

7.1.1 Problems Solved with Replication
Replication 虽然不很完美，但它可以有效解决有关备份和规模可伸缩性的问题。

7.1.1.1 Data distribution
就数据分发而言，Replication 对网络要求不高，无须一直“在线”。你也可以在一台服务器上对两个单独的 MySQL 服务进行 replication，这是一个测试新版本 MySQL 的好方法。

7.1.1.2 Load balancing
如果你的服务器运行大量的查询中，读查询远远大于写查询，那么 replication 是一个很有效的负载均衡解决方案。你可以通过 replication 将负载分布到那些从服务器上。

7.1.1.3 Backup and recovery
如果你的服务器非常繁忙而且处于7×24服务中，那么 replication 是一个很有效的“热备份”方案。

7.1.1.4 High availability and failover
利用 replication 和一些相对简单的技术，你就可以拥有 MySQL 自动失效备援方案，从而获得较好程度的可用性。

failover：失效備援，為系統備援能力的一種，當系統中其中一項設備 (EQPT,EQUIP ) 失效而無法運作時，另一項設備即可自動接手原失效系統所執行的工作。如果各伺服器 (Server) 具備故障復原的能力，就可以減少使用者打電話到支援中心的頻率，進而降低管理成本。

其原理可以在 DNS 上对主服务器的域名解析设较低 TTL，当主机故障，迅速刷新域名到从服务器。因为 TTL 设的较低，所以客户端会迅速解析域名到从服务器。

7.1.2 Problems Not Solved with Replication
当然，replication 不能解决一切问题。性能就是一个制约因素，因为每个从服务器需要执行和主服务器相同的写查询。由此可知，在写操作量很大的程序中，从服务器的配置需要和主服务器一样强劲。如果此时你用 replication 来建立负载均衡，你可能就要失望了。

7.1.3 Replication Performance
性能吗，这里没有数据，不过据作者讲还不错。

7.2 Configuring Replication
理论讲完了，该动手操作了。

7.2.1 On a New Server
分为四步：
1. 在每个服务器上建立一个 replication 帐号。
2. 修改服务器配置文件 my.cnf 。
3. 重起主服务器证实二进制日志产生。
4. 重起从服务器证实 replication 开始工作。

7.2.1.1 Account creation
在从服务器上建立帐号，是为了其将来变成主服务器而打算。

mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO
repl@”192.168.1.0/255.255.255.0” IDENTIFIED BY ‘c0pyIT!’;

随后来验证帐号正确无误：
mysql> SHOW GRANTS FOR repl;

7.2.1.2 Configuration file entries
修改配置文件也就是告诉主服务器启用二进制日志，告诉从服务器谁是主服务器，它的登录证件以及其他等等。

修改主服务器配置文件 my.cnf 如下：
log-bin
server-id = 1
日志文件默认存于数据目录，当然你可以指定你想要的目录，例如：
log-bin = /var/db/repl/log-bin

修改从服务器配置文件：
server-id = 2 master-host = master.example.com
master-user = repl
master-password = c0pyIT!
master-port = 3306

7.2.1.3 Restart master
无须多说，你只需要重启 MySQL 服务，然后验证二进制日志是否出现。你也可以用 mysqlbinlog 来检查存储在二进制日志里的数据。

7.2.1.4 Restart slave
同样，重启 MySQL 服务，无论从服务器连接主服务器成功与否，MySQL 都会在错误日志里记录下来：
021103 13:58:10 Slave I/O thread: connected to master ‘repl@master:3306’,
replication started in log ‘log-bin.001’ at position 4

7.2.2 On an Existing Server

7.2.2.1 What needs to happen
在已有的服务器上设置 replication，出了设置帐号和修改配置文件以外，还要考虑已有数据拷贝到从服务器的问题。

7.2.2.2 Snapshot or backup, then copy
最简单的办法就是让 MySQL 离线，然后将数据打包、拷贝至从服务器。如果你不能让服务器离线，那就在修改配置、让服务器重启后做一个在线的 snapshot。
这个 snapshot 对 MyISAM 表没问题，但对 InnoDB 和 BDB 来讲最好还是离线备份。 Snapshot 在进行过程中要对数据做一个读锁定。

7.2.2.3 Online table copies
我们还可以在线从主服务器上完整拷贝一个表过来，例如：
LOAD TABLE mytable FROM MASTER

单这也有局限性，在拷贝过程中主服务器上的数据不能有更改。另外，这种方法不会拷贝索引过来，如果数据量很大的话，在本地建立索引也需要很长时间。

7.2.2.4 Online copy and synchronize (MySQL 4.x only)
MySQL 4.0 提供了 LOAD DATA FROM MASTER 命令。此命令可队主服务器的数据进行读锁定，然后将主服务器的表一一拷贝过来，完成后才会释放锁定，随后开始 replication 。
这个方法虽然不错，但是效率比较慢，另外只对 MyISAM 有效，还必须对 replication 帐号赋予 SUPER 和 RELOAD 的权限。

7.3 Under the Hood

7.3.1 Replication in 3.23
很少有人用3.23版本，而且 replication 在3.23的实现也并不怎么好。

7.3.2 Replication in 4.0
4.0版本中，replication 被重写了，它现在有两个线程：IO 线程和 SQL 线程。IO 线程从主服务器的二进制日志读取查询，然后存于本地的 relay 日志里。SQL 线程从本地的 relay 日志里读取查询并执行它。
当然这个方案并不是万无一失，IO 线程还是有可能在主服务器崩溃的时候读不到一些查询。

7.3.3 Files and Settings Related to Replication

7.3.3.1 Log files
日志文件包括 binary 和 replay 日志。Binary 日志包含了所有的写查询。如果 MySQL 不再需要它们，最好删除之。
Relay 日志是从服务器自动生成的，而且可以在配置文件里修改其文件名和存储路径：
relay-log = /home/mysql/relay.log。
不像 binary 日志，relay 日志当不再需要时，MySQL 会自动删除它。

7.3.3.2 Log index files
每个日志文件都有其索引文件。索引文件包含了这些日志的文件名，当日志文件增添时，索引文件会同步更新。
log-bin-index = /var/db/logs/log-bin.index
relay-log-index = /var/db/logs/relay-log.index

当从服务器配置好且运行 replication 时，最好不要改变这些配置。

7.3.3.3 Status files
Master.info 文件用来储存主服务器的信息，包括主机名、端口、用户名、密码、日志文件名和其存放路径。
MySQL 4.0 从服务器额外提供了一个状态文件，relay-log-info，来监视 SQL 线程处理的过程。

7.3.3.4 Filtering
当然有时候你并不想从主服务器复制一切到从服务器，MySQL 提供了一些控制选项来过滤数据。

这种控制选项分为两类，第一类应用于主服务器的 binary 日志，并提供了单数据库过滤：
binlog-do-db=dbname
binlog-ignore-db=dbname

第二类应用于从服务器的 relay 日志：
replicate-do-table=dbname.tablename
replicate-ignore-table=dbname.tablename
replicate-wild-do-table=dbname.tablename
replicate-wild-ignore-table=dbname.tablename
replicate-do-db=dbname
replicate-ignore-db=dbname
replicate-rewrite-db=fromdbname->todbname

可以看出从服务器的控制选项更为完全，不仅提供单表过滤，而且还可以在 replication 过程中修改表名和数据库名。

7.4 Replication Architectures

7.4.1 The Replication Rules
四条规则：
1. 每个从服务器必须有一个唯一的服务器 ID 。
2. 每个从服务器只能有一个主服务器。
3. 一个主服务器可以有几个从服务器。
4. 从服务器也可能是其他从服务器的主服务器。

7.5 Administration and Maintenance

7.5.1.1 Master status
下面这个命令用来显示主机 replication 状态的：
mysql> SHOW MASTER STATUS G

7.5.1.2 Slave status
SHOW SLAVE STATUS 给出的信息要比主服务器多一些，这些信息中 SlaveIORunning 和 SlaveSQLRunning 最为重要。他们告诉你 IO 和 SQL 线程是否在运行。

7.5.1.3 Replication heartbeat
简单的心跳系统可以在一定程度上得知从服务器何时脱线了。其原理是在主服务器每隔一定时间在表中插入时间戳，此时从服务器也应该有相同的操作。

7.5.2 Log Rotation
SHOW MASTER LOGS 命令显示目前有多少日志。

mysql> PURGE MASTER LOGS TO ‘binary-log.004’;
此命令是删除所有日志，除了命令中的那个日志。注意不要删的太快，之前要确定从服务器已经不需要那些日志了。

7.5.3 Changing Masters
MySQL 提供了专门的命令来更换主服务器：CHANGE MASTER TO 。

7.5.3.1 Using the right values
正常情况下，比较简单，有七步：
1. 断开所有客户与主服务器的连接。
2. 确认新的主服务器已准备好。
3. 在新的主服务器上执行 RESET MASTER 的指令。
4. 确认从服务器已准备好。
5. 关掉旧的主服务器。
6. 客户可以连接新的主服务器。
7. 在每个从服务器上执行 CHANGE MASTER TO 的指令，使其连接新的主服务器。

RESET MASTER 指令是重新设置二进制日志。下面是一个完整的转换主服务器指令的例子：
mysql> CHANGE MASTER TO
-> MASTERHOST=’newmaster.example.com’,
-> MASTERUSER=’repl’,
-> MASTERPASSWORD=’MySecret!’,
-> MASTERPORT=3306,
-> MASTERLOGFILE=’log-bin.001’,
-> MASTERLOGPOS=4;

7.5.4 Tools
介绍了一些检测，控制日志，排错的工具。

7.6 Common Problems
此章介绍了一些影响 replication 的问题。