|
这是针对公司内部的一个分享，主题是去年10月份就想好的，中间因为一些项目，也包括自己的拖延症，ppt一直没准备好。 我们有不少项目依赖于binlog同步数据，所以对binlog的格式以及内部结构进行了简单介绍 主要是两阶段提交的一些概念和原理，与下面的组提交原理一起，方便后面对崩溃恢复机制的理解 种类包括异步复制、半同步复制、增强半同步复制和并行复制，顺便结束了复制延迟常见的原因 基于上面的原理，介绍主库、从库分别在异常宕机的情况下，如何保证数据一致的 这部分由于时间的关系，没有准备，并且本身也是一个很大课题，所以干脆就去掉了 关于数据库分页查询的话题，网上谈论的很多，但开发人员在使用上还是习惯以往的思路。 MySQL的 limit m,n 工作原理就是先读取符合where条件的前面m+n条记录，然后抛弃前m条，返回后面n条，所以m越大，偏移量越大，性能就越差。这也是大部分ORM框架生成的分页sql。
这个参数原本是解决像 NDB Cluster 多节点写入冲突的情况，也可以在普通主从、双主、环形复制等情况下解决冲突，保持幂等性。幂等性怎么定义，感兴趣的可以阅读The differences between IDEMPOTENT and AUTO-REPAIR mode）。 这个参数不能在线修改，只能加到配置文件里面或者启动的时候带上--slave-skip-errors=1032,1062。除非你真的理解它skip掉了什么，否则不建议使用。 讲一个我所遇到的坑。在我们的一个分库项目中，需要把一个database里面的数据拆成32份，于是做了个主从，把从库里面不需要的那份删除，但复制过来肯定会报 HA_ERR_KEY_NOT_FOUND 错误，于是这也是所期望的，就设置了--slave-skip-errors=1032。 但接下来就出现 1062:HA_ERR_FOUND_DUPP_KEY 错误！从库只会删数据，不会写入和更新，怎么会出现重复数据？读者不妨试想一下为什么。 MySQL Binlog 里面记录了每行数据的变更，开发有时候需要根据这些变更的时间、中间值去查问题，是bug导致的，还是用户操作引发的。然而原始binlog内容不利于检索，有段时间使用阿里RDS企业版DMS数据追踪的功能，也能完成这个工作，甚至生成回滚sql，后由于收费以及容量不够的缘故，放弃不用。 本文所介绍的就是基于外面开源的各类组件，整合起来，达到类似数据追踪的功能 —— binlog 可视化。 使用容器来实现资源的申请和释放，毕竟这类检索binlog内容的需求不多。 代替ELK技术栈的日志收集、处理、展示平台。社区版够用，需要自行安装，也可以把 graylog 换成 ELK stack。 nxlog 是用 C 语言写的一个开源日志收集处理软件，它是一个模块化、多线程、高性能的日志管理解决方案，支持多平台。
在【编排模板】里选择maxwell-graylog-rabbitmq，【创建应用】下一步修改编排模板： 需要分析 binlog 大致位于哪个时间段。请尽可能的精确，如果时间范围过大，可能耗时非常久。3个binlog入完graylog大约6分钟。不能保持示例默认的值 比如在数据库迁库时，将当天表的数据同步到新库，模拟阿里云dms数据传输的功能，相当于在测试环境演练，减少失误。 另外还可以从新库反向同步增量数据到老库，解决测试环境多项目测试引起数据库冲突的问题。 比如数据库迁移项目，切换期间数据写向新库，但如果切换失败需要回滚到老库，就需要把这段时间新增的数据同步回老库（启动消费程序），这就不需要程序段再考虑复杂的回滚设计。 |
