mysql主从复制浅析（一）

复制概述

mysql内建的复制功能是构建大规模、高性能应用的基础。复制解决的基本问题是让一台服务器的数据与其他的服务器同步，以主备的方式构建数据系统。

常见用途

• 数据分布：在不同的地理位置分布数据，进行备份。
• 负载均衡：将读操作分布到多个服务器上（使用dns轮询或lvs）
• 备份：是传统备份的补充，不能完全替代备份
• 故障切换：避免单点失效
• 升级测试：使用一个更高版本的mysql作为备库作为主库的升级测试

工作原理

1. 在主库上把更改记录到二进制日志（Bin Log）
2. 备库上将主库的日志复制到自己的中继日志（Relay Log）上。
3. 备库读取中继日志的事件，写入数据

配置复制样例

1) 配置主库和备库

vi /etc/my.cnf
log_bin = mysql-bin #启动二进制日志
server_id = 128 #服务器id,一般取ip的最后一段

2）重启mysql

service mysql restart

3）主库上创建复制账号

mysql>GRANT REPLICATION SLAVE ON *.* to ‘replication‘@‘%‘ identified by ‘123456‘;

4) 主库上查询master状态

mysql> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000015 |      107 |              |                  |
+------------------+----------+--------------+------------------+

注：执行完此步骤后不要再操作主服务器MYSQL，防止主服务器状态值变化

5）备库配置slave

mysql> CHANGE MASTER TO
    -> MASTER_HOST=‘192.168.75.128‘,
    -> MASTER_USER=‘replication‘,
    -> MASTER_PASSWORD=‘123456‘,
    -> MASTER_PORT=3306,
    -> MASTER_LOG_FILE=‘mysql-bin.000015‘,
    -> MASTER_LOG_POS=107,
    -> MASTER_CONNECT_RETRY=10；

//启动复制功能
mysql>  start slave;

6) 查看备服务器复制功能状态

mysql> show slave status\G
************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.75.128
                  Master_User: replication
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File:
          Read_Master_Log_Pos: 4
               Relay_Log_File: t1-relay-bin.000015
                Relay_Log_Pos: 4
        Relay_Master_Log_File:
             Slave_IO_Running: Yes  //此状态必须YES
            Slave_SQL_Running: Yes  //此状态必须YES
          .............

备服务器中途复制

前面的设置是主备服务器都刚创建，并且知道当前主库的起始日志，实际工作中的场景大多是已经运行了一段时间的主库，然后用一台新安装的备库与之同步。下面是备服务器中途复制的常用方法：

• 冷备份：关闭主库，把数据复制到备库。重启主库后在备库执行 CHANGE MASTER TO指向主库新的日志文件
• 使用mysqldump：如果只包含InnoDB表，可以使用mysqldump传输复制数据，再指定二进制日志坐标 $ mysqldump --single-transaction --all-databases --master-data=1 --host=server1 | mysql --host=server2
• 使用Percona Xtabackup开源的热备份工具

复制的工作模式

• 基于语句的复制：备库记录和执行主库运行过的SQL
• 基于行的复制：备库复制主库每一行数据（推荐）

常用的主备架构

• 一主多备：在少量写大量读时，该配置十分有效，可以将读操作分摊多个备库上，直到主备之间的带宽成为瓶颈。
• 双主复制：包含两台服务器，每一个都配置成对方的主库和备库。使用场景是两个不同的应用服务器都需要连接一个可写的数据库。该配置主要有2个问题，两服务器同时修改一行数据和AUTO_INCREMENT问题。
• 双主复制的被动模式：双主复制的变体，主要区别是一台服务器是只读的被动服务器。由于是有一台只读服务器，所以没有上面的问题，而且该模式下服务器的配置是一样的，所以故障转移和故障恢复很容易解决。

复制的管理和维护

1)测量备库延迟

SHOW SLAVE STATUS输出的secondsbehindmaster理论上显示了备库的延时。

2)确定主备是都一致

• mysql内置工具CHECKSUM TABLE,当复制正在进行时，该方法不可行。
• pt-talble-checksum 比较好的开源工具。

3)备库从新同步备库数据

备库忽略了一些数据或人为的修改备库的数据时就需要从新同步备库，方法有： - 关闭备库，重新从主库复制一份数据，简单但数据量大时不推荐 - 使用mysqldump转储受影响的数据，当主库数据没有发生改变时，该方法很好，但只同步一百万行数据中的一小部分时效率不高。 - 开源工具pt-table-sync,比较主备之间不同的数据从而进行同步，效率很高

4)数据损坏解决方案

• 主库意外关闭：备库从主库一个新的日志开始复制数据，再用pt-talle-checksum重新同步主备。
• 备库意外关闭：正常情况备库重启会去mastter.info寻找上次复制的位置，如果该文件损坏或文件本身数据是错误的，备库可能会重新执行一些二进制日志事件，造成如惟一索引这样的错误，解决方案使用开源工具pt-slave-restart