mysql replication

Posted 2021-04-30 数据库笔记

简介

mysql replication即mysql主从复制技术。是mysql本身自带的一个功能。其复制功能并不是copy文件来实现的。而是借用binlog日志文件(类似oracle archivelog)里面的SQL命令实现的主从复制。

MySQL复制技术有以下一些特点：
(1)数据分布(Data distribution)
(2)负载平衡(load balancing)
(3)备份(Backups) 
(4)故障切换(failover)

mysql replication原理

MySQL的主从复制默认是一个异步的复制过程，数据库从一个Master复制到Slave数据库，在Master与Slave之间实现整个主从复制的过程是由三个线程参与完成的，其中有两个线程(SQL线程和IO线程)在Slave端，另一个线程(IO线程)在Master端。

mysql replication流程图

流程说明：

MySQL主从复制之前我们需要先启动Master数据库然后再启动Salve数据库，然后在Salve数据库中执行startslave;，执行完成之后，流程就如下了：

①Salve的IO线程会读取mastr.info文件中配置好的主库信息，比如说存放的有：Master数据库的用户名、密码、端口、还有Master的binlog索引位置。

②拿到信息之后就带着信息去链接Master的主库IO线程

③当主库的IO线程先检查SLave传过来的配置信息是否正确，如果正确，就拿着Slave传过来的binlog索引位置和Master库的binlog文件中最后一个索引位置进行对比，如果一致就陷入等待状态，等待Master的binlog索引位置更新；

④如果不一致就把Slave传过来的binlog索引位置往后的所有SQL语句包括最后一条SQL语句的索引位置发送个给Slave的IO线程；

⑤Slave的IO线程拿到信息之后，先把Master传过来的binlog索引在Slave的master.info文件中进行更新；

 ⑥然后再把Master传过来的SQL语句写入到relay文件中，然后继续循环执行第二个步骤；

⑦Slave的SQL线程会一直持续的观察relay日志文件中是否有改动，如果没有就继续监听；

⑧如果发现relay中有变动，那么就获取变动的内容转换为SQL语句，并且把SQL语句在Salve的数据库中进行执行

mysql replication复制模式

MySQL的复制有三种模式：Statement Level、Row Level、Mixed Level。复制级别的不同，会导致Master端二进制日志文件的生成形式的不同。

  Statement Level：基于语句的复制：  在主服务器上执行的SQL语句，在从服务器上执行同样的语句。这种模式的优点是Master端不需要记录每一行数据的变化，二进制日志文件量小，IO成本低，速度快。

 相应的，该模式存在的缺点如下：由于记录的是执行语句，就需要额外的知道每条语句执行的上下文信息，以保证该相同的操作在Slave端执行时能够得到和 Master同样的结果。但由于MySQL功能的不断增多，这种复制模式需要考虑的情况也就越来越多，出现bug的几率也就也大。

  Row Level：基于行的复制：把每行改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持。这种模式的优点是：日志文件不会将SQL语句执行的上下文记录下来，只是记录哪一条数据修改了，修改成什么样子了；这样做可以避免如某些特定情况下存储过程、trigger的调用和触发没有被正确执行等复制问题。

  同样，该模式也存在缺点：日质量的成倍增加。例如：执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。这样就大增加了复制过程的IO成本，导致速度下降、性能下降。

  Mixed Level：该模式结合了之前两种模式的优点，规避了二者的缺点。在该模式下，MySQL会根据执行的每一条语句来区分记录日志文件的格式。举例说明，当涉及到复杂的存储过程时，采用Row Level，规避Statement Level存在的某些场景无法复制的问题；当涉及到Alter table等操作时，采用Statement Level来规避Row Level带来的日志量巨大的问题。

mysql replication复制级别

异步复制（Asynchronousreplication）

MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收到binlog并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

 

全同步复制（Fullysynchronous replication）

指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

 

半同步复制（Semisynchronousreplication）（5.5版后）

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待从库接收到日志并传递是否成功接收日志的标识码（ack）,主库接收到ack后才会将结果返回给客户端。如果主库超过rpl_semi_sync_master_timeout设置的时长仍未收到ack，则判定为超时，主库会将复制模式降级为异步复制，等待修复后重新收到ack，再升级为半同步复制。

mysql replication搭建步骤(1主1从)

①配置slave的my.cnf文件：

log_bin = /mysql/binlog/mysql-bin（和主库一致）

server_id = X（保证唯一）

relay_log = /mysql/log/relay_log/mysql-relay-bin（中继日志文件位置）

log_slave_updates= TRUE（将复制事件写进自己的二进制日志）

read_only = 1（备库只读模式）

配置完成重新启动mysql

②创建复制帐号

主库执行：

mysql>grantreplication slave on *.* to 'repl'@'192.168.233.3' identified by '123456';

③查看主库binlog文件名和索引位置

④建立复制关系

mysql> CHANGEMASTER TO MASTER_HOST='192.168.233.2',

-> MASTER_USER='repl',

-> MASTER_PASSWORD='123456',

->MASTER_LOG_FILE='mysql-bin.000007',(步骤③查到的file值),

->MASTER_LOG_POS=0;(MASTER_LOG_POS的值为0，表示从日志的开始位置开始复制)

⑤查看复制状态

mysql> SHOWSLAVE STATUS\G

在这里主要是看:

    Slave_IO_Running=Yes

    Slave_SQL_Running=Yes

slave的I/O和SQL线程都已经开始运行，而且Seconds_Behind_Master不再是NULL。日志的位置增加了，意味着一些事件被获取并执行了。如果你在master上进行修改，你可以在slave上看到各种日志文件的位置的变化，同样，你也可以看到数据库中数据的变化。