主从复制_mysql主从复制简介

篇首语：本文由编程笔记#小编为大家整理，主要介绍了mysql主从复制简介相关的知识，希望对你有一定的参考价值。

 mysql  Replication概述：

mysql replication俗称MySQL AB 复制或者主从复制，是mysql官方推荐的数据同步技术。

优点：

1.通过增加从服务器来提高数据库平台的可靠性，在主服务器上执行写入和更新，在从服务器上向外提供读功能，可以动态地调整从服务器的数量，从而缓解主服务器平台的高性能

2.提高数据安全性，因为数据已复制到从服务器，主服务器数据异常时，可以将从服务器复制进程终止来达到保护数据完整性的特点。

3.在主服务器上生成实时数据，而在从服务器上分析这些数据，从而缓解主服务器的性能。

MySQL复制类型：

异步复制：mysql默认的复制就是异步，主库在执行完客户端提交的实务后会立即将结果返给客户端，并不关心从库是否已经接受并处理。

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

半同步复制：主库在执行完客户端提交的事务后不是立即返回给客户端，而是至少一个从库接收到并写入到relay log 中才返回给客户端。相对于异步复制，半同步复制 提高了数据的安全性，同时也造成了一定程度的延迟，这个延迟做少是一个TCP/IP往返的时间。所以半同步最好在低延时的网络中使用。当出现超时情况时，源主服务器会暂时切换到异步复制模式，直到至少有一台设置为半同步复制的从服务器及时收到信息为止。

半同步复制的潜在问题

客户端事务在存储引擎层提交后，在得到从库确认的过程中，主库宕机了。此时可能的情况有两种：

• 事务还没发送到从库上：此时，客户端会收到事务提交失败的信息，客户端会重新提交该事务到新的主上，当宕机的主库重新启动后，以从库的身份重新加入到该主从结构中，会发现，该事务在从库中被提交了两次，一次是之前作为主的时候，一次是被新主同步过来的。

• 事务已经发送到从库上：此时，从库已经收到并应用了该事务，但是客户端仍然会收到事务提交失败的信息，重新提交该事务到新的主上。

MySQL支持的复制模式：

基于 SQL 语句的复制(statement-based replication, SBR)：在主服务器上执行的SQL语句，在从服务器上执行同样的SQL语句，效率比较高。

基于行的复制(row-based replication, RBR)：主服务器把表的行变化作为事件写入到二进制日志中，主服务器把代表了行变化的事件复制到从服务中。

混合模式复制(mixed-based replication, MBR)：先采用基于语句的复制，一旦发现基于语句无法精确复制时，再采用行。

在MySQL5.1.4之前的版本都只能使用基于 SQL 语句的复制方式，MySQL5.6.5和往后的版本是基于global transaction identifiers(GTIDs)来进行事务复制。当使用GTIDs时可以大大简化复制过程，因为GTIDs完全基于事务，只要在主服务器上提交了事务，那么从服务器就一定会执行该事务。

通过设置服务器的系统变量binlog_format来指定要使用的格式：

RBR 的优点

• 任何情况都可以被复制，这对复制数据来说是最安全可靠的


• 更少的行级锁表


• 和其他大多数数据库系统的复制技术一样


• 多数情况下，从服务器上的表如果有主键的话，复制就会快很多


• Binlog 文件较大


• 复杂的回滚时 binlog 中会包含大量的数据


• 主服务器上执行 多个UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而且只写为一个操作事物，这会导致频繁发生 binlog 的并发写问题


• 不能通过查看日志来审计执行过的sql语句，不过可以通过使用mysqlbinlog  --base64-output=decode-rows --verbose来查看数据的 变动


• 历史悠久，技术成熟· binlog 文件较小


• binlog 中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况


• binlog可以用于实时的还原，而不仅仅用于复制


• 主从版本可以不一样，从服务器版本可以比主服务器版本高


• 不是所有的 UPDATE 语句都能被复制，尤其是包含不确定操作的时候。


• 复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁


• 对于一些复杂的语句，在从服务器上的耗资源情况会更严重

RBR 的缺点

• Binlog 文件较大


• 复杂的回滚时 binlog 中会包含大量的数据


• 主服务器上执行 多个UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而且只写为一个操作事物，这会导致频繁发生 binlog 的并发写问题


• 不能通过查看日志来审计执行过的sql语句，不过可以通过使用mysqlbinlog  --base64-output=decode-rows --verbose来查看数据的 变动

SBR 的优点

• 历史悠久，技术成熟· binlog 文件较小


• binlog 中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况


• binlog可以用于实时的还原，而不仅仅用于复制

主从版本可以不一样，从服务器版本可以比主服务器版本高

SBR 的缺点

• 不是所有的 UPDATE 语句都能被复制，尤其是包含不确定操作的时候。


• 复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁

对于一些复杂的语句，在从服务器上的耗资源情况会更严重

• 如下函数的语句不能被正确地复制：load_file(); uuid(), uuid_short(); user(); found_rows(); sysdate(); get_lock(); is_free_lock(); is_used_lock(); master_pos_wait(); rand(); release_lock(); sleep(); version();


• 在日志中出现如下警告信息的不能正确地复制：[Warning] Statement is not safe to log in statement format.或者在客户端中出现show warnings


• Insert … select语句会执行大量的行级锁表

无论选择哪种方式复制，都会影响到复制的效率以及服务器的损耗，以及数据一致性问题，目前其实没有很好的客观手段去评估一个系统更适合哪种方式的复制。

关于主从同步的监控问题，Mysql 有主从同步的状态信息，可以通过命令 show slave status获取，除了获知当前是否主从同步正常工作，另外一个重要指标就是 Seconds_Behind_Master，从字面理解，它表示当前 MySQL 主从数据的同步延迟，单位是秒。但这个指标从 DBA 的角度并不能简单的理解为延迟多少秒，感兴趣的同学可以自己去研究，但对于应用来说，简单的认为是主从同步的时间差就可以了，另外，当主从同步停止以后，重新启动同步，这个数值可能会是几万秒，取决于主从同步停止的时间长短，我们可以认为数据此时有很多天没有同步了，而这个数值越接近零，则说明主从同步延迟最小，我们可以采集这个指标并汇聚曲线图，来分析我们的数据库的同步延迟曲线，然后根据此曲线，给出一个合理的阀值，主从同步的时延小于阀值时，我们认为从库是同步的，此时可以安全的从从库读取数据。

复制的工作过程

 该过程的第一部分就是master记录二进制日志。在每个事务更新数据完成之前，master在二日志记录这些改变。MySQL将事务串行的写入二进制日志，即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后，master通知存储引擎提交事务。

复制过程的限制

• MySQL5.6之前的版本复制操作在Slave上执行是串行化的，Master上的并行更新会导致数据复制延迟。


• 所有MYSQL服务器的版本都要高于3.2，还有一个基本的原则就是从服务器的数据库版本可以高于主服务器数据库的版本，但是不可以低于主服务器的数据库版本。