4_mysql（主从复制）

一、主从复制

1.介绍
两台或以上数据库实例，通过binlog二进制日志，实现数据的“同步”关系。
2.主从复制原理

1. 从库：CHANGE MASTER TO，将ip、port、user、password、binlog、position写入到master.info进行记录
2. 从库：START SLAVE，启动IO_THREAD和SQL_THREAD，
3. 从库：IO_THREAD读取master.info信息，连接主库
4. 主库：分配DUMP_THREAD线程响应从库，该连接为长连接
5. 从库：IO_THREAD根据master.info记录的binlog文件名和position号向主库请求最新日志
6. 主库：DUMP_THREAD检查binlog日志，如果有新的将截取日志返回给从库
7. 从库：IO_THREAD将发送来的binlog存储到TCP/IP缓存中，立即返回ACK给主库，主库工作完成
8. 从库：IO_THREAD将缓存中的数据刷写到relay-log中，同时更新master.info文件中的binlog文件名和position，IO_THREAD工作完成
9. 从库：SQL_THREAD读取relay-log.info获取上次指定到的relay-log位置作为起点，回放relay-log
10. 从库：SQL_THREAD回放完成后，更新relay-log.info文件
* 若 `relay_log_purge` 功能开启，SQL_THREAD将定期删除应用过的relay-log；DUMP_THREAD回实时监控主库中的binlog变化，若有新变化，则会发信息通知从库

3.主从故障分析及处理
3.1 IO线程
3.2 SQL线程
SQL线程的故障大概率出现在直接对从库增删改或双主架构中：创建的对象已经存在、需要操作的对象不存在、约束冲突
故障修复过程：
思路一：以主库为准，将从库反操作，重启线程
思路二：以从库为准(已知此时从库数据状态与主库其实是相同的，有风险)，跳过此次复制错误
思路三：重新搭建主从
4.主从延时
4.1 介绍：主库发生了操作，从库“很久”才追上
4.2 主从延时原因
4.2.1 主库方面
外部：
网络
硬件
主库业务繁忙
拆分业务(分布式)：组件分离、垂直拆分、水平拆分
大事务的拆分
从库太多
内部：
binlog更新时机：sync_log_bin=1
未开GTID时，主库可以并发事务，但从库需要按序执行日志，dump只能串行传输
开启GTID后(5.7+默认开启，5.6+出现该功能)，主库可以并发事务，dump也可以并行传输(因为GTID是连续递增的)
4.2.2 从库方面
外部：
网络、硬件(比主库低)
内部：
IO线程
写relay-log --> IO性能
SQL线程
5.6 版本开启GTID之后,加入了SQL多线程的特性,但是只能针对不同库(database)下的事务进行并发回放.
5.7 版本开始GTID之后,在SQL方面,提供了基于逻辑时钟(logical_clock),binlog加入了seq_no机制,
真正实现了基于事务级别的并发回放,这种技术我们把它称之为MTS(enhanced multi-threaded slave).
大事务拆成多个小事务,可以有效的减少主从延时.

二、主从复制高级进阶

2.1 延时从库
普通的主从复制，在处理物理故障损坏时比较擅长。但对于逻辑损坏，如主库意外出现了删库操作，从库若立即同步，则主从的数据都会受损。
延时从库是我们人为配置的一种特殊从库，主库做了某项操作之后，从库会延时N小时回放(SQL线程的延时)，可以处理逻辑损坏。
2.2 过滤复制
2.3 半同步复制
用于解决传统异步非GTID复制工作模型下主从数据不一致问题

1. 主库执行新的事务,commit时,更新 show master status\G ,触发一个信号
2. binlog dump 接收到主库的 show master status\G信息,通知从库日志更新了
3. 从库IO线程请求新的二进制日志事件
4. 主库会通过dump线程传送新的日志事件,给从库IO线程
5. 从库IO线程接收到binlog日志,当日志写入到磁盘上的relaylog文件时,给主库ACK_receiver线程发送ACK
6. ACK_receiver线程触发一个事件,告诉主库commit可以成功了
7. 如果ACK达到了我们预设值的超时时间(默认10s),半同步复制会切换为原始的异步复制.

2.4 GTID复制
用于保证主从复制中的高级特性；
优点：保证事务全局同一；截取日志更加方便；判断主从工作状态更加方便；传输日志，可以并发传输；主从复制构建更加方便。

三、高可用MHA

3.1 介绍
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，该工具仅适用于MySQL Replication 环境，目的在于维持master主库的高可用性。MHA 是自动的 master 故障转移和 slave 提升的软件包，基于标准的MySQL复制（异步/半同步）。
MHA由两部分组成：MHA Manager（管理节点）和 MHA Node（数据节点）。
MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。
MHA Node运行在每台MySQL服务器上。
MHA Manager 会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。
3.2 MHA工作原理
3.2.1 监控节点
每隔 ping_interval=2 秒探测一次，如果主库还没有心跳，则认为主库宕机，进入failover过程
3.2.2 选主策略
3.2.3 数据补偿
当SSH能连接，从库使用 save_binary_logs 脚本对比主库GTID 或者position号,立即将二进制日志保存至各个从节点并且应用；
当SSH不能连接，从库之间使用 apply_diff_relay_logs 对比relaylog差异进行补偿
3.2.4 failover
主从身份切换，所有从库取消和原有主库的复制关系，与新主库重新构建主从关系；
manager 调用 masterha_conf_host 脚本将故障库踢出集群；
MAH是一次性的高可用，Failover后manager会自动退出。
3.3 架构改造方案
日志补偿：binlog server
应用透明：vip
实时提醒：sendreport

四、读写分离Atlas

4.1 介绍
读写分离、从库负载均衡、IP过滤、自动分表、DBA平滑上下线DB node、自动摘除宕机的DB

五、分布式中间件Mycat

使用Mycat可以搭建读写分离、高可用、垂直切分和水平切分架构，使用分布式的架构，有效解决大数据库中面对海量数据的性能瓶颈。
5.1 垂直切分
一个数据库由很多表的构成，每个表对应着不同的业务，垂直切分是指按照业务将表进行分类，分布到不同的数据库上面，这样也就将数据或者说压力分担到不同的库上面。
5.2 水平分片
相对于垂直拆分，水平拆分不是将表做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中包含一部分数据。
5.3 全局表
一个真实的业务系统中，往往存在需要join操作关联起来的表，而有些类似字典表的表格，会与多个业务表之间都有关系，在分片的情况下，当业务表因为规模而进行分片以后，业务表与这些附属的字典表之间的关联，就成了比较棘手的问题，考虑到字典表具有以下几个特性：
① 变动不频繁
② 数据量总体变化不大
③ 数据规模不大，很少有超过数十万条数据
全局表较好的避免了跨库join操作性能低下的问题。
5.4 E-R分片
虽然全局表能较好的解决跨库join带来的性能消耗问题，但并不是所有join操作的需求都属于这类有数据字典表的，一些join操作可能只是几张表之间的关联关系(如主键和外键)，这时候可以使用E-R关系的来设计分片策略。
在E-R分片中，父表可以使用任意一种分片策略进行分片，而子表的数据依赖与符表进行分片