数据库使用 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 位置重新同步。