《叶问》第1期--知数堂技术小贴士

转自老叶茶馆：https://mp.weixin.qq.com/s/kPFUemQU6foGFNxIkhefsQ

2018年6月10日，周日

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

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

人为原因导致从库与主库数据不一致（从库写入）
主从复制过程中，主库异常宕机
设置了ignore/do/rewrite等replication等规则
binlog非row格式
异步复制本身不保证，半同步存在提交读的问题，增强半同步起来比较完美。但对于异常重启（Replication Crash Safe），从库写数据（GTID）的防范，还需要策略来保证。
从库中断很久，binlog应用不连续，监控并及时修复主从
从库启用了诸如存储过程，从库禁用存储过程等
数据库大小版本/分支版本导致数据不一致？，主从版本统一
备份的时候没有指定参数例如mysqldump --master-data=2 等
主从sql_mode 不一致
一主二从环境，二从的server id一致
MySQL自增列主从不一致
主从信息保存在文件里面，文件本身的刷新是非事务的，导致从库重启后开始执行点大于实际执行点
采用5.6的after_commit方式半同步，主库当机可能会引起主从不一致，要看binlog是否传到了从库
启用增强半同步了（5.7的after_sync方式），但是从库延迟超时自动切换成异步复制

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

master:innodb_flush_log_at_trx_commit=1&sync_binlog=1
slave:master_info_repository="TABLE"&relay_log_info_repository="TABLE"&relay_log_recovery=1
设置从库库为只读模式
可以使用5.7增强半同步避免数据丢失等
binlog row格式
必须引定期的数据校验机制
当使用延迟复制的时候，此时主从数据也是不一致的（计划内），但在切换中，不要把延迟从提升为主库哦~
mha在主从切换的过程中，因主库系统宕机，可能造成主从不一致（mha本身机制导致这个问题）

2018年6月11日，周一

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

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

根据业务类型，和业务容量的评估，来选择和判断是否使用分库分表
当前数据库本事具有的能力，压力的评估
数据库的物理隔离，例如减少锁的争用、资源的消耗和隔离等
热点表较多,并且数据量大，可能会导致锁争抢，性能下降
数据库的高并发，数据库的读写压力过大，可能会导致数据库或系统宕机
数据库（MySQL5.7以下）连接数过高，会增加系统压力
单表数据量大，如SQL使用不当，会导致io随机读写比例高。查询慢（大表上的B+树太大，扫描太慢，甚至可能需要4层B+树）
备份和恢复时间比较长

二、都遇到什么问题?

全局pk（主键和唯一索引）的冲突检测不准确，全局的自增主键支持不够好
分片键的选择。如没有选择好，可能会影响SQL执行效率
分布式事务，中间价产品对分布式事务的支持力度
对于开发来说，需要进行业务的拆分
对于开发来说，部分SQL不兼容则需要代码重构，工作量的评估
对于开发来说，跨库join，跨库查询

三、如何解决?

使用全局分号器。或者使用全局唯一id，（应用生成顺序唯一int类型做为全局主键）
应用层来判断唯一索引
配合应用选择合适的分片键，并加上索引
配合应用，配合开发，对不兼容SQL的进行整改

2018年6月12日，周二

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

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

对业务的了解，需要考虑业务对数据库一致性要求的敏感程度，切换过程中是否有事务会丢失
对于基础设施的了解，需要了解基础设施的高可用的架构。例如单网线，单电源等情况
对于数据库故障时间掌握，业务方最多能容忍时间范围，因为高可用切换导致的应用不可用时间
需要了解主流的高可用的优缺点：例如 MHA/PXC/MGR 等。
考虑多IDC多副本分布，支持IDC级别节点全部掉线后，业务可以切到另一个机房

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

基础层和基础运维部门配合，了解和避免网络/ 硬盘/ 电源等是否会出现单点故障
应用层和应用开发同学配合，在关键业务中记录SQL日志，可以做到即使切换，出现丢事务的情况，也可以通过手工补的方式保证数据一致性，例如：交易型的业务引入状态机，事务状态，应对数据库切换后事务重做
业务层了解自己的应用，根据不同的应用制定合理的高可用策略。
单机多实例环境及基于虚拟机或容器的设计不能分布在同一台物理机上。
最终大招在数据库不可用，可以把已提及的事务先存储到队列或者其他位置，等数据库恢复，重新应用

2018年6月13日，周三

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

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

xtrabackup会，它在备份时会产生短暂的全局读锁FTWL(flush table with read lock)，用于拷贝frm/MYD/MYI等文件，以及记录binlog信息。如果MyISAM表的数据量非常大，则拷贝时间就越长，加锁的时间也越长
mysqldump有可能会。如果只是添加 --single-transacton 选项用于保证备份数据一致性，这时就不会产生FTWL锁了。但通常我们为了让备份文件和binlog保持一致，通常也会设置 --master-data 选项用于获得当前binlog信息，这种情况也会短暂加锁
数据量特别大的话，建议优先用 xtrabackup，提高备份/恢复速度。而如果数据量不是太大或者想备份单表，则建议用mysqldump了，方便逻辑恢复。各有利弊，注意其适用场景

二、xtrabackup冷知识

基于MySQL 5.6版本开发的xtrabackup，会在备份过程中生成内部通信文件 suspend file，用于 xtrabackup 和 innobackupex 的通信，备份结束后文件删除，默认文件位置 /tmp/xtrabackup_suspended
如果在备份过程中，修改了 /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等的生产中，该如何选择？

一、生产环境中：

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

从成熟度上来选择，推荐：异步复制(GTID+ROW)
从数据安全及更高性能上选择：增强半同步（在这个结构下也可以把innodb_flush_log_trx_commit调整到非1，从而获得更好的性能)
对于主从切换控制觉的不好管理，又对数据一致性要求特别高的场景，可以使用MGR

二、理由：

异步复制，相对来讲非常成熟，对于环境运维也比较容易上手
增强半同步复制，可以安全的保证数据传输到从库上，对于单节点的配置上不用要求太严格，特别从库上也可以更宽松一点，而且在一致性和性能有较高的提升，但对运维上有一定的要求
MGR组复制。相对增强半同步复制，MGR更能确保数据的一致性，事务的提交，必须经过组内大多数节点（n/2+1）决议并通过，才能得以提交。MGR架构对运维难度要更高，不过它也更完美

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

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

《叶问》第1期--知数堂技术小贴士相关推荐

知数堂MySQL DBA在线培训第八期招生中
知数堂MySQL DBA在线培训班值得信赖吗 "知数堂培训"是由资深MySQL专家叶金荣.吴炳锡联合推出专业优质在线培训课程,目前主要有MySQL DBA实战优化和Python运维 ...
知数堂全网通缉这个人
嘿,兄弟,我们好久不见,你在哪里? 嘿,朋友,如果真的是你,请打招呼! ...... 如果你热爱学习,如果你对自己有信心如果你已经是或即将是知数堂的一员... 那么,或许我们要找的就是你吴老板老 ...
加入知数堂，成为专业MySQL DBA，就是这么简单！
刚毕业就失业,怎么叩开名企大门? 骑驴找马,硬实力不够? 拿不到好的offer,高薪资永远都是"别人"的屌丝一枚,怎么迎娶白富美? --------[神技能]------- My ...
年终盘点|知数堂2017年度好文
因为加班.约会.加班.约会,错过了知数堂无数次的公开课和技术分享~ 早上还在懊恼遗憾,现在又齐齐整整地回来了~ 而幸福就是,这种失而复得的小确幸这篇文章内涵满满,一年的技术分享都囤这了~ 年关将至, ...
知数堂mysql实战优化，成为专业MySQL DBA
51cto mysql成为风哥一样的数据库大神,全套课程欢迎v私聊,见水印找到我知数堂MYSQL实战13期,业界最靠谱的mysql技术资源,通过这套课程的学习到目前学生平均工资15K+. ...
知数堂郑松华：MySQL 8.0 SQL优化之CTE 、窗口函数的应用
特邀嘉宾郑松华知数堂<SQL优化>课程讲师资深数据库工程师对SQL优化有独到见解 7年SQL开发和调优经验于韩国法院数据中心从事数据库技术支持原SKC&CSheny ...
2021年知数堂公开课首秀
本周知数堂为你准备了两个公开课主题: <MySQL8.0_SQL一些经验>2021#1,<知数堂邀你一起讨论MySQL DBA的成长规划>2021#2 下面分别介绍一下两个主题 ...
毋庸置疑，知数堂确实靠谱
① 讲师靠谱:资深MySQL专家叶金荣.吴炳锡老师亲自授课 ② 时间靠谱:一次交费,可多次听课,必有个属于您的档期 ③ 职业靠谱:互联网急需MySQL.Python人才,前(钱)景大好 ④ 课程靠谱: ...
知数堂培训在线免费分享《DBA神技之SQL Review》
2016.7.28 知数堂培训推出免费在线分享<DBA神技之SQL Review> 1.分享主题 <DBA神技之SQL Review> 2.嘉宾介绍吴炳锡,知数堂培训联合创始 ...

《叶问》第1期--知数堂技术小贴士

《叶问》第1期--知数堂技术小贴士相关推荐

最新文章

热门文章