《叶问》第1期

关 于 叶 问

《叶问》是知数堂新设计的互动栏目，不定期给大家提供技术知识小贴士，形式不限，或提问、或讨论均可，并在当天发布答案，让大家轻轻松松利用碎片时间就可以学到最实用的知识点。

2018年6月10日，周日

MySQL主从复制什么原因会造成不一致，如何预防及解决？

一、导致主从不一致的原因主要有： 

1. 人为原因导致从库与主库数据不一致（从库写入）

2. 主从复制过程中，主库异常宕机

3. 设置了ignore/do/rewrite等replication等规则

4. binlog非row格式

5. 异步复制本身不保证，半同步存在提交读的问题，增强半同步起来比较完美。 但对于异常重启（Replication Crash Safe），从库写数据（GTID）的防范，还需要策略来保证。

6. 从库中断很久，binlog应用不连续，监控并及时修复主从

7. 从库启用了诸如存储过程，从库禁用存储过程等

8. 数据库大小版本/分支版本导致数据不一致？，主从版本统一

9. 备份的时候没有指定参数 例如mysqldump --master-data=2 等

10. 主从sql_mode 不一致

11. 一主二从环境，二从的server id一致

12. MySQL自增列 主从不一致

13. 主从信息保存在文件里面，文件本身的刷新是非事务的，导致从库重启后开始执行点大于实际执行点

14. 采用5.6的after_commit方式半同步，主库当机可能会引起主从不一致，要看binlog是否传到了从库

15. 启用增强半同步了（5.7的after_sync方式），但是从库延迟超时自动切换成异步复制

二、预防和解决的方案有：

1. master:innodb_flush_log_at_trx_commit=1&sync_binlog=1

2. slave:master_info_repository="TABLE"&relay_log_info_repository="TABLE"&relay_log_recovery=1

3. 设置从库库为只读模式

4. 可以使用5.7增强半同步避免数据丢失等

5. binlog row格式

6. 必须引定期的数据校验机制

7. 当使用延迟复制的时候，此时主从数据也是不一致的（计划内），但在切换中，不要把延迟从提升为主库哦~

8. mha在主从切换的过程中，因主库系统宕机，可能造成主从不一致（mha本身机制导致这个问题）

2018年6月11日，周一

你为什么会决定进行分库分表，分库分表过程中遇到什么难题，如何解决的？

一、为什么决定进行分库分表？

1. 根据业务类型，和业务容量的评估，来选择和判断是否使用分库分表

2. 当前数据库本事具有的能力，压力的评估

3. 数据库的物理隔离，例如减少锁的争用、资源的消耗和隔离等

4. 热点表较多,并且数据量大，可能会导致锁争抢，性能下降

5. 数据库的高并发，数据库的读写压力过大，可能会导致数据库或系统宕机

6. 数据库（MySQL5.7以下）连接数过高，会增加系统压力

7. 单表数据量大，如SQL使用不当，会导致io随机读写比例高。查询慢（大表上的B+树太大，扫描太慢，甚至可能需要4层B+树）

8. 备份和恢复时间比较长

二、都遇到什么问题?

1. 全局pk（主键和唯一索引）的冲突检测不准确，全局的自增主键支持不够好

2. 分片键的选择。如没有选择好，可能会影响SQL执行效率

3. 分布式事务，中间价产品对分布式事务的支持力度

4. 对于开发来说，需要进行业务的拆分

5. 对于开发来说，部分SQL不兼容则需要代码重构，工作量的评估

6. 对于开发来说，跨库join，跨库查询

三、如何解决?

1. 使用全局分号器。或者使用全局唯一id，（应用生成顺序唯一int类型做为全局主键）

2. 应用层来判断唯一索引

3. 配合应用选择合适的分片键，并加上索引

4. 配合应用，配合开发，对不兼容SQL的进行整改

2018年6月12日，周二

MySQL高可用架构应该考虑什么? 你认为应该如何设计？

一、MySQL高可用架构应该考虑什么？

1. 对业务的了解，需要考虑业务对数据库一致性要求的敏感程度，切换过程中是否有事务会丢失

2. 对于基础设施的了解，需要了解基础设施的高可用的架构。例如 单网线，单电源等情况 

3. 对于数据库故障时间掌握，业务方最多能容忍时间范围，因为高可用切换导致的应用不可用时间

4. 需要了解主流的高可用的优缺点：例如 MHA/PXC/MGR 等。

5. 考虑多IDC多副本分布，支持IDC级别节点全部掉线后，业务可以切到另一个机房

二、你认为应该如何设计? 

1. 基础层 和基础运维部门配合，了解和避免网络/ 硬盘/ 电源等是否会出现单点故障 

2. 应用层 和应用开发同学配合，在关键业务中记录SQL日志，可以做到即使切换，出现丢事务的情况，也可以通过手工补的方式保证数据一致性，例如：交易型的业务引入状态机，事务状态，应对数据库切换后事务重做 

3. 业务层 了解自己的应用，根据不同的应用制定合理的高可用策略。 

4. 单机多实例 环境及基于虚拟机或容器的设计不能分布在同一台物理机上。 

5. 最终大招 在数据库不可用 ，可以把已提及的事务先存储到队列或者其他位置，等数据库恢复，重新应用

2018年6月13日，周三

MySQL备份，使用xtrabackup备份全实例数据时，会造成锁等待吗？那么如果使用mysqldump进行备份呢？

一、xtrabackup和mysqldump会造成锁等待吗？ 

1. xtrabackup会，它在备份时会产生短暂的全局读锁FTWL(flush table with read lock)，用于拷贝frm/MYD/MYI等文件，以及记录binlog信息。如果MyISAM表的数据量非常大，则拷贝时间就越长，加锁的时间也越长

2. mysqldump有可能会。如果只是添加 --single-transacton 选项用于保证备份数据一致性，这时就不会产生FTWL锁了。但通常我们为了让备份文件和binlog保持一致，通常也会设置 --master-data 选项用于获得当前binlog信息，这种情况也会短暂加锁

3. 数据量特别大的话，建议优先用 xtrabackup，提高备份/恢复速度。而如果数据量不是太大或者想备份单表，则建议用mysqldump了，方便逻辑恢复。各有利弊，注意其适用场景

二、xtrabackup冷知识

1. 基于MySQL 5.6版本开发的xtrabackup，会在备份过程中生成内部通信文件 suspend file，用于 xtrabackup 和 innobackupex 的通信，备份结束后文件删除，默认文件位置 /tmp/xtrabackup_suspended 

2. 如果在备份过程中，修改了 /tmp 的访问权限或该文件的权限，则两个程序间直接不能通信，会造成 xtrabackup hang 住，正在备份的表不能正常释放锁，会造成锁等待，此时需要强制 kill 掉 xtrabackup 进程

2018年6月15日，周五

MySQL 5.7开始支持JSON，那还有必要使用MongoDB存JSON吗？请列出你的观点/理由。

一、观点A：支持MySQL存储JSON

1.MongoDB不支持事务，而MySQL支持事务

2.MySQL相对MongoDB而言，MySQL的稳定性要优于MongoDB

3.MySQL支持多种存储引擎

二、观点B:支持MongoDB存储JSON 

1.从性能的角度考虑，对于JSON读写效率MongoDB要优于MySQL

2.MongoDB相对MySQL而言，MongoDB的扩展性要优于MySQL

3.MongoDB支持更多的JSON函数

三、总结

1.如果应用程序无事务要求，存储数据表结构复杂并且经常被修改， 例如游戏中装备等场景用MongoDB比较适合

2.如果应用程序有事务要求，存储数据的"表"之间相互有关联，例如有订单系统等场景用MySQL比较适合

3.整体来看相对看好MySQL的JSON功能，在未来官方的努力下MySQL的JSON功能有机会反超MongoDB

2018年6月17日，周日当数据被误删除/误操作后造成数据丢失。你尝试过用什么手段来挽救数据/损失？

一、前提 
1.当数据被误删除/误操作后，第一时间要关闭数据库。业务方需要紧急挂停机公告，避免数据二次污染，用于保护数据的一致性

2.BINLOG格式为ROW格式，不讨论其他格式的BINLOG

二、数据被误操作(update/delete/drop)造成数据丢失，可以用哪些手段来恢复？ 

1.BINLOG恢复：可以使用逆向解析BINLOG工具来恢复。例如：binlog2SQL等

2.延迟从库: 可以通过解除延迟从库，并指定BINLOG结束位置点，可以实现数据恢复

三、数据被误删除(rm/物理文件损坏)造成数据丢失，可以用哪些手段来恢复？ 

1.如果有备份，可以通过备份恢复 mysqldump/xtrabackup + binlog 来实现全量+增量恢复

2.如果无备份但是有从库，可以通过主从切换，提升从库为主库，从而实现数据恢复

3.如果无备份并且无从库，但MySQL没有重启，可以通过拷贝/proc/$pid/fd中的文件，来进行尝试恢复

4.如果无备份并且无从库，但MySQL有重启，可以通过extundelete或undrop-for-innodb来恢复

2018年6月19日，周二MySQL 5.7的复制架构,在有异步复制、半同步、增强半同步、MGR等的生产中，该如何选择？

一、生产环境中： 

几种复制场景都有存在的价值。下面分别描述一下： 

1. 从成熟度上来选择，推荐：异步复制(GTID+ROW)

2. 从数据安全及更高性能上选择：增强半同步 （在这个结构下也可以把innodb_flush_log_trx_commit调整到非1， 从而获得更好的性能)

3. 对于主从切换控制觉的不好管理，又对数据一致性要求特别高的场景，可以使用MGR

二、理由：

1. 异步复制，相对来讲非常成熟，对于环境运维也比较容易上手 

2. 增强半同步复制，可以安全的保证数据传输到从库上，对于单节点的配置上不用要求太严格，特别从库上也可以更宽松一点，而且在一致性和性能有较高的提升，但对运维上有一定的要求

3. MGR组复制。相对增强半同步复制，MGR更能确保数据的一致性，事务的提交，必须经过组内大多数节点（n/2+1）决议并通过，才能得以提交。MGR架构对运维难度要更高，不过它也更完美

总的来讲，从技术实现上来看：MGR> 增强半同步>异步复制。

未来可能见到更多的MGR在生产中使用，对于MySQL的运维的要求也会更上一层楼。