MySQL生产环境高可用架构详解

GTID同步集群
mysql内部提供的同步机制，基于一个全局的事务id来标识同步进度，保证同步不会因为偏移量的的问题造成数据不一致的情况；也是生产中比较常用的方式；
主节点上配置：
gtid_mode=on
enforce_gtid_consistency=on
log_bin=on
server_id=单独设置一个
binlog_format=row
从节点上配置
gtid_mode=on
enforce_gtid_consistency=on
log_slave_updates=1
server_id=单独设置一个
集群扩容
加新节点的时候，需要先把已有的数据导出来，通过mysqldump工具导出sql语句，导完了再配置主从，需要把业务停下来做。
半同步复制
在mysql的主从架构中，默认是采用的异步复制的方式，也就是说，主库与从库之间只有主库单方面的把已经完成的操作给从库，从库是否已经接收或者执行了。主库是都不知道的，在这种情况下就很容易出现，主库已经把数据写好了。从库却还没有收到消息。这时我们客户端去从库查找数据，就发现数据不存在。这个问题频繁出现明显不能够被接受。这时我们就需要进行同步操作，也就是主库等待从库把数据同步完成了，我们主库才算真的成功。但是如果这样做，从库如果挂掉了，从库没办法响应主库，告诉主库从库已经完成数据的操作，主库就变的阻塞掉了。所以我们需要半同步机制来操作了。我们给主库等待从库同步时间获取响应设置一个超时时间，如果超过超时时间，我们主库直接算作完成。
在/usr/local/mysql/lib/plugin文件夹中又存在semisync_master.so和semisync_slave.so插件，分别在主节点和从节点安装这两个插件；
主节点执行：
install plugin rpl_semi_sync_master soname ‘semisync_master.so’;
查看当前状态show global variables like ‘rpl_semi%’;

rpl_semi_sync_master_enabled 为OFF，还没有打开这种半同步方式，
rpl_semi_sync_master_timeout 默认同步超时时间为10秒
我们打开这种半同步方式：
set global rpl_semi_sync_master_enabled=ON;
主库配置完毕；
从节点执行：
安装插件
install plugin rpl_semi_sync_slave soname ‘semisync_slave.so’;
查看
show global variables like ‘rpl_semi%’;
修改
set global rpl_semi_sync_slave_enabled = on;

主从架构的数据延迟问题
我们主节点与客户端之间很大可能是并发执行，同时插入很多数据，我们主从之间的dump线程默认是单线程的，这效率明显不够用。我们也
从节点搜索
show global variables like ‘slave_parallel_%’;

这个就是并行度目前为0；
我们修改 DATABASE为LOGICAL_CLOCK
把0改成我们需要并行度即可；
加大主从之间的并行量。
mysql高可用方案
我们之前做的主从架构，如果做成环状互为主从，如果挂掉一个，我们就需要手动的调整他。手动的调整必然也需要重启服务器。又需要手动调整又需要重启数据库。这都是很严重的问题；
通过MMM,MHA，MGR三种方案可以自动调整主从之间存在的问题；(操作不一定要会机制要懂)
MMM
至少存在两个主节点，做双主复制，只有一个对外提供读写服务，通过监控端来监控服务，监控master状态。一旦发现读写库master挂了，监控器会把读写库切换导另一个主服务器上。
怎么切换：虚拟ip概念，所有的读写根据这个虚拟ip来读写。当这个虚拟ip在哪个主节点，那么就是哪个主节点来执行读写操作，也就是说当控制端发现原来读写的主节点挂了，他就会把虚拟ip切换到另一个主节点上。实现高可用，同时原来属于读写节点的从节点也会切换过来。
读写效率高，不知此GTID，容易丢失数据，只监控主节点，如果所有主节点都挂了，那就挂了，没办法切换成从节点，用的比较少。
MHA
MHA需要单独部署一台机器，其他的机器分成多个集群组，每个集群组中包含主节点和从节点，当主节点挂了，从节点自动会被切换上来成为主节点，即使主节点没有问题，也可以在线操作把主节点和从节点切换。监控mysql的日志去判断当前节点是否正常。支持GTID，但是还是存在需要同步的问题，就有可能造成数据不一致的可能。目前用的最多的MHA。

缺点：必须自己开发虚拟IP转移的脚本，大量的脚本需要定制；
MGR
5.7.17版本官方推出的。最大的好处就是解决数据一致性的问题。
比如我们现在有三个主节点，其中任意一个主节点执行事务时，他需要通过至少一半以上的节点同意才能成功。（类似）
需要小心：目前还没有得到一个很权威的认证。

分库分表

把数据分到不同的数据库或者把数据分到不同的表。统称为数据分片。
垂直分片：把日志表竖向的拆开，拆开成两张表，根据业务去拆分。把用户表放一个库里，把订单表放在一个库里。如果业务有快速的变动，我们这种方式会跟不上业务变更的速度。并没有办法解决单点数据库数据量太大的问题，比如我用户表单表的数据量已经超级大了。查询速度依然得不到提升。
水平分片：用户表数据量太大了，把用户表拆成两个个表，放到不同的库里。比如我们根据id来分，偶数放一个表里，奇数放一个表里。，数据量减少了一半，速度就快了一点。不再根据业务来分，而是根据字段来区分，从根本上解决单表的数据量太大的问题，这是我们数据库分库分表的关键所在。
id取模：优点，数据均匀，扩容麻烦。如果按2取模，把数据分成两份了。如果我需要扩容，重新取模为3，那么所有的数据都要调整。相当的麻烦，数据量比较稳定的。
范围：时间分片，按年份，月份来分表。容易扩容，数据分布不够均匀。
按地区，枚举值来分都是可以的。
分库分表的缺点
事务的一致性：如果我们按id取模来插插数据，插10条数据，5条插一张表，另外5条插另外一张表。这就需要考虑到分布式事务的问题，分布式事务本来就已经非常麻烦了，再加上这个东西，就变得更加棘手了。分布式事务是尽量需要避免的。
主键避重如果有主键重复了，数据库没办法帮我们检测这些数据。加重了数据的麻烦程度。使用UUID也很容易造成冲突
运维工作量没做一个操作都要考虑数据片是怎么分布的。
什么时候需要分库分表
单表超过500W，单表容量达到2GB就需要分库分表了。需要考虑数据增长，后期增长缓慢的按照三年左右的业务量来预估人数。
业务数据这一类增长速度快速且稳定的数据，一半需要按照预估量两倍以上来分库分表，后期增容是非常麻烦的。分库分表能不分的时候尽量不要分，后期维护很麻烦。