javaMySQL面试题-集群

　　1 、主从复制过程

　　MySQL主从复制：

　　●原理：将主服务器的binlog日志复制到从服务器上执行一遍，达到主从数据的一致状态。

　　●过程：从库开启一个I/O线程，向主库请求Binlog日志。主节点开启一个binlog dump线程，检查自己的二进制日志，并发送给从节点;从库将接收到的数据保存到中继日志(Relay log)中，另外开启一个SQL线程，把Relay中的操作在自身机器上执行一遍

　　●优点：

　　○作为备用数据库，并且不影响业务

　　○可做读写分离，一个写库，一个或多个读库，在不同的服务器上，充分发挥服务器和数据库的性能，但要保证数据的一致性

　　binlog记录格式：statement、row、mixed

　　基于语句statement的复制、基于行row的复制、基于语句和行(mix)的复制。其中基于row的复制方式更能保证主从库数据的一致性，但日志量较大，在设置时考虑磁盘的空间问题。

　　2 、数据一致性问题

　　"主从复制有延时"，这个延时期间读取从库，可能读到不一致的数据。

　　缓存记录写key法：

　　在cache里记录哪些记录发生过的写请求，来路由读主库还是读从库

　　异步复制：

　　在异步复制中，主库执行完操作后，写入binlog日志后，就返回客户端，这一动作就结束了，并不会验证从库有没有收到，完不完整，所以这样可能会造成数据的不一致。

　　半同步复制：

　　当主库每提交一个事务后，不会立即返回，而是等待其中一个从库接收到Binlog并成功写入Relay-log中才返回客户端，通过一份在主库的Binlog，另一份在其中一个从库的Relay-log，可以保证了数据的安全性和一致性。

　　全同步复制：

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

　　3 、集群架构

　　keepalived + VIP + MySQL 主从/双主

　　当写节点 Master db1 出现故障时，由 MMM Monitor 或 Keepalived 触发切换脚本，将 VIP 漂移到可用的 Master db2 上。当出现网络抖动或网络分区时，MMM Monitor 会误判，严重时来回切换写 VIP 导致集群双写，当数据复制延迟时，应用程序会出现数据错乱或数据冲突的故障。有效避免单点失效的架构就是采用共享存储，单点故障切换可以通过分布式哨兵系统监控。

　　架构选型：MMM 集群 -> MHA集群 -> MHA+Arksentinel。

　　4 、故障转移和恢复

　　转移方式及恢复方法

　　1. 虚拟IP或DNS服务 (Keepalived +VIP/DNS 和 MMM 架构)

　　问题：在虚拟 IP 运维过程中，刷新ARP过程中有时会出现一个 VIP 绑定在多台服务器同时提供连接的问题。这也是为什么要避免使用 Keepalived+VIP 和 MMM 架构的原因之一，因为它处理不了这类问题而导致集群多点写入。

　　2. 提升备库为主库(MHA、QMHA)

　　尝试将原 Master 设置 read_only 为 on，避免集群多点写入。借助 binlog server 保留 Master 的 Binlog;当出现数据延迟时，再提升 Slave 为新 Master 之前需要进行数据补齐，否则会丢失数据。