标签：MySQL   主从复制   原理   实践   

第1章 MySQL的主从复制介绍

MySQL的主从复制方案，和上述文件及文件系统级别同步是类似的，都是数据的传输。只不过MySQL无需借助第三方工具，而是其自带的同步复制功能。另外一点，MySQL的主从复制并不是磁盘上文件直接同步，而是逻辑的binlog日志同步到本地再应用执行的过程。

复制可以单向：M=>S，也可以是双向M<==>M，也可以是多M换装同步等。如果设置了链式级联复制，那么，从（slave）服务器本身除了充当从服务器外，也会同时充当其下面从服务器的主服务器。链式级联复制类似A-->B-->C-->D的复制形式。

主从复制条件：

1、开启binlog功能

2、主库建立同步账号

3、从库配置master.info（change master）

4、start slave 复制开关

1.1 主从复制原理介绍

MySQL的主从复制是一个异步的复制过程（虽然一般情况下感觉是实时的），数据将从一个MySQL数据库（Master）复制到另外一个MySQL数据库（Slave），两个数据库之间实现整个主从复制的过程是由三个线程参与完成的。其中两个线程（SQL和I/O）在Slave端，另外一个线程（I/O）在Master端。

要实现MySQL的主从复制，首先必须打开Master端的binlog记录功能，否则就无法实现。因为整个复制过程实际上就是Slave从Master端获取binlog日志，然后在Slave上以相同顺序执行获取的binlog日志中记录的各种SQL操作。

[mysqld]
log-bin = /data/3306/mysql-bin

1.2 MySQL主从复制原理过程详细描述

第一步：

在Slave服务器上执行start slave命令开启主从复制开关，开始进行主从复制。

第二步：

此时，Slave服务器的I/O线程会通过在Master上已经授权的复制用户权限请求连接Master服务器，并请求从指定binlog日志文件的指定位置（日志文件名和位置就是在配置主从复制服务时执行change master命令指定的）之后开始发送binlog日志内容。

第三步：

Master服务器接受到来自Slave服务器的I/O线程请求后，其上负责复制的I/O线程会根据Slave服务器的I/O线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息，然后返回给Slave端I/O线程。返回的信息中除了binlog日志内容外，还有在Master服务器段记录的新的binlog文件名称，以及在新的binlog中的下一个指定更新位置。

第四步：

当Slave服务器I/O线程获取到Master服务器上I/O线程发送的日志内容、日志文件及位置点后，会将binlog日志内容依次写到Slave端自身的Relay Log（即中继日志）文件（MySQL-relay-bin.xxxxxx）的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取Master端新binlog日志能够告诉Master服务器从新binlog日志的指定文件及位置开始请求新的binlog日志内容。

第五步：

Slave服务器段的SQL线程会实时检测本地的Relay Log中I/O线程新增加的日志内容，然后及时地把Relay Log文件中的内容解析成SQL语句，并在自身的Slave服务器上按解析SQL语句的位置顺序执行应用这些SQL语句，并在relay-log.info中记录当前应用中继日志的文件名及位置点。

第2章 主从复制步骤案例

2.1 开启主库binlog功能

[root@localhost ~]# grep log-bin /data/3306/my.cnf
log-bin = /data/3306/mysql-bin

2.2 确保所有实例server-id不同

[root@localhost ~]# grep server-id /data/330{6..7}/my.cnf
/data/3306/my.cnf:server-id = 1
/data/3307/my.cnf:server-id = 3

2.3 主库授权复制的用户rep

mysql> grant replication slave on *.* to 'rep'@'10.0.0.%' identified by '123456';
Query OK, 0 rows affected (0.00 sec)
 
mysql> flush privileges;
Query OK, 0 rows affected (0.01 sec)

2.4 主库导出备

q  对主数据库锁表

mysql> flush table with read lock;
Query OK, 0 rows affected (0.00 sec)

注：锁表之后窗口不能退出！！再开一个窗口登录。

q  查看binlog文件及位置点（--master-data=2）

mysql> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000010 |     5218 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

q  新开一个shell窗口导出全备数据

[root@localhost backup]# mysqldump -uroot -p123456 -S /data/3306/mysql.sock -A -B --events |gzip> /service/backup/rep_bak_$(date +%F).sql.gz
[root@localhost backup]# ll /service/backup/
total 144
-rw-r--r-- 1 root root 145138 Feb  6 01:04 rep_bak_2018-02-06.sql.gz

q  解锁，开放用户写入

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

2.5 从库确保server-id不同

[root@localhost ~]# grep server-id /data/3307/my.cnf
server-id = 3

2.6 主库全备导入从库

[root@localhost backup]# mysql -uroot -p123456 -S /data/3307/mysql.sock < rep_bak_2018-02-06.sql
[root@localhost backup]# mysql -uroot -p123456 -S /data/3307/mysql.sock -e "show databases;"
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
| test_dbk           |
+--------------------+

2.7 从库找位置点，配置master.info

在上面的show master info得到的位置信息。

mysql-bin.000010 |     5218

从库连接主库的配置如下：

CHANGE MASTER TO
MASTER_HOST='10.0.0.16',
MASTER_PORT=3306,
MASTER_USER='rep',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='mysql-bin.000010',
MASTER_LOG_POS=4547;

登录备库，执行如上指令：

[root@localhost 3307]# mysql -uroot -p123456 -S /data/3307/mysql.sock
mysql> CHANGE MASTER TO
    -> MASTER_HOST='10.0.0.15',
    -> MASTER_PORT=3306,
    -> MASTER_USER='rep',
    -> MASTER_PASSWORD='123456',
    -> MASTER_LOG_FILE='mysql-bin.000010',
    -> MASTER_LOG_POS=5218;
Query OK, 0 rows affected (0.03 sec)
 
mysql>

注：1、默认情况下是没有master.info文件的。在运行了如上命令之后，会在备库的数据目录/data/3307/data/下面生成一个master.info文件！

       2、如果change错误，可以使用reset sleav all，再次重新设置！！

2.8 开启从库备份开关

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

2.9 查看从库同步状态

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.0.0.15
                  Master_User: rep
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000010
          Read_Master_Log_Pos: 536031
               Relay_Log_File: relay-log.000002
                Relay_Log_Pos: 531066
        Relay_Master_Log_File: mysql-bin.000010
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes              #<==看到有这两个线程在的时候基本就成功了。
              Replicate_Do_DB:
          Replicate_Ignore_DB: mysql
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 536031
              Relay_Log_Space: 531216
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0        #<==查看是否有延迟
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
1 row in set (0.00 sec)

q  Slave_IO_Running: Yes，这个是I/O线程状态，I/O线程负责从从库去主库读取binlog日志，并写入到从库的中继日志中，状态为Yes表示I/O线程正常工作。

q  Slave_SQL_Running: Yes，这个是SQL线程状态，SQL线程负责读取中继日志(relay-log)中的数据并转换为SQL语句应用到从数据库中，状态为Yes表示I/O线程正常工作。

q  Seconds_Behind_Master: 0，这个是在复制过程中，从库比主库延迟的秒数，这个参数很重要，但还有更准确地判断主从延迟的方法：在主库写时间戳，然后从库读取时间戳和当前数据库的时间进行比较，从而认定是否延迟。

2.10 查看主库线程状态

使用show processlist;命令可以查看mysql的线程状态：

mysql> show processlist;
+----+------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+
| Id | User | Host            | db   | Command     | Time | State                                                                 | Info             |
+----+------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+
| 57 | root | localhost       | NULL | Query       |    0 | NULL                                                                  | show processlist |
| 61 | rep  | 10.0.0.16:34487 | NULL | Binlog Dump |  347 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL             |
+----+------+-----------------+------+-------------+------+-----------------------------------------------------------------------+------------------+
2 rows in set (0.00 sec)

线程状态说明：

第3章 主从复制故障解决办法

故障再现步骤：1、主库新建数据库test；2、从库删除同步过来的数据库test；3、主库上再删除数据库test。简单 执行如上步骤，则在从库就会出现复制故障问题：

show slave status:报错；且show slave status\G:

            Slave_IO_Running: Yes
            Slave_SQL_Running: No
        Seconds_Behind_Master: NULL
Last_Errno: 1008
Last_SQL_Error: Error 'Can't drop database 'test'; database doesn't exist' on query. Default database: 'test'. Query: 'drop database test'

q  解决方法1

stop slave;                             #<==临时停止同步开关
set global sql_slave_skip_counter =1;   #<==将同步指针向下移动一个，可多次重复操作
start slave;                            #<==开启同步开关

q  解决方法2

根据忽略的错误号事先在配置文件中配置，跳过指定的不影响业务数据的错误，例如：

grep slave-skip /data/3306/my.cnf
slave-skip-errors = 1032,1062,1007，1008        #<==可忽略的错误号自行设置

1007：数据库已存在，创建数据库失败

1008：数据库不存在，删除数据库失败

1032：记录不存在

1062：字段值重复，入库失败

MySQL主从复制原理及实践

标签：MySQL   主从复制   原理   实践   

原文地址：http://blog.51cto.com/13178102/2082767