Mysql 5.6主从同步配置

主从同步，本质是利用数据库日志，将主库数据复制一份到从库，本质上是使用了数据复制技术。

本文概要

主库的基本配置
从库的基本配置
完全同步的步骤
注意事项
工作原理

1. 主库的基本配置

做两件事：启用日志（记录数据库操作），赋予从库复制权限。配置如下：

启用日志：

# sync_binlog=1 #默认为0，当 sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。 #当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

log_bin=mysql-bin #打开日志，并指定日志基本名称。

log_bin_index=mysql-bin.index

log_bin_trust_function_creators=1

expire_logs_days = 3

给予从库复制权限

（不同的主机，配置不同的用户名，以区分。如slave95,m95m96，或者采用统一用户名，如下所示：）

mysql> grant replication slave on *.* to 'slave'@'%' identified by 'dd@2016';

mysql> flush privileges;

2. 从库的基本配置

做两件事：启用（中继）日志，指定从库从主库某个文件（某个位置）复制日志。

启用（中继）日志

#log-bin=mysql-bin #从库用不上

relay-log=slave-relay-bin

relay-log-index=slave-relay-bin.index

skip-slave-start   #防止复制随着mysql启动而自动启动

slave-skip-errors=all

relay_log_info_repository = TABLE

master_info_repository    = TABLE

relay_log_recovery        = 1

log_bin_trust_function_creators=1

slave-net-timeout = 60            #默认值3600.意味着没有得到更多数据之后slave等待时间

expire_logs_days = 3

read-only=1  #可选项，做读写分离时，可配置

replicate_wild_do_table=datacenter.% #告诉从服务器线程限制复制更新的表匹配指定的数据库和表名模式的语句。

replicate_wild_do_table=kettle.%

指定从库从主库某个文件（某个位置）复制日志

mysql>CHANGE MASTER TO

MASTER_HOST='192.168.100.104',

MASTER_PORT=3306,

MASTER_USER='slave',

MASTER_PASSWORD='dd@2016',

MASTER_LOG_FILE='mysql-bin.000001',

MASTER_LOG_POS=839;

3. 完全同步的步骤

主库

进行锁表，防止数据写入

使用命令：

mysql> flush tables with read lock;

2.备份数据

mysqldump -uroot -p -B kettle datacenter|gzip>/ddhome/data.sql.gz

3.查看master 状态，解开锁表功能

mysql> show master status;

mysql> unlock tables;

4.把mysql备份文件传到从库机器，进行数据恢复

scp mysql.bak.sql root@192.168.128.11:/tmp/

从库

停止从库的状态

mysql> stop slave;

导入数据

mysql -uroot -p  </tmp/mysql.bak.sql

or

mysql> source /tmp/mysql.bak.sql

设置从库同步，注意该处的同步点，就是主库show master status信息里的| File| Position两项

change master to master_host = '10.130.254.13', master_user = 'slave', master_port=3306, master_password='dd@2016', master_log_file = 'mysql-bin.000104', master_log_pos=481224382;

重新开启从同步

mysql> start slave;

查看同步状态

mysql> show slave status\G

查看：（参考：mysql主从复制搭建中几种log和pos详解 - 学无涯，愈进而愈惘 - CSDN博客）

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Seconds_Behind_Master: 0

          Master_Log_File: mysql-bin.000125

      Read_Master_Log_Pos: 947053504    #从库IO线程读取主库日志的位置

           Relay_Log_File: slave-relay-bin.000064

            Relay_Log_Pos: 947053667    #从库IO线程写入本地日志

    Relay_Master_Log_File: mysql-bin.000125

      Exec_Master_Log_Pos: 947053504    #从库sql线程执行到哪里

简单来讲就是从库先通过io线程读取主库的二进制文件（Master_Log_File）和位置（Read_Master_Log_Pos）然后缓存到本地（从库服务器）的中继文件（Relay_Log_File）中并记录已经读取到的位置（Relay_Log_Pos），再通过从库的sql线程去读取中继文件（Relay_Log_File），这个sql线程执行会记录已经执行到了哪个文件（Relay_Master_Log_File）和哪个位置（Exec_Master_Log_Pos）。

4. 注意事项

从库每次都要手动start slave，不能自动启动。如果是双主热备时，则自动启动;
在Slave上使用 replicate_wild_do_table 和 replicate_wild_ignore_table 来解决跨库更新的问题

5. 工作原理

master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）。
Slave将Master的日志拷贝到自己的中继日志(relay log)中。
Slave重新执行中继日志中的事件并放到自己的数据库中。

MySQL复制的缺点

MySQL的复制（replication）功能让人且爱且恨。MySQL复制配置简单，深受开发人员的喜欢，基于复制的读写分离方案也非常流行。而MySQL数据库高可用大多也是基于复制技术，但是MySQL复制本身依然存在部分缺陷，最为主要的问题如下：

数据丢失问题（consistency）
数据同步延迟问题（delay）
扩展性问题（scalability）

从MySQL 5.7的lossless semi-sync replication已经解决了数据丢失的问题，MySQL 5.7的multi-thread slave也解决了数据同步延迟的问题，MySQL 5.7的Group replication也扩展性问题。

参考文献

tips:本文属于自己学习和实践过程的记录，很多图和文字都粘贴自网上文章，没有注明引用请包涵！如有任何问题请留言或邮件通知，我会及时回复。