企业官网建设流程全解析

简介：一份面向Oracle DBA及数据同步实施人员的OGG部署实战文档，聚焦如何利用Oracle GoldenGate 12.2.0.2将Windows上的Oracle数据库实时同步至Linux环境。资源定位明确：适合正在规划跨平台数据迁移、灾备同步或需要快速掌握OGG核心配置的运维和数据库工程师。文档完整覆盖源库与目标库的前置准备，详细说明开启归档模式、强制日志、附加日志，创建goldengate用户并授权，以及enable_goldengate_replication参数设置；同时给出目标库额外授权、checkpoint表与全局参数文件配置等关键细节。接着讲解OGG子目录初始化、Manager端口与参数、Extractor、Replicat等核心组件配置，并补充监控日志、常见故障排查等维护要点。具体SQL、GGSCI命令和安装步骤均以清晰的命令片段呈现，方便读者直接对照操作。文档共1个PDF文件，压缩包大小496KB，内容紧凑、步骤完整。资源发布以来已有295人学习，可用于OGG快速落地、跨平台同步实施及后续问题定位。

1. Oracle OGG安装部署细说：Windows同步到Linux

接到过这样一个需求：客户有一套老业务库跑在Windows Server上，Oracle 11g，硬件要退役，新机器是Linux，业务不能长时间停。数据库同步软件翻了一圈，最后还是用Oracle GoldenGate（OGG）做实时同步——源端Windows抓日志，目标端Linux投递，停机窗口压到分钟级。这篇文章就是把这个过程完整拆开：OGG的同步机制怎么理解、Windows源端怎么装、Linux目标端怎么配置、初始化数据怎么做，以及我实际部署中踩过的一堆坑。适合正在做Oracle跨平台迁移、灾备、读写分离或数据中心汇聚的DBA和运维工程师。你要的是一套能照抄的落地路径，不是概念科普。

2. 同步机制与部署选型：先搞懂Capture、Transport和Replicat再动手

OGG不是触发器、不是物化视图、更不是定期导数据，它从Oracle的redo/archive log里解析变化，再以自定义的trail文件格式投递到目标库，整个过程对源库业务几乎无侵入。很多人第一次部署时一头扎进命令里，结果进程起来又abend，反复摸不着头脑。我建议先花半小时把链路模型理清楚，后面配参数全是顺水推舟的事。

2.1 OGG同步链路：三个进程加一个中转文件

OGG一条完整的同步链路，在标准配置下由三部分构成：源端主抽取进程（Extract）、源端数据泵进程（Data Pump）、目标端复制进程（Replicat），中间靠trail文件接力。

主抽取进程直接连源库，读取redo/archive log，把变化解析成OGG内部格式写到源端的本地trail文件。数据泵进程读本地trail，通过TCP/IP传给目标端Manager进程拉起的Collector接收器，落地成目标端的远程trail文件。Replicat进程读远程trail，把事务在目标库回放。

这套设计的核心价值在于两级trail形成了天然的缓冲和解耦：源端主抽取不受网络抖动影响，数据泵失败不会污染主抽取；目标端Replicat进度落后也不会反压源端。生产环境我从不省掉数据泵这一跳，哪怕源和目标都是同一台机器，也按标准链路搭。原因很简单——一旦源端主抽取直接跨公网传，网络闪断会直接拖垮日志抓取进度，恢复起来极其痛苦。

每个进程都有独立的checkpoint机制。Extract的checkpoint记录读日志的位置，Replicat的checkpoint记录已提交到目标库的事务位置。正因为有checkpoint，进程重启后能精确续传，不会丢事务也不会重复应用。这也是OGG敢叫“实时同步”的底气。

2.2 为什么Windows源到Linux目标要单独规划字符集和时区

同构平台（Linux到Linux）的OGG部署相对省心，一旦跨Windows和Linux，几个隐藏差异就会冒出来。

先看字符集。源库字符集可能是ZHS16GBK，目标库可能是AL32UTF8。OGG传输trail文件时按字节搬运，不做转码，到了目标端由Replicat负责按目标库字符集解释。如果两边NLS_LANG设置不一致，中文同步过去就变成问号或乱码。部署前必须确认三处字符集对齐：源端数据库字符集、源端OGG进程的NLS_LANG、目标端Replicat进程的NLS_LANG。我在后面第4章会给出具体配置方法。

再看时区。Oracle的DATE类型不带时区，OGG解析日志时按源端会话时区写入trail。如果源端Windows是东八区，目标端Linux也设了东八区，问题不大；但很多Linux服务器习惯设成UTC，结果就是目标库数据比源库慢8小时。这不是同步丢数据，是时区解释不一致。解决方案是源端和目标端的数据库、操作系统、OGG进程统一用同一个时区基准，并在Replicat参数里显式声明时区相关列的处理方式。

还有两个容易被忽略的点：路径风格完全不同，GGSCI里所有目录参数注意别把Windows的C:\OGG\...习惯带到目标端；trail文件是二进制跨平台格式，OGG从12c开始统一了跨平台trail格式，低版本（11g之前）Windows和Linux的trail文件不能互读，所以版本选型尤为重要。

2.3 版本选型与部署形态：先对参数再动手

OGG版本必须跟Oracle数据库版本匹配。Oracle 11g配OGG 11.x/12.1，Oracle 12c配OGG 12.2/18c，Oracle 19c配OGG 19.x。跨大版本用新OGG连老库一般可以，反过来老OGG连新库基本不行。我的原则是：源库和目标库都看，选两者都支持的最高OGG版本，并且同一链路两端用完全相同的OGG版本号，避免小版本行为差异。

部署形态上，源端Windows安装包和目标端Linux安装包是分开的，下载时要分别选对应操作系统版本。Windows端建议安装在纯英文路径下，比如C:\OGG，不要带空格和中文；Linux端一般装在oracle用户的/u01/ogg之类的位置，属主设为oracle:oinstall，权限750就行。

网络规划方面，OGG默认Manager监听端口我用7809，再加一组动态端口给Collector接收数据。源端防火墙要放行目标端到源端这些端口的TCP入站规则，很多部署失败根本不是配置问题，是防火墙把Collector的握手包丢了。整个过程可以先在两端各启动Manager，用telnet验证端口连通，再进行后续配置。

3. Windows源端部署：MGR、抽取进程与trail文件的三个核心配置

源端是所有同步数据的发源地，一旦这边配置错，目标端再折腾也是白费。我的落地顺序是：先做数据库层准备，再装OGG软件，然后依次配置Manager、主抽取进程和数据泵进程。每一步验证通过再做下一步，绝不跳步。

3.1 数据库准备：补充日志和归档模式检查

OGG抓取日志的前提是源库开启了归档模式（ARCHIVELOG），并且开了补充日志（Supplemental Logging）。很多同步数据丢失的案例，根源都在这步没做扎实。

-- 检查源库关键日志属性 SELECT log_mode, supplemental_log_data_min, force_logging FROM v$database; -- 开启最小补充日志（如果未开启） ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; -- 开启强制日志，避免NOLOGGING操作导致日志缺失 ALTER DATABASE FORCE LOGGING;

逻辑说明：log_mode必须是ARCHIVELOG；supplemental_log_data_min为YES才表示OGG能识别主键列的变化；force_logging为YES能确保直接路径加载等NOLOGGING操作也写入日志。第1条查询语句用来确认现状，第2、3条是开启命令，执行后最好再查一次确认。

参数说明：只开最小补充日志时，OGG能同步DML；如果要同步主键更新或被更新列的旧值，还要加上ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS。显卡的update操作默认不会带出旧值，后面Replicat映射会拿不到更新前内容，这是一个高频坑，建议部署时直接加上。另外，开启补充日志会让redo量增加约5%~15%，对写密集系统要提前评估磁盘空间。

3.2 安装OGG源端并配置Manager进程

OGG的Windows版安装包，解压或安装完成后，目录结构是固定的。关键子目录有dirprm（参数文件）、dirrpt（报告与异常日志）、dirtrail（trail文件）、dirdef（定义文件）、dirchk（checkpoint文件）。这些目录在第一次用GGSCI命令启动时会自动创建，不用手工建。

环境变量方面，确保系统PATH里能找到OGG安装目录，并设置NLS_LANG与源库字符集一致。比如源库是ZHS16GBK，就设NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK。这一步漏了，后续所有中文数据同步出去就会变成乱码。

打开命令行，进入OGG目录，启动GGSCI：

ggsci GGSCI> CREATE SUBDIRS

CREATE SUBDIRS会自动创建OGG标准目录结构。然后编辑Manager参数：

GGSCI> EDIT PARAMS MGR

写入以下内容：

PORT 7809 DYNAMICPORT 7810-7820 AUTOSTART EXTRACT * AUTORESTART EXTRACT *, RETRIES 3, WAITMINUTES 5 PURGEOLDEXTRACTS ./dirtrail/*, USECHECKPOINTS, MINKEEPHOURS 24

逻辑说明：PORT 7809是Manager监听端口；DYNAMICPORT 7810-7820是Data Pump向目标端传输时使用的动态端口范围；AUTOSTART和AUTORESTART让抽取进程随Manager自动拉起并在异常退出后自动重启；PURGEOLDEXTRACTS防止trail文件无限堆积。参数配置完，启动Manager：

GGSCI> START MGR GGSCI> INFO MGR

3.3 抽取进程与数据泵的参数落地

主抽取进程负责抓日志，数据泵负责传数据。生产环境我把它们拆成两个进程，这样主抽取的checkpoint不受网络影响。

先建立主抽取进程：

GGSCI> EDIT PARAMS EXTORA

EXTRACT EXTORA USERID ogg@pdb1, PASSWORD ogg TRANLOGOPTIONS EXCLUDEUSER ogg EXTRAIL ./dirtrail/lt TABLE ogg.T_ORDER; TABLE ogg.T_USER;

逻辑说明：EXTRACT EXTORA声明进程名，必须与EDIT PARAMS的文件名一致；USERID指定OGG连接源库的数据库账号，提前在源库创建好，并授予DBA或SELECT ANY TRANSACTION等最小权限；TRANLOGOPTIONS EXCLUDEUSER ogg让OGG不去抽取自己的同步数据，防止循环陷阱；EXTRAIL定义本地trail文件路径；TABLE定义要同步的表，可以用TABLE ogg.*;匹配全部表。

注意，Windows系统里trail文件路径用./dirtrail/lt相对路径最稳妥，绝对路径要注意反斜杠转义。trail文件名是两字符前缀，OGG会自动补6位序列号。

然后在GGSCI中注册主抽取进程：

GGSCI> ADD EXTRACT EXTORA, TRANLOG, BEGIN NOW GGSCI> ADD EXTTRAIL ./dirtrail/lt, EXTRACT EXTORA

参数说明：TRANLOG表示从日志抓取，BEGIN NOW表示从当前时间点开始记录。ADD EXTTRAIL把trail文件和抽取进程绑定。这样主抽取进程每抓一段日志，就把数据写入lt开头的trail文件。

数据泵进程配置：

GGSCI> EDIT PARAMS PUMP

EXTRACT PUMP USERID ogg@pdb1, PASSWORD ogg RMTHOST 192.168.1.100, PORT 7809 RMTTRAIL /u01/ogg/dirtrail/rt TABLE ogg.T_ORDER; TABLE ogg.T_USER;

逻辑说明：RMTHOST指定目标端Linux机器的IP和Manager端口；RMTTRAIL是落地到目标端的trail文件路径，这里必须写Linux路径格式；TABLE列表与主抽取进程保持一致。注意源端主抽取和目标端Replicat都只需配TABLE，中间的数据泵只搬运不选型。

注册并启动：

GGSCI> ADD EXTRACT PUMP, EXTTRAILSOURCE ./dirtrail/lt GGSCI> ADD RMTTRAIL /u01/ogg/dirtrail/rt, EXTRACT PUMP GGSCI> START EXTRACT * GGSCI> INFO ALL

EXTTRAILSOURCE告诉数据泵读哪个本地trail；ADD RMTTRAIL建立远程trail映射。全启动后INFO ALL应该看到EXTRACT EXTORA和PUMP都处于RUNNING状态。

4. Linux目标端部署：从安装依赖到Replicat参数落地

目标端是数据最终落地的位置，配置比源端稍简单，但它管着应用侧入口和初始加载，复杂度一点不少。我习惯把目标端的MGR、Replicat、checkpoint表和初始化装载放在一个流程里做，减少反复切换上下文。

4.1 目标端安装与依赖检查

Linux上的OGG安装，核心是两件事：目录和权限。用oracle用户操作：

mkdir -p /u01/ogg chown oracle:oinstall /u01/ogg chmod 750 /u01/ogg cd /u01/ogg # 假设安装包已上传至/home/oracle/ unzip -q /home/oracle/ggs_linux_19c.zip

逻辑说明：只要目录权限正确、安装包版本匹配，解压即可完成安装，不需要configure或make。解压后依然要CREATE SUBDIRS初始化目录。

验证动态库依赖：

ldd /u01/ogg/extract | grep "not found"

参数说明：Oracle 19c的OGG依赖libjvm.so、libnnz19.so等Oracle客户端库。ldd如果输出not found，需要把Oracle环境变量指过去。我一般会在/u01/ogg/.bash_profile里导出：

export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/rdbms/lib export NLS_LANG=AMERICAN_AMERICA.AL32UTF8

NLS_LANG这里必须与目标库字符集一致，否则Replicat按错误字符集解释trail，中文数据直接乱码。如果你的源库是ZHS16GBK，这里就要写AMERICAN_AMERICA.ZHS16GBK，或者让目标库也建为GBK。跨字符集最佳实践是两端都用AL32UTF8，源OGG进程的NLS_LANG也设置成AL32UTF8，让Oracle在日志解析阶段完成转换。

4.2 Replicat与checkpoint表的配置

Replicat进程在目标库回放数据，它的checkpoint信息需要落到一张表中，这张表叫做checkpoint表。先执行OGG自带的建表脚本：

cd /u01/ogg sqlplus ogg/ogg @/u01/ogg/sql/OGGcore.sql

脚本会在目标库创建类似OGG.ggs_checkpoint的系列表。然后在GGSCI里注册：

GGSCI> DBLOGIN USERID ogg@tdb1, PASSWORD ogg GGSCI> ADD CHECKPOINTTABLE OGG.ggs_checkpoint

参数说明：DBLOGIN让GGSCI能连上目标库执行DDL；ADD CHECKPOINTTABLE把checkpoint表绑定给OGG。没有checkpoint表，Replicat进程也能跑，但每次重启都要人工确认位点，容易出错。我每次都建。

接着编辑Replicat参数：

GGSCI> EDIT PARAMS REPORA

REPLICAT REPORA USERID ogg@tdb1, PASSWORD ogg SOURCECHARSET ZHS16GBK TARGETCHARSET AL32UTF8 DISCARDFILE ./dirrpt/repora.dsc, APPEND, MEGABYTES 50 REPERROR DEFAULT, DISCARD HANDLECOLLISIONS MAP ogg.T_ORDER, TARGET ogg.T_ORDER; MAP ogg.T_USER, TARGET ogg.T_USER;

逻辑说明：SOURCECHARSET和TARGETCHARSET声明源端trail字符集与目标库字符集，源库是GBK、目标库是UTF8时必须显式配置；DISCARDFILE指定错误数据落盘位置；REPERROR DEFAULT, DISCARD让无法回放的事务记入discard文件而不终止进程；HANDLECOLLISIONS处理初始化阶段可能出现的重复主键或缺失行；MAP语句完成源表到目标表的映射，这里同名同构，所以两遍写一样。

注意：HANDLECOLLISIONS只应在初始化加载期间使用，日常增量同步必须去掉，否则真正的数据冲突会被静默吞掉。生产上见过团队一年多没去掉这个参数，某天源端漏发了一批变更，目标端全部自动忽略，账都对不上。

注册Replicat并启动：

GGSCI> ADD REPLICAT REPORA, EXTTRAIL ./dirtrail/rt, CHECKPOINTTABLE OGG.ggs_checkpoint GGSCI> START REPLICAT REPORA GGSCI> INFO ALL

4.3 初始化数据装载：先追平基线，再开增量

OGG同步是逻辑复制，只同步日志产生的变更，不会自动拷贝存量数据。所以部署一个新同步链路时，必须先做一次全量初始化，把存量数据搬到目标库，然后让OGG从初始化开始时刻的日志位点继续补增量。

常见做法是用Oracle自带的EXPDP/IMPDP做基线。顺序是：先完成OGG所有进程配置但暂不启动Replicat，源端启动抽取进程和数据泵；用TRANSACTIONS对齐方式确定同步起点后，在源端导出数据；目标端导入完成；最后启动Replicat。

导出导入命令示例：

expdp ogg/ogg@src_db directory=DATA_PUMP_DIR dumpfile=base_%U.dmp parallel=4 tables=ogg.T_ORDER,ogg.T_USER impdp ogg/ogg@dst_db directory=DATA_PUMP_DIR dumpfile=base_%U.dmp parallel=4 table_exists_action=truncate

逻辑说明：导出用expdp并行参数减少总耗时，导入用table_exists_action=truncate清掉目标端可能存在的测试数据，避免主键冲突。导出期间业务继续写入，导入完成后目标库落后一部分增量，这部分由Replicat追上。

参数说明：更稳妥的做法是用OGG的Initial Load模式，即ADD REPLICAT REPORA, SPECIALRUN，让Replicat以一次性任务的方式追完整段trail。但SPECIALRUN方式下不会更新目标端checkpoint表，追完要重启进程切换为正常模式，步骤繁琐。我实际生产首选EXPDP/IMPDP配合CDC式追平：导入完成后启动Replicat，它会自动从远程trail的最早未应用位置开始补数据。前提是目标端导入期间源端的trail文件没有被purge掉，所以初始化期间要把MGR参数里PURGEOLDEXTRACTS的MINKEEPHOURS临时调大，比如改成48小时。

5. 初始化加载与增量同步避坑：5个高频故障定位记录

OGG部署最磨人的是故障排查。我把这些年见过的高频坑整理成5条，每条的写法都是“现象→原因→解决”，方便你真遇到时按图索骥。

5.1 源库没开补充日志：同步第一天就abend

现象：源端EXTRACT进程启动后几秒到几分钟内变成ABEND，查看dirrpt/extora.rpt日志提示ORA-01291: missing log或Supplemental logging not enabled。

原因：源库只开了归档模式，没开补充日志。OGG从在线日志中解析主键列时找不到足够的列信息，直接报错退出。

解决：登录源库执行前面第3.1节的两条ALTER DATABASE命令，开启最小补充日志和强制日志，然后重启EXTRACT进程。注意开启补充日志后，必须推送一次新的归档才能让OGG从新日志中读取完整信息，所以我一般会执行一次ALTER SYSTEM SWITCH LOGFILE，再重启进程。

5.2 目标表已有历史数据：主键冲突刷爆discard

现象：Replicat进程一直RUNNING，但目标表数据不增长，discard文件以MB级速度膨胀，里面全是ORA-00001: unique constraint violated。

原因：目标表里本来就有存量测试数据或历史数据，Replicat回放源端INSERT时主键冲突。这种情况常见于初始化导入没做truncate，或者初始化期间有人手动往目标表插了数据。

解决：先停止Replicat，把涉及的目标表数据清掉，用TRUNCATE TABLE而不是DELETE，避免redo暴涨；再启动Replicat让其重新追放。如果业务上目标表不能清，就得做数据比对、制定合并规则，或者映射时用COLMAP重写目标主键。简单场景就用HANDLECOLLISIONS先撑住，同步稳定后再慢慢排查冲突数据。

5.3 中文变问号：字符集不对齐的老问题

现象：源端表里的中文，同步到目标库变成了??，数字英文正常。

原因：源库ZHS16GBK、目标库AL32UTF8，两边的OGG进程NLS_LANG都没显式设置，各自按操作系统默认字符集解析，中文在字节转码时丢失。

解决：三层对齐。源库OGG进程设置NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK；目标端Replicat进程设置NLS_LANG=AMERICAN_AMERICA.AL32UTF8；在Replicat参数里加上SOURCECHARSET ZHS16GBK和TARGETCHARSET AL32UTF8。改完重启Replicat，它会从trail重新解析，已经乱码的历史数据需要从初始化阶段重新同步。

5.4 时区不一致引起的8小时漂移：看起来像同步丢了

现象：目标库最新一条数据的CREATE_TIME比源库慢8小时，且实时延迟一直存在，但进程状态正常。

原因：两边操作系统时区不一致，源端东八区、目标端UTC，Replicat按目标会话时区解释trail里的时间型数据。

解决：把两端操作系统时区统一为Asia/Shanghai；数据库层确认目标库DBTIMEZONE为+08:00；在Replicat参数中给时间列做显式映射，例如COLMAP (create_time = create_time AT TIME ZONE 'Asia/Shanghai')。改完重启Replicat，先用一条测试数据验证时间一致，再放量同步。

5.5 trail文件占满磁盘：同步进程集体罢工

现象：源端磁盘使用率飙升到100%，EXTRACT进程ABEND，报错Trail file is full或Unable to write to trail file；目标端同样出现磁盘满。

原因：MGR参数里没配PURGEOLDEXTRACTS，或者初始化期间手动把MINKEEPHOURS调大后忘了调回去。trail文件按照每个约10MB持续增长，3天不清理就能吃掉几十GB。

解决：在两端MGR参数中配置自动清理：

PURGEOLDEXTRACTS ./dirtrail/*, USECHECKPOINTS, MINKEEPHOURS 12

USECHECKPOINTS确保只删除所有进程都不再读取的trail，不会误删未消费数据。清完磁盘后重启Manager，它会立即执行一次purge。经验上说，trail文件所在分区至少预留同步峰值日志量的3倍空间，我在生产环境统一按单日redo量的5倍规划。

6. 同步质量验证与日常运维技巧：用一张表盯住延迟和断点

部署完不等于交付，真正决定这套OGG能不能长期扛住的是日常验证手段。我自己的做法是配一个监控SQL，每10分钟查一次两端延迟，超过阈值就告警。

6.1 一条命令盯住交付延迟

GGSCI> INFO ALL GGSCI> STATS REPLICAT REPORA, LATEST

逻辑说明：INFO ALL能看到每个进程的状态和Lag值，Lag的单位是秒，表示源端事务写入trail与目标端应用之间的时间差。正常情况下应该是个位数秒，超过30秒就要关注。LATEST输出最近一次事务的时间戳，判断进程是不是卡住了。

很多团队只看进程RUNNING就认为没事，这是最大的误区。REPLICAT长期RUNNING但Lag持续增大，说明它在缓慢追数据，而不是实时同步。我会把INFO ALL的Lag抓到监控脚本里，超过60秒就报警。

6.2 进程状态巡检与异常恢复

每天定时巡检，除了看进程状态，还要看两端dirrpt目录下的*.rpt文件有没有新增ERROR字样。

grep -i "ERROR" /u01/ogg/dirrpt/*.rpt

一旦发现REPLICAT因某个事务报错，可以跳过坏事务避免整个链路停摆：

GGSCI> SEND REPLICAT REPORA, SKIP

这条命令跳过当前正在报错的事务并继续处理后续数据。注意SKIP等同于丢弃一个事务，必须在核对日志确认跳过的是脏数据或无法回放的历史数据后才执行。真实业务数据不能用SKIP硬跳，要先去源库查清数据，手动补偿。

6.3 日常养护：purge、归档与重启顺序

日常保养三件事：磁盘空间、MGR自动重启、重启顺序。

重启OGG时我严格按照“先目标端后源端、先数据泵后主抽取”的顺序执行：目标端MGR、目标端REPLICAT、源端MGR、源端PUMP、源端EXTRACT。顺序错乱的典型后果是数据泵先起、主抽取未起，远程trail没有新数据，Replicat等待后无异常；但只要顺序反过来，就可能出现源端主抽取持续写trail、目标端还没启Replicat，导致远程trail堆积，磁盘提前占满。

另外，OGG账号密码变更后，参数文件里的USERID和PASSWORD要同步更新。从OGG 19c开始支持USERIDALIAS方式连接Oracle Wallet，能避免密码明文写在dirprm下的参数文件里。生产环境我建议尽早切到USERIDALIAS，配合钱包管理，安全性高很多，也省去每次改数据库密码要同步改OGG配置的麻烦。

最后说一个我自己吃过亏的习惯：无论同步链路多稳定，每个月必须做一次真实故障演练——手动停掉目标端REPLICAT，让它落后10分钟，再手动启，验证能否自动追平。这一步能暴露大量平时发现不了的问题，比如trail被purge过早、checkpoint表损坏、目标表索引失效。一套同步系统如果连续三个月不验证断点恢复，关键时刻基本靠不住。希望这些细节点能帮你在部署OGG时少走几趟弯路。

本文还有配套的精品资源，点击获取