?MySQL BINLOG 是 MySQL 记录数据修改操作的二进制文件，数据库开启 BINLOG后 ，第三方组件（如 Canal，Flink-CDC）可以从数据库的 BINLOG 中增量获取数据的修改记录，实现数据的增量订阅。
数据库使用 CASB 方式配置加密后，明文数据经过代理后加密成密文，密文数据直接写入数据库，与此同时，BINLOG 存储密文到日志。因此，使用 BINLOG 直接订阅数据库时，同步订阅到的数据为密文。
CASB BINLOG 解密
CASB 支持根据当前配置的加密策略解密 BINLOG 日志数据，第三方组件可将订阅源由数据库变更 CASB 代理，由 CASB 代理解密 BINLOG 中的密文数据。
支持的订阅协议：
COM_BINLOG_DUMP
COM_BINLOG_DUMP_GTID
支持的事件类型：
WRITE_ROWS_EVENTv1
UPDATE_ROWS_EVENTv1
DELETE_ROWS_EVENTv1
WRITE_ROWS_EVENTv2
UPDATE_ROWS_EVENTv2
DELETE_ROWS_EVENTv2
WRITE_ROWS_COMPRESSED_EVENT_V1
UPDATE_ROWS_COMPRESSED_EVENT_V1
DELETE_ROWS_COMPRESSED_EVENT_V1
支持的压缩算法类型
zlib
使用限制
访问代理的代理账号必须为
casb_binlogdump，代理账号绑定的元数据账号必须有获取数据库 BINLOG 权限。binlog_format格式必须为ROW 。访问代理的连接字符集必须为
utf8或utf8mb4。仅支持根据当前配置的加密策略解密数据。
不支持对 BINLOG 数据使用脱敏和访问控制策略。
常见问题
1. 两个数据库间已配置主从关系并使用 BINLOG 同步数据，主数据库接入 CASB 后，从数据库使用 BINLOG 协议连接 CASB，同步明文数据异常。
BINLOG 数据经过 CASB 代理解密后，明文相较于密文变短，导致 MySQL 从库的 Read_Master_log_Pos 和 Exec_Master_Log_Pos 不一致，导致同步失败。从库数据的解密请使用CASB 主从同步功能。
2. 加密策略修改或删除后，存量的 BINLOG 数据无法解密。
仅支持根据当前配置的加密策略解密数据，历史已加密的 BINLOG 数据根据当前策略无法解密时，将保留密文。
3. 表结构变更，变更前的存量 BINLOG 数据无法解密。
表结构变更后，CASB 的表结构和 BINLOG 历史数据的表结构不一致。若数据库参数
binlog_row_metadata未设置为 FULL，BINLOG 事件仅记录各字段数据，不记录各字段名，CASB 无法识别 BINLOG中 数据对应的加解密策略信息，导致无法解密历史数据。4. 表结构变更，变更后的增量 BINLOG 数据无法解密。
直连数据库变更表结构后，若未及时在 CASB 同步表结构，CASB 的表结构仍为旧值，和 BINLOG 增量数据的结构不一致。若数据库参数
binlog_row_metadata未设置为 FULL，BINLOG 事件仅记录各字段数据，不记录各字段名，CASB 无法识别 BINLOG 中数据对应的加解密策略信息，导致无法解密新增的数据。表结构变更最佳实践
为了解决表结构变更导致的 BINLOG 数据无法解密的问题，可采用以下两种方案。
配置数据库参数（推荐）
配置数据库参数
binlog_row_metadata为 FULL，将字段信息记录到 BINLOG 中，CASB 会根据字段信息解析和应用字段的加解密策略。使用此方案时，需数据库支持此参数，且会造成 BINLOG 占用空间变大。
业务侧手动变更
业务侧需支持 BINLOG 数据处理的幂等性，即支持从某个位置重新处理所有 BINLOG 数据。
记录表结构变更前的最后 BINLOG 位置信息。
变更和同步表结构。
通过代理变更表结构（自动触发 CASB 表结构采集任务）。
直连 DB 变更表结构后，手动在 CASB 控制台更新表结构。
配置同步工具，从变更前的最后 BINLOG 位置重新同步。
?
?
