Mysql架构之Mysql复制

Mysql集群架构

好处

（1）提高高可用。如果某个数据库实例出现问题，这时候可由其他的数据库实例提供服务，或者可以快速的切换到其他数据库实例，对于业务来说基本上无感知，也不会导致业务的中断。同时过多的数据在多个数据库实例之间的复制，提高了数据的安全性和可用性。

（2）提高性能。业务对数据的访问可以分散到不同的数据库实例上，可以根据数据访问类型不用，将不同性质的访问操作，进行分离，都可以降低单个数据库实例的访问压力。

Mysql集群可行性方案

Mysql Cluster

由Mysql本身提供，优势：可用性非常高，性能非常好。每份数据至少可在不同主机存一份拷贝，且冗余数据拷贝实时同步。但它的维护非常复杂，存在部分Bug，目前还不适合比较核心的线上系统，所以不推荐。

DRBD磁盘网诺镜像方案

Distributed Replicated Block Device，其实现方式是通过网络来镜像整个设备(磁盘).它允许用户在远程机器上建立一个本地块设备的实时镜像,与心跳链接结合使用,也可看做一种网络RAID。

优势：软件功能强大，数据可在底层快设备级别跨物理主机镜像，且可根据性能和可靠性要求配置不同级别的同步。IO操作保持顺序，可满足数据库对数据一致性的苛刻要求。但非分布式文件系统环境无法支持镜像数据同时可见，性能和可靠性两者相互矛盾，无法适用于性能和可靠性要求都比较苛刻的环境，维护成本高于MySQL Replication。另外，DRBD也是官方推荐的可用于MySQL高可用方案之一，所以这个可根据实际环境来考虑是否部署。

Mysql Replication

在实际应用场景中，MySQL Replication是使用最为广泛的一种提高系统扩展性的设计手段。众多的MySQL使用者通过Replication功能提升系统的扩展性后，通过简单的增加价格低廉的硬件设备成倍 甚至成数量级地提高了原有系统的性能。

Mysql复制

什么是Mysql复制？

复制是指将主数据库的DDL和DML操作通过二进制日志传到从库上，然后再从库上对这些日志进行重做，从而使得从库和主库的数据库同步。Mysql支持一台主库同时向多台从库进行复制，从库同时也可以作为其他服务器的主库，实现链状的复制。

注意：由于Mysql实现的并不是完全的同步复制，所以主从库之间存在一定的差距，在从库上进行的查询操作需要考虑到这些数据的差异，一般只有更新不频繁的数据或者对实时性要求不高的数据才可以通过从库查询，实时性要求高的数据仍是需要通过主库查询。

优点：

1.如果主库出现问题，可以快速切到从库提供服务；

2.可以在从库上执行查询操作，降低主库的访问压力；

3.某些数据维护工作，比如备份，可以在从库上进行，以避免备份期间影响主库的服务。

Mysql复制原理概述：

（1）首先，Mysql主库在提交事务是会把数据变更作为事件Events记录在二进制日志binlog中；主库上的sync_binlog参数控制binlog日志刷新到磁盘上。

（2）主库推送二进制日志文件Binlog中的事件到从库的Relay Log,之后从库根据Relay Log重做数据变更操作，通过逻辑复制以此来达到主库和从库的数据一致。

Mysql通过3个线程来完成主从库间的复制：其中Bin-log Dump线程跑在主库上，I/O线程和SQL线程跑在从库上。当在从库上启动复制时，会先启动I/O线程连接主库，主库随后创建Bin-log Dump线程读取数据库中事件并发送给I/O线程，I/O线程获取到事件数据后更新到从库的Relay Log中，之后从库上的SQL线程读取Relay Log中更新的数据库事件并重做。

可以通过SHOW PROCESSLIST命令在主库上查看Bin-log Dump线程的运行情况，从Bin-log Dump线程状态可以看出，Mysql的复制是主库主动推送日志到从库上的，是属于“推”日志的方式来做同步的。同样的也可以在从库上使用SHOW PROCESSLIST命令查看I/O线程和SQL线程的运行情况。I/O线程等着主库上的Bin-log Dump线程发送事件并更新到Relay log中取，SQL线程读取Relay log并应用变更到数据库上。

复制过程中的各类文件解析

日志文件

复制过程中涉及了两类非常重要的日志：二进制日志文（Binlog）和Relay log。Bin-log会把Mysql中的所有的DDL和DML对应的操作以二进制的形式记录到日志文件中，不包括DQL语句对应的操作。

可以通过show variables查看binlog的格式。binlog支持三种格式Statement、Row、Mixed，也对应了Mysql的3中复制技术。

relay log的文件格式、内容和binlog一样，唯一的区别在于从库上的SQL线程执行完当前relay log中的事件后，SQL线程会自动删除当前relay log，避免从库上的relay log占用过多的磁盘空间。为了保证从库crash重启之后，从库I/O线程个SQL仍知道从哪儿开始复制，从库默认还会创建两个文件master.info和relay_log.info用来保存复制进度。这两个文件在磁盘上以文件形式分别记录了I/O线程当前读取主库binlog文件的进度和SQL线程中执行relay log的进度。

可以通过show slave status命令查看当前从库复制状态。对应的主要参数：

Master Host: 主库的 IP.

Master User 主库上, 主从复制使用的用户账号,

Master Port:主库 MySQL的端口号,

Master_Log_File:从库的I/0线程当前正在读取的主库 Binlog的文件 。

Read_Master Log_Pos:从库I/0线程当前读取到的位置。

Relay_Log_File: 从库 SQL线程正在读取和应用的中继日志 Relay Log的文件名 。

Relay_Log_Pos: 从库 SQL线程当前读取并应用的中继日志 Relay Log的位置。

Relay_Master_Log_File:从库 SQL线程正在读取和应用的 Relay Log对应于主库Binlog的文件名 。

Exec_Master_Log_Pos:中继日志 RelayLog中 Relay_Log_Pos位置对应于主库 Binlog 的位置。

Binlog三种文件格式

Statement：基于SQL语句级别的Binlog每条DDL和DML语句都会保存到Binlog里。

Row：基于行级别的，记录每一行数据的变化。也就是将每行数据的变化都记录到Binlog里，记录非常详细，但并不是记录原始的SQL；在复制的时候，并不会因为存储过程或触发器造成主从数据不一致的问题，但是记录的日志量比Statement格式要大的多。

Mixed：混合模式。混合了Statement和Row两种模式。默认情况是Statement格式，某些情况会切换到Row模式。

异步复制和半同步复制

异步复制

在 MySQL5.5之前, MySQL的复制是异步复制,主库和从库的数据之间存在一定的延迟,这样存在一个隐患:当在主库上写一个事务并提交成功,而从库尚未得到主库推送的 Binlog日志时,主库宕机了,例如主库可能因磁盘损坏、内存故障等造成主库上该事务 Binlog丢失,此时从库就可能损失这个事务,从而造成主从不一致。

半同步复制

半同步复制，是等待其中一个从库也接收到Binlog事务并成功写入Relay Log之后，才返回Commit操作成功给客户端；如此半同步就保证了事务成功提交后至少有两份日志记录，一份在主库Binlog上，另一份在从库的Relay Log上，从而进一步保证数据完整性；半同步复制很大程度取决于主从网络RTT（往返时延），以插件 semisync_master/semisync_slave 形式存在。