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.版本不一致,特别是高版本是主,低版本为从的情况下,主数据库上面支持的功能,从数据库上面不支持该功能。