mysql性能优化系列8-mysql集群

1. 为什么要使用集群

（1）可用性
单个数据库实例宕机，其他的数据库实例可提供服务，对业务来说基本无感知。同时数据在多个实例之间的复制，提高数据的安全性和可用性。
（2）提高性能
业务对数据的访问可以分散到不同的数据库实例上，比如读写分离降低单个数据库实例的访问压力。

2. 集群方案

（1）MySQL Cluster
Mysql本身提供，优势：可用性和性能非常好。每份数据至少可在不同主机存一份拷贝，且冗余数据拷贝实时同步。但它的维护非常复杂，存在部分Bug，不适合比较核心的线上系统。
（2）DRBD
Distributed Replicated Block Device（磁盘网络镜像方案）是通过网络来镜像整个设备(磁盘)。它允许用户在远程机器上建立一个本地块设备的实时镜像，与心跳链接结合使用。
优势：软件功能强大，数据可在底层快设备级别跨物理主机镜像，且可根据性能和可靠性要求配置不同级别的同步。IO操作保持顺序，可满足数据库对数据一致性的苛刻要求。但非分布式文件系统环境无法支持镜像数据同时可见，性能和可靠性两者相互矛盾，无法适用于性能和可靠性要求都比较苛刻的环境，维护成本高于MySQL Replication。DRBD也是官方推荐的可用于MySQL高可用方案之一。
（3）MySQL Replication
MySQL Replication是使用最为广泛的一种方案。通过Replication功能提升系统的扩展性，硬件设备价格低廉，但性能成数量级地提高。

3. 复制

复制是指将主库的 操作通过二进制日志传到复制从库,然后从库根据日志重新执行操作，使得从库和主库的数据保持同步。MysQL支持一台主库同时向多台从库进行复制,从库同时也可以作为其他服务器的主库，实现链状的复制 。
由于MySQL并不是完全同步,所以主从库数据之间存在一定的差距，一般对实时性要求不高的数据可以通过从库查询，实时性要求高的数据仍然需要从主数据库获得。
优势：

• 如果主库宕机、从库可以提供服务
• 读写分离，降低从库压力
• 某些数据库维护工作比如备份，可以在从库上执行，避免影响主库提供服务

3.1 原理

• 主库在事务提交时会把数据变更作为事件Events记录在二进制日志文件Binlog中，主库上的sync_binlog参数控制Binlog日志刷新到磁盘
• 主库推送二进制日志文件Binlog中的事件到从库的中继日志Relay Log，从库根据Relay Log重做数据变更，从而主库和从库达到数据一致
• MySQL通过3个线程来完成主从库的数据复制，Binlog Dump线程在主库上，I/0线程和SQL线程跑在从库上。当在从库上启动复制时，首先创建I/0程连接主库，主库随后创建Binlog Dump线程读取数据库事件发送给I/0线程，I0线程将事件数据写到从库的中继日志Relay Log中去，从库上的 SQL线程读取中继日志RelayLog中重新执行操作。

3.2 文件参数

复制过程涉及了两个日志文件：二进制日志文件Binlog和中继日志文件Relay Log。Binlog会记录Create、Drop、Insert、Update、Delete等操作，但不会记录Select操作。Binlog支持Statement、Row、Mixed三种方式，通过show variables可以査看。
Relay Log的文件格式、内容和Binlog一样，区别在于从库的SQL线程在执行完Relay Log中的事件后，会自动删除Relay Log中的事件，避免Relay Log占用过多的磁盘空间。
为了保证从库Crash重启之后，从库的I/0线程和SQL线程仍然能够知道从哪里开始复制，从库上默认还会创建两个日志文件master.info（记录l/0线程读取主库Binlog的进度）和relay_log.info（SQL线程读取RelayLog的进度）。
可以通过 show slave status命令能够看到当前从库复制的状态。

• Master Host：主库 IP
• Master Port：主库 MySQL的端口号
• Master User：主库上主从复制的用户账号
• Master_Log_File：主库的Binlog文件
• Read_Master Log_Pos：从库I/0线程当前读取到的位置
• Relay_Log_File：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的位置

3.3 三种复制技术

Binlog有三种格式：

• Statement：基于SQL语句级别的Binlog，每条修改数据的SQL都会保存到Binlog
• Row：基于行级别，记录每一行数据的变化，并不记录原始SQL。在复制的时候，不会因为存储过程或触发器造成主从库数据不一致，但是日志量较Statement格式要大得多 。
• Mixed：混合Statement和Row模式，默认情况下采用Statement模式记录，某些情况下会切换到Row模式

binlog_format设置为Row时, MySQL实际上在 Binlog中逐行记录数据的变更, Row格式比 Statement格式更能保证从库数据的一致性(复制的是记录,而不是单纯操作 SQL)。当然, Row格式下的 Binlog的日志量很可能会增大非常多,在设置时需要考虑到磁盘空间间题。可以通过参数binlog_format在全局或者在当前session动态设置Binlog的格式，在全局设置会影响所有session。

3.4 复制架构

常见3种复制架构有一主多从复制、多级复制和双主复制/DrualMaster架构

• 一主多从：在主库查询压力非常大时，可以配置一主多从实现读写分离，在主库宕机时, 可以把一个从库切换为主库继续提供服务

• 多级复制
  MysQL的复制是主库推送Binlog日志到从库，主库的 I/0压力和网络压力会随着从库增加而增长(每个从库都会在主库上有一个独立的Binlog Dump线程来发送事件)，多级复制架构解决了一主多从场景下，主库额外的 I/0和网络压力

• 双主复制/Dual Master：主库Master和Master2互为主从， client客户端的写请求都访问主库Master，而读请求可以选择访问主库 Master或 Master2。
  
  双主复制还能和主从复制联合起来使用。

3.5 复制过程

（1）异步复制
主库执行完Commit后，在主库写入Binlog日志后即可成功返回客户端，无需等Binlog日志传送给从库。

步骤：

• 主从库安版本相同
• 在主库上设置一个复制使用的账户，并授予REPLICATION SLAVE权限
• 修改主库配置文件my.cnf，开启 BINLOG，并设置server-id的值
• 执行show master status得到主库上当前的二进制日志名和偏移量值。这个操作的目的是为了在从数据库启动以后,从这个点开始进行数据的恢复
• 修改从数据库的配置文件my.cnf，增加 server-id参数。server-id的值必须是唯一的，不能和主数据库的配置相同
• 在从库上使用 - -skip-slave- start选项启动从数据库，这样不会立即启动从数据库服务上的复制进程，方便我们对从数据库的服务进行进一步的配置
• 在从库指定复制使用的用户,主数据库服务器的IP、端口以及开始执行复制的日志文件和位置等

CHANGE MASTER TO MASTER_HOST='192.168.56.103',MASTER_PORT=3306,MASTER_USER='rep1',MASTER_PASSWORD='1234test' ,MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=428

• 在从库上启动slave线程

（2）半同步复制
MySQL5.5之前，复制是异步操作，这样存在一个隐患：当主库上写入一个事务并提交成功,而从库尚未得到主库推送的 Binlog日志时,主库宕机了或者主库可能因磁盘损坏、内存故障等造成主库上该事务 Binlog丢失,此时从库就可能损失这个事务，从而造成主从不一致。而半同步复制，是等待其中一个从库也接收到Binlog事务并成功写入Relay Log之后，才返回Commit操作成功给客户端。这样保证至少有两份日志记录，一份在主库Binlog上，另一份在从库的Relay Log上。半同步复制很大程度取决于主从网络RTT（往返时延），以插件semisync_master/semisync_slave 形式存在。

3.5 集群高可用插件

（1）Keepalived
Mysql+Keepalived可以实现双主高可用。Keepalived在之前文章中说过，不再详细解释。简单回顾下。
Keepalived是基于VRRP协议的一款高可用软件。Keepailived有一台主服务器和多台备份服务器，在主服务器和备份服务器上面部署相同的服务配置，使用一个虚拟IP地址对外提供服务，当主服务器出现故障时，虚拟IP地址会自动漂移到备份服务器。
Keepalived是一个工作在IP/TCP协议栈的IP层，TCP层及应用层实现交换机制的软件。作用是检测服务器的状态，如果有一台服务器宕机，或工作出现故障，Keepalived将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中。

• IP层： Keepalived会定期向服务器群中的服务器发送一个ICMP的数据包（Ping程）,如果发现某台服务的IP地址没有激活，Keepalived便将它从服务器群中剔除
• TCP层:主要以TCP端口的状态来决定服务器工作正常与否。如果Keepalived检测到对应端口没有启动，则Keepalived将把这台服务器从服务器群中剔除
• 应用层：对指定的URL执行HTTP GET。然后使用MD5算法对HTTP GET结果进行求和。如果这个总数与预期值不符，那么服务器将从服务器池中移除。该模块对同一服务实施多URL获取检查

（2）HAProxy
HAProxy是请求分发，类似于nginx的负载均衡，haproxy监听一个统一对外提供能力的端口，然后内部进行分发。除支持http7层处理外，还顺便为mysql支持4层转发。这里常常需要一个额外的机器来提供服务，但是由于只为haproxy使用，一个最低配机器即可。haproxy转发策略可以是轮询、加权或者随机等。
为了保证HAProxy的可靠性，常常用两台HAProxy，并用KeepAlived实现HAProxy高可用。