MYSQL主从复制

MySQL主从复制与主主复制

MySQL集群（一）之主从复制
mysql集群技术：主从复制，读写分离

 

relay 传递

Slave 复数、奴隶

replication 复制

 

privileges 特权

 

主从复制，只能有一个主节点，可以用n多个从节点

 

一、配置文件

在执行这个主从复制之前，首先必须打开 Master 端的Binary Log(MySQL-bin.xxxxxx)功能，否则无法实现。从服务器也需要开启二进制日志和 relay 日志功能 .这样可以从主服务器读取 binlog, 并产生 relaylog。

 

在启动 MySQL Server 的过程中使用“log-bin” 参数选项

在 my.cnf 配置文件中的 MySQLd 参数组中增加“log-bin” 参数项

 

一般Linux中的MySQL配置文件都在/etc/my.cnf (windows中的配置文件为mysql.ini)

log-bin=mysql-bin 开启二进制日志

 

注意：二进制日志必须开启，因为数据的同步实质上就是其他的MySQL数据库服务器将这个数据变更的二进制日志在本机上再执行一遍。

 

 

二、Mysql主从复制的原理

1、主服务器凡运行语句 , 都产生一个二进制日志 binlog

2、从服务器不断读取主服务器的 binlog

3、从主服务读取到的 binlog, 转换为自身可执行的 relaylog,

4、执行 relaylog

 

实现步骤 :

1、首先确保主服务器打开二进制日志功能 ,这样主服务器一旦有数据变化 ,立即产生二进制日志 

2、从服务器也需要开启二进制日志和 relay 日志功能 ,这样可以从主服务器读取 binlog, 并产生 relaylog

3、在主服务器建立一个从服务器的账号 , 并授予各种数据库权限。指定从服务对应的主服务器 , 开启从服务器 .

 

三、Mysql主从复制的过程

 

3.1、主从复制详细过程

MySQL 的 Replication 是一个异步的复制过程，在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql 线程和IO 线程)在 Slave 端，另外一个线程(IO 线程)在 Master 端。 

 

1） Slave 上面的IO 线程连接上 Master，并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容。

2） Master 接收到来自 Slave 的 IO 线程的请求后，通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息，返回给 Slave 端的 IO 线程。

返回信息中除了日志所包含的信息之外，还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 BinaryLog 中的位置。

 

3）Slave 的 IO 线程接收到信息后，将接收到的日志内容依次写入到 Slave 端的RelayLog （中继日志文件）文件(MySQL-relay-bin.xxxxxx)的最末端，并将读取到的Master 端的bin-log 的文件名和位置记录到master-info 文件中，以便在下一次读取的时候能够清楚的告诉Master “我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我” 。

 

4）Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后，会马上解析该 Log 文件中的内容为在 Master 端真实执行的那些可执行的 Query 语句，并在自身执行这些 Query。

这样，实际上就是在 Master 端和 Slave 端执行了同样的 Query，所以两端的数据是完全一样的。

 

3.2、Mysql主从复制过程的图形表示

 

 

四、MySQL支持的复制类型与MySQL复制应用类型

 

4.1、MySQL支持的复制类型

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

2）基于行的复制row：把改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持

3）混合类型的复制mixed: 默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。

 

4.2、MySQL复制应用类型

1）数据分布 (Data distribution )

2）负载平衡(load balancing)

3）读写分离(split reading and writting)

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

 

 

5、哪些原因会导致mysql主从数据不一致

 

1.网络的延迟

由于mysql主从复制是基于binlog的一种异步复制，通过网络传送binlog文件，理所当然网络延迟是主从不同步的绝大多数的原因，特别是跨机房的数据同步出现这种几率非常的大，所以做读写分离，注意从业务层进行前期设计。

 

2.主从两台机器的负载不一致

由于mysql主从复制是主数据库上面启动1个io线程，而从上面启动1个sql线程和1个io线程，当中任何一台机器的负载很高，忙不过来，导致其中的任何一个线程出现资源不足，都将出现主从不一致的情况。

 

3.max_allowed_packet设置不一致

主数据库上面设置的max_allowed_packet比从数据库大，当一个大的sql语句，能在主数据库上面执行完毕，从数据库上面设置过小，无法执行，导致的主从不一致。

 

4.mysql异常宕机情况下，如果未设置sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出现binlog或者relaylog文件出现损坏，导致主从不一致。

 

MySQL提供一个sync_binlog参数来控制数据库的binlog刷到磁盘上去。

默认sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。

 

如果sync_binlog>0，表示每sync_binlog次事务提交，MySQL调用文件系统的刷新操作将缓存刷下去。最安全的就是sync_binlog=1了，表示每次事务提交，MySQL都会把binlog刷下去，是最安全但是性能损耗最大的设置。这样的话，在数据库所在的主机操作系统损坏或者突然掉电的情况下，系统才有可能丢失1个事务的数据。但是binlog虽然是顺序IO，但是设置sync_binlog=1，多个事务同时提交，同样很大的影响MySQL和IO性能。虽然可以通过group commit的补丁缓解，但是刷新的频率过高对IO的影响也非常大。对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。

 

所以很多MySQL DBA设置的sync_binlog并不是最安全的1，而是100或者是0。这样牺牲一定的一致性，可以获得更高的并发和性能。

 

5.key自增键开始的键值跟自增步长设置不一致引起的主从不一致。

 

6.mysql本身的bug引起的主从不同步。

7.版本不一致，特别是高版本是主，低版本为从的情况下，主数据库上面支持的功能，从数据库上面不支持该功能。