《叶问》第1期

  1. 云栖社区>
  2. 博客>
  3. 正文

《叶问》第1期

tplinux 2018-11-29 13:50:39 浏览592
展开阅读全文

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的运维的要求也会更上一层楼。

网友评论

登录后评论
0/500
评论
tplinux
+ 关注