mr_zhangwz的博客

报错信息：@@SESSION.GTID_NEXT cannot be set to ANONYMOUS when @@GLOBAL.GTID_MODE = ON。

调整myisam引擎参数。# 导入完毕后进行恢复。# 关闭binlog。

MySQL :: MySQL 5.7 Reference Manual :: 8.12.4.1 How MySQL Uses Memory

MySQL的同步机制比较单纯，主库上执行过的 DML 和 DDL 会在从库上再执行一次，那么主库上需要 10min 才能执行完的 DDL 理论上在从库至少也要花费 10min 才能执行完，这意味着从库的同步会延迟 10min 以上，等 DDL 执行完之后才会继续追同步。本文会介绍 gh-ost，由 Github 维护的 MySQL online DDL 工具，同样使用了镜像表的形式，但是放弃了使用低效的 trigger，而是从 binlog 中提取需要的增量数据来保持镜像表与源表的数据一致性。

根据以上缺点,我们并不推荐在列中设置 NULL 作为列的默认值,你可以使用NOT NULL消除默认设置,使用0或者''空字符串来代替NULL。有的时候为了消除NULL带来的技术债务,我们需要在 SQL 中使用IFNULL()来确保结果可控,但是这使程序变得复杂.NULL值并是占用原有的字段空间存储,而是额外申请一个字节去标注,这个字段添加了NULL约束.(就像额外的标志位一样)对含有 NULL 值的列进行统计计算,eg. count(),max(),min(),结果并不符合我们的期望值.

表竖向拆分是因为单行的总宽度太大或列数比较多，可以将大字段列、不常用的列，拆分到该表的扩展表中，拆分后可减少IO和避免内存中热数据被换出。表横向拆分常见方法有：按数据类别、日期（如日表、月表、年表）、地域、用户id取余等。分库，常见的是按业务功能分库、分实例，又可以按数据的冷热，分出在线库和历史库。表横向拆分是因为单表行数太多，可把单表拆分成多张小表。分库分表后，可通过冗余关联列减少跨库查询。分表分为竖向拆分和横向拆分。

WHERE table_schema = '改成自己的数据库名字'WHERE table_schema = '改成自己的数据库名字'

从故障的反复确认，到binlog/relay日志的层层比对，多重差异日志的应用，到最后复制位置的准确选择做得每一步都是十分仔细，如果中途有意外发生会终止failover操作，并产生mha_manager.failover.error的文件，下一次必须要删除该文件才能正常failover，再或是当从库的差异日志太大落后太多（100M），默认情况会终止failover随后报错退出，除非设置check_repl_relay=0，因为它要保证快速切换，downtime不能过长。只需安装node包。

当 relay_log_purge=0 时，旧的 relay log 则会被保留。虽然这并不会影响从库复制本身，但还是会有坑：由于崩溃或停止 MySQL 时，SQL 线程可能没有执行完全部的 relay log，最后一个 relay log 中的一部分数据会被重新下载到新的文件中。但是对于MHA场景下，对于某些滞后从库的恢复依赖于其他从库的relay log，因此采取禁用自动删除功能以及定期清理的办法,从而避免对于清理过多过大的relay log需要注意引起的复制延迟资源开销等。

从2011年开始，我就一直在写博客，只不过之前是在网易博客上，前前后后写了1500篇以上，后来网易博客关闭了，想过要把博客搬到其他站点，奈何文档数量太大了，其他博客也不提供博客搬家功能，所以就一直拖到了现在。当初在网易开博客时，也考察过CSDN博客，但CSDN上有广告的原因，所以当时选择了网易博客。当初选博客时，如果能预料到之后它会关闭，肯定不会选择它。人生就是这般无常，兜兜转转又来到了CSDN。