北京旅游型网站建设成都seo培
虚谷Binlog介绍
Binlog（binary log，二进制日志）是数据库维护的一组日志文件，用来记录对数据进行修改的信息。在虚谷数据库中也叫modify log，是记录数据库表结构，数据变更的二进制文件，变更记载功能可用于实时归档事务内的任何DDL/DML操作（例如create table , alter table , insert into , update , delete 操作），保障了用户对数据库操作的可溯源性。
binlog常见的应用场景：
- 数据同步：同步工具使用订阅者消费日志记载，生成语句同步给备库
- 数据恢复：误删数据后通过工具进行日志解析，恢复数据
Binlog开启
开启变更日志记载之前需要确认，在集群的GATHER节点执行，单机自带GATHER属性
数据库自带DBMS_REPLICATION.CREATE_MODIFY_SOURCE系统函数，在服务端定义binlog可以以库，模式，表为单位进行管理记载。
binlog 日志的开启与关闭需要SYSDBA进入指定库来操作。
库：exec dbms_replication.create_modify_source('*','*');
模式：exec dbms_replication.create_modify_source('sch_name','*');
表：exec dbms_replication.create_modify_source(' sch_name ',' tab_name ');
系统视图dba_modify_logs
注意：开启后，如果没有相应的数据变更，系统不会生成相应的binlog文件，执行变更后才会记载SQL语句，相应的系统表（dba_databases,dba_schemas,dba_tables）的列reg_modify应为true 。
Binlog文件
开启变更日志后，目录在XHOME/XMODI下记载，一个目录代表一个数据库，DB00000001就是DB_ID=1中创建的变更。
每个数据库目录中就是binlog二进制文件和MATE元数据目录，内容为本库级别下的库级，模式级，表级的变更记载，数据库中可以开启多个变更记载。
Binlog参数
用例
modify_log_parti_num = 8; 变更日志并行写通道数
modify_log_pice_len = 10; 变更日志文件分片大小(单位:M)
ignore_when_meta_err = 2; 变更日志元信息错误处理模式(0:抛错 1:返回NULL 2:不返回)
max_allow_lob_len = 10; 允许记载的最大大对象大小(单位:M)
Binlog记载格式
Binlog记载DDL语句（create drop alter）记录SQL语句
Binlog记载DML语句（insert delete update）记录每行的实际数据，优点，准确性强，能准确复制数据的变更，缺点，记载的文件较大，较大的网络磁盘IO，但现在有SSD，Nvme和万兆网络，都是可以接受的。
Binlog消费
想要获取Binlog中的SQL语句，解析Binlog信息，需要先创建订阅者DBMS_REPLICATION.CREATE_SUBSCRIBER系统函数创建，创建好的订阅者可以在sys_subscribers试图查到。再通过DBMS_REPLICATION.POLL_MODIFY_DATA结合查看解析Binlog中的DDL/DML操作，看到的就是SQL语句。
订阅者由系统管理员 SYSDBA 来管理，因此，订阅者的创建与删除都需要由 SYSDBA 来操作。
创建：exec dbms_replication.create_subscriber('s_test',' SYSDBA');
变更日志解析使用的DBMS_REPLICATION.POLL_MODIFY_DATA函数，需要清楚从哪个起始位置开始？binlog的8个分区中的哪个，8个区的file文件中的哪个，目录中的file_no为16进制转为10进制。扫描多少数据量？可以超过指定超过一个file_no大小。是否添加过滤条件？设置只查某些object的变更记载。KEEP_POS表示是否把当前订阅者消费binlog最后读取位置持久化到dba_streams中，在下次消费的时候可以使用FNO=-1自动从最后位置继续读取，继续持久化到dba_streams，保证下次消费的是binlog的新数据。
示例:
exce DBMS_REPLICATION.POLL_MODIFY_DATA('s_test',0,'obj_id=1048577',10*1024*1024,true,0,0);
exec DBMS_REPLICATION.POLL_MODIFY_DATA('s_test',0,null,10*1024*1024,true,-1,0);
| 参数名称 | 参数类型 | 参数解释 | 默认值 |
| SUBSCRIBER_NAME | VARCHAR | 订阅名 | 无 |
| PARTI_NO | INTEGER | 分区号 | 无 |
| FILTER | VARCHAR | 过滤条件（obj_id） | 无 |
| POLL_LEN | BIGINT | 本次查询需要扫描的日志文件长度（字节） | 无 |
| KEEP_POS | BOOLEAN | 是否移动当前分区的备份数据读取位置到本次读取结束位置 | 无 |
| FNO | INTEGER | 本次查询开始的文件号 | -1 |
| FPOS | BIGINT | 本次查询的开始文件内偏移量 | 0 |
select * from dba_streams where SUBS_ID = 1048577;
同步工具是读取dba_streams表的8个分区的binlog位置开始解析，解析并持久化数据读取位置到本次读取结束位置。
常见问题
1. 同步操作是按照binlog文件号顺序处理，同步已进行到最新数据，发现之前还有数据未同步，导致主备数据不一致情况。这时查询binlog中是否有数据记载，有就可以定位数据所在的文件号和起始位置，再持久化到dba_streams中，继续启动同步工具处理未同步数据。
2. 在集群存在G节点在给kafka同步数据的同时。创建订阅者后开启同步，订阅者读取会从file_no=0开始，将binlog中的变更记载再加载一遍，难免会有报错，新建订阅者的分片读取位置没有持久化到dba_streams中，需要将binlog读取位置向后推移持久化，加载最新的binlog。