MySQL 5.5 Community Server MySQL 5.6 Community Server Percona Configuration Wizard XtraBackup 搭建主从复制 Great Sites on MySQL Percona MySQL Performance Blog Severalnines 推荐管理工具 Sequel Pro phpMyAdmin 推荐书目 MySQL Cookbook
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html 
这是一个创建于 816 天前的主题，其中的信息可能已经有所发展或是发生改变。
Debezium 是 Kafka Connect 生态体系下的一个 source connector, 支持实时将 MySQL, PostgreSQL 等数据库的变更事件转化为 Kafka 的消息. 随后, 我们可以通过种类丰富的 sink 将数据导入其他数据源.
本文以 MySQL 为例, 简单介绍 Debezium 在初次创建 connector 时为数据库做快照的策略.
- 获取读锁, 限制表结构的变更
- 读取表结构
- 设置事务隔离级别为 REPEATABLE READ
- 释放读锁, 允许对表的结构和数据进行更新
- 读取所有表的数据
锁
Debezium 优先会选择全局读锁来限制表结构的变更, 对应 SQL FLUSH TABLES WITH READ LOCK. 在无法获取全局读锁的情况下, Debezium 需要为每一张表单独加锁, 对应 SQL FLUSH TABLE {} WITH READ LOCK.
优先使用全局读锁而非表锁的主要原因在于:
- Debezium 通过设置事务隔离级别为 RR 来保证全表数据的一致性, 读取到的都是在事务开始那一刻的快照
- 释放表锁会同时提交当前事务, 所以在读取完全部数据前需要持有锁, 视数据规模, 写禁止会持续几分钟到几十分钟
- 释放全局读锁并不会导致事务被提交, 所以可以在读取完表结构后即释放锁, 写禁止的时间一般小于一秒, 和数据规模无关
扫表
这个操作其实在业务上也会比较常见, 一些人会错误的通过不断更新 OFFSET 来实现扫全表. 在稍有规模的数据集就会发现当 OFFSET 变大时, SQL 执行的很慢. 于是更换成浮标式的分页, 即使用当前查询的主键做为下次查询的限制条件, 规避对 OFFSET 的需求.
Debezium 利用 JDBC 提供的 stream 概念简化了逻辑的同时, 提高了效率. 从使用上看, 通过设置 TYPE_FORWARD_ONLY 和 CONCUR_READ_ONLY, JDBC 会实现类似 lazy load 的效果. 先加载 n 条数据, 当用户需要 n+1th 数据时再加载 n 条数据.
虽然没有去看 JDBC 具体的实现, 但是结合文档中提及的内容, 我们可以猜测:
- JDBC 向 server 原封不动的发送了 sql.
- socket 读取到 n 条数据后, hang 住直到上游需要更多的数据.
 | 1 F281M6Dh8DXpD1g2 2023-07-19 12:48:08 +08:00 jdbc 本来就可以设置 fetch size |
Select Language