mysql主从复制(Master-Slave)



（一）Master-Slave

一、复制原理

开始搭建前有个mysql复制原理的基础知识需要补充:

1 .复制概述

Mysql内建的复制功能是构建大型，高性能应用程序的基础。将Mysql的数据分布到多个系统上去，这种分布的机制，是通过将Mysql的某一台主机的数据复制到其它主机（slaves）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。

请注意当你进行复制时，所有对复制中的表的更新必须在主服务器上进行。否则，你必须要小心，以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。

1.1 mysql支持的复制类型：

(1)：基于语句的复制： 在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。
一旦发现没法精确复制时， 会自动选着基于行的复制。

(2)：基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持
(3)：混合类型的复制: 默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。

1.2 复制解决的问题

MySQL复制技术有以下一些特点：

(1) 数据分布 (Data distribution )

(2) 负载平衡(load balancing)

(3) 备份(Backups)

(4) 高可用性和容错行 High availability and failover

1.3 复制如何工作

整体上来说，复制有3个步骤：

(1) master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）；

(2) slave将master的binary log events拷贝到它的中继日志(relay log)；

(3) slave重做中继日志中的事件，将改变反映它自己的数据。

2. mysql进行主备复制使用到了三个线程：

1.主库上的转存储线程: 会将mysql server提交的事务写入到二进制文件中，这个二进制文件就叫做binlog。

2.备库上的连接线程： 备库启动后，负责和主库通信，读取binlog，同时，将binlog存储进自己的一个叫中继日志的relaylog中。

3.备库上的relaylog重放线程: 此线程会将relaylog中的事件在备库上进行回放，说白点就是重新执行一次

测试环境

主备 master slave

IP: 192.168.56.87 192.168.56.88

Mysql-Version : 5.6.23

OS: Red Hat Enterprise Linux Server Release 5.5 (cat /etc/redhat-release)

MySQL 主从流程图

1、配置Mysql主配置文件/etc/my.cnf

[root@bogon ~]# vi /etc/my.cnf

server-id = 1
#指定服务器的ID（ID唯一）

log-bin = mysql-bin #指定产生binlog日志文件的前缀

以上两项是必须的，设置后重启服务。

[root@node1 ~]# service mysqld restart

Shutting down MySQL.. [ OK ]

Starting MySQL. [ OK ]

[root@node1 ~]# service mysql restart

Shutting down MySQL.. [ OK ]

Starting MySQL. [ OK ]

2、主服务器授权

在Master上创建一个用户并授权从服务器可以连接主服务器并可以进行更新。

mysql> grant replication
slave on *.* to 'test'@'192.168.56.%' identified by '123';

Query OK, 0 rows affected
(0.00 sec)

3.锁定主库的表，备份主库

mysql> flush tables with read lock;

锁定主库表的目的是防止数据备份阶段有数据写入，数据恢复丢失数据

查看正在写哪一个二进制文件和文件位置（ POS 值）（用于恢复数据用）

mysql>show master
status\G

*************************** 1. row ***************************

File: mysql-bin.000001

Position: 329

Binlog_Do_DB:

Binlog_Ignore_DB:

Executed_Gtid_Set:

1 row in set (0.00
sec)

注意： show master status\G 后面不能加; show master
status\G; 前面最好也没有空格否则很容易报意外的错误。

进入到shell命令行备份数据库

/usr/local/mysql/bin/mysqldump -R -u
root -p test >/tmp/test.sql

-R 备份函数，存储过程

回到锁表界面，解锁所有表

mysql> unlock tables;

4、备份文件传输到从库上

scp -P4999 ccc.sql 用户名
@172.16.22.2:/tmp/

[root@node1 tmp]# scp test.sql root@192.168.56.88:/tmp/

root@192.168.56.88's
password:

test.sql 100% 2044 2.0KB/s 00:00

[root@node1 tmp]#

-P 加端口号，默认的 ssh端口号为 22 ，如果没有修改过，此参数可省略

ccc.sql 要传输的文件名

用户名@ip:/tmp/ 用户 @IP:/目录

5.从库开启ready_log

5.1 创建存目录存放ready_log

mkdir /usr/local/mysql/reay_log

chmod -R 755 /reay_log

chown mysql:dba reay_log

5.2编辑slave的参数

[root@repli1 ~]# vi /etc/my.cnf

server-id = 2 #指定服务器的ID

log-bin=mysql-bin

relay_log= /usr/local/mysql/reay_log/mysql-relay-bin

log_slave_updates=1

read_only=1

重启服务

service mysql restart

server_id 服务器的标识符，唯一值，不能跟从服务器重复

log-bin=mysql-bin 开启 binlog日志

relay_log 开启复制日志， relay-log 日志记录的是在复制过程中，从服务器 I/O 线程将主服务器的二进制日志读取过来记录到从服务器本地文件，然后 SQL 线程会读取 relay-log日志的内容并应用到从服务器。

ready_only=1 只读

6.模拟这段时间主库继续有业务

主库操作

mysql> CREATE TABLE pet1 (name VARCHAR(20), owner VARCHAR(20),

species VARCHAR(20), sex CHAR(1), birth DATE, death DATE);

mysql> INSERT INTO pet1 VALUES ('Puffball','Diane','hamster','f','1999-03-30',NULL);

mysql> commit;

Query OK, 0 rows affected (0.00 sec)

7. 从库导入数据

test 数据库本来就有不用再建了，如果没有就要建库。

mysql> create database test character set utf8 collate 'utf8_general_ci';

mysql> use test;

mysql> source /tmp/test.sql;

依次导入其它 DB

8、从库配置同步

mysql> change master to master_host='192.168.56.87',master_user='test',master_password='123',

master_log_file='mysql-bin.000005',master_log_pos=120;

master_host 主机 IP

master_user 上面创建的复制用户名

master_passowrd 用户密码

master_log_file 从那个二进制文件开始复制 对应上面的file

master_log_pos 从二进制文件的哪个位置开始复制 对应上面的position

mysql> start slave

ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository 竟然报错了

mysql> reset slave; 重置slave的参照

Query OK, 0 rows affected (0.00 sec)

mysql> start slave;

Query OK, 0 rows affected (0.00 sec) 现在才成功

mysql> show slave status\G;

启动Slave服务器，进入mysql控制台，查看同步状态。

mysql> show slave status\G

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.56.87

Master_User: test

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000005

Read_Master_Log_Pos: 586

Relay_Log_File: mysql-relay-bin.000009

Relay_Log_Pos: 749

Relay_Master_Log_File: mysql-bin.000005

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

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: 586

Relay_Log_Space: 1294

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

Master_UUID: 84b3bb06-f8a9-11e4-9dad-080027ecb38e

Master_Info_File: /usr/local/mysql/data/master.info

SQL_Delay: 0

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

Master_Retry_Count: 86400

Master_Bind:

Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set:

Executed_Gtid_Set:

Auto_Position: 0

1 row in set (0.00 sec)

正常状态下，看到上面的两行加粗处，即Slave_IO_Running和Slave_SQL_Running的参数都为
Yes，就说明主从同步运行正常。

9. 查看pet1 的数据有没有同步过来

mysql> select * from pet1;

+----------+-------+---------+------+------------+-------+

| name | owner| species | sex | birth | death |

+----------+-------+---------+------+------------+-------+

| Puffball | Diane| hamster| f | 1999-03-30 | NULL|

+----------+-------+---------+------+------------+-------+

pet1 也被同步过来了；

10、同步测试

10.1 在master上写入数据：

mysql> CREATE TABLE pet3 (name VARCHAR(20), owner VARCHAR(20),

species VARCHAR(20), sex CHAR(1), birth DATE, death DATE);

mysql> INSERT INTO pet3 VALUES ('Puffball','Diane','hamster','f','1999-03-30',NULL);

mysql> commit;

10.2 在slave上查看结果：

mysql> use test

Database changed

mysql> show tables;

+----------------+

| Tables_in_test |

+----------------+

| pet |

| pet1 |

| pet3 |

+----------------+

3 rows in set (0.00 sec)

mysql> select * from pet3;

+----------+-------+---------+------+------------+-------+

| name | owner | species | sex | birth | death |

+----------+-------+---------+------+------------+-------+

| Puffball | Diane | hamster | f | 1999-03-30 | NULL |

+----------+-------+---------+------+------------+-------+

1 row in set (0.00 sec)

可以看到 pet3表被同步过来啦！

经过一番波折终于搭建成功了！

---------------------------------------------------------------------
还未测试

使用replicate_do_db和replicate_ignore_db时有一个隐患，跨库更新时会出错

如设置 replicate_do_db=test

use mysql;

update test.table1 set ......

第二句将不会被执行

如设置 replicate_ignore_db=mysql

use mysql;

update test.table1 set ......

第二句会被忽略执行

原因是设置replicate_do_db或replicate_ignore_db后，MySQL执行sql前检查的是当前默认数据库，所以跨库更新语句被忽略。

可以使用replicate_wild_do_table和replicate_wild_ignore_table来代替

如

replicate_wild_do_table=test.%

或

replicate_wild_ignore_table=mysql.%

这样就可以避免出现上述问题了