MS系列：Mysql、Mycat

一致性哈希分片

什么是一致性哈希
http://www.zsythink.net/archives/1182
一致性哈希的扩容
https://blog.csdn.net/ydyang1126/article/details/70773557?locationNum=11&fps=1

慢日志

http://www.zsythink.net/archives/1260

读快照–可重复读

导出大批量数据-如何保证数据一致性
http://www.zsythink.net/archives/1436

GTID

MySQL5.6 以后，提供了基于 GTID 多开启多线程同步复制的方案，即每个库有一个单独的(sql thread)。
进行同步复制，这将大大改善 MySQL 主从同步的数据延迟问题，配合 Mycat 分片，可以更好的将一个超级大表的数据同步的时延降低到最低。此外，用 GTID 避免了在传送 binlog 逻辑上依赖文件名和物理偏移量，能够更好的支持自动容灾切换，对运维人员来说应该是一件令人高兴的事情，因为传统的方式里，你需要找到 binlog和 POS 点，然后 change master to 指向，而不是很有经验的运维，往往会将其找错，造成主从同步复制报错，在 mysql5.6 里，无须再知道 binlog 和 POS 点，需要知道 master 的 IP、端口，账号密码即可，因为同步复制是自动的，mysql 通过内部机制 GTID 自动找点同步。
即使是并发复制机制、仍然无法避免主从数据库的数据瞬间不同步的问题，因此又有了一种增强的方案，即galera for mysql、percona-cluster 或者 mariadb cluster 等集群机制，他们是一种多主同步复制的模式，可以在任意节点上进行读写、自动控制成员，自动删除故障节点、自动加入节点、真正给予行级别的并发复制等强大能力!
关于GDIT，可参考：https://yq.aliyun.com/articles/57731

MyCat的使用瓶颈

https://blog.csdn.net/u013235478/article/details/53178657
1. 当分片数量比较多时对非分片字段查询性能低
2. 分页排序性能低
3. 除非E-R分片，否则join查询性能低
4. XA事务：mysql设置了自动提交时，mycat不能回滚已提交的数据库；mysql设置不自动提交时，mycat等待事务超时时进行回滚。

MyCat高可用

Keepalived+HAproxy+Mycat 集群+MySQL 主从

MyCat的坑

• Mycat不负责主从复制，配置了主从自动切换后，写操作会立即切换到从服务器，不会考虑从服务器是否数据已同步，可能会造成数据错误。有如下解决方案可以缓解这个问题：

  1. 使用mysql5.7的GDIT的功能提高复制速度，减小数据丢失的可能性。
  2. 主库使用InnoDB引擎，从库使用MyISAM引擎，提高复制速度。
  3. 针对数据实时性和可用性要求比较高的场景，需要使用数据库集群，比如Galera；

• Mycat的夸库事务处理

  1. 如果mysql设置了自动提交，后面的事务失败了，前面提交的事务无法回滚。
  2. 如果mysql设置不自动提交，等到事务锁timeout的时候会回滚，但是timeout的时间比较长。

• 不支持一些Sql语句

  1. 除了分片规则相同、ER 分片、全局表、以及 SharedJoin，其他表之间的 Join 问题目前还没有很好的解决，需要自己编写 Catlet 来处理.
  2. 不支持 Insert into 中不包括字段名的 SQL
  3. insert into x select from y 的 SQL，若 x 与 y 不是相同的分片规则，则不被支持，此时会涉及到跨分片转移
  4. 跨分片的事务，目前只是弱 XA 模式，还没完全实现 XA 模式
  5. 分片的 Table，目前不能执行 Lock Table 这样的语句，因为这种语句会随机发到某个节点，也不会全部分片锁定，经常导致死锁问题，此类问题常常出现在 sqldump 导入导出 SQL 数据的过程中。
  6. 目前 sql 解析器采用 Druid,再某些 sql 例如 order，group，sum ，count 条件下，如果这类操作会出现兼容问题，比如：
     select t.name as name1 from test order by t.name
  7. 这条语句 select 列的别名与 order by 不一致解析器会出现异常，所以在对列加别名时候要注意这类操作异常，特别是由 jpa 等类似的框架生成的语句会有兼容问题。

MySql高可用方案对比

https://blog.csdn.net/slwang001/article/details/71080002
https://blog.csdn.net/u013399093/article/details/70597712
https://www.2cto.com/database/201504/387166.html
MySQL MGR与Galera性能测试
https://blog.csdn.net/chenhaifeng2016/article/details/77530569
高一致分布式数据库Galera Cluster
http://geek.csdn.net/news/detail/159228
注：关于mysql高可用，mycat权威指南高级篇里面也有详细论述

Galera：

优点：
(1).同步复制 Synchronous replication
(2).Active-active multi-master 拓扑逻辑
(3).可对集群中任一节点进行数据读写
(4).自动成员控制，故障节点自动从集群中移除
(5).自动节点加入
(6).真正并行的复制，基于行级
(7).直接客户端连接，原生的 MySQL 接口
(8).每个节点都包含完整的数据副本
(9).多台数据库中数据同步由 wsrep 接口实现

缺点：
(1).目前的复制仅仅支持InnoDB存储引擎,任何写入其他引擎的表，包括mysql.*表将不会复制,但是DDL语句会被复制的,因此创建用户将会被复制,但是insert into mysql.user…将不会被复制的.
(2).DELETE操作不支持没有主键的表,没有主键的表在不同的节点顺序将不同,如果执行SELECT…LIMIT… 将出现不同的结果集.
(3).在多主环境下LOCK/UNLOCK TABLES不支持,以及锁函数GET_LOCK(), RELEASE_LOCK()…
(4).查询日志不能保存在表中。如果开启查询日志，只能保存到文件中。
(5).允许最大的事务大小由wsrep_max_ws_rows和wsrep_max_ws_size定义。任何大型操作将被拒绝。如大型的LOAD DATA操作。
(6).由于集群是乐观的并发控制，事务commit可能在该阶段中止。如果有两个事务向在集群中不同的节点向同一行写入并提交，失败的节点将中止。对 于集群级别的中止，集群返回死锁错误代码(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
(7).XA事务不支持，由于在提交上可能回滚。
(8).整个集群的写入吞吐量是由最弱的节点限制，如果有一个节点变得缓慢，那么整个集群将是缓慢的。为了稳定的高性能要求，所有的节点应使用统一的硬件。
(9).集群节点建议最少3个。
(10).如果DDL语句有问题将破坏集群。

找出每个班级分数最高的3个学生

select * from student s1 left join class c on s1.class_id=c.id 
where ( 
    select count(1) from student s2 where s2.class_id=s1.class_id and s2.score>=s1.score
) <=3;