简介面向Oracle数据库向瀚高HGDB迁移与同步场景的专用抽取工具适合需要完成数据库升级、异构数据迁移或双库一致维护的DBA与实施人员。工具围绕ETL流程设计支持从Oracle抽取数据、自动进行类型与结构转换后写入瀚高并能处理存储过程、触发器、索引等Oracle特性同时要求JRE 7运行环境。压缩包共660个文件大小55.29MB以dll、jar、exe、properties为主jar与dll提供核心运行与数据库驱动exe用于启动迁移任务properties、xml等承担连接与同步配置附带丰富的时区规则文件可保障时间数据处理准确。目前已有771人学习下载。迁移过程具备错误处理与恢复机制可在异常时降低中断风险。通过该工具可快速建立Oracle到HGDB的迁移通道降低手工改写成本包内目录和配置模块较完整便于按需调整抽取逻辑也可作为数据库国产化替代项目中的实用参考。1. 瀚高数据库抽取工具数据要搬得动才算数做数据迁移或者数仓接入的人多半都遇到过这种场景源库是瀚高数据库HighGo Database目标可能是另一个瀚高实例、PostgreSQL、Kafka也可能是某个数据湖。这时候你发现网上搜“瀚高数据库抽取工具”出来一堆名词——有说用自带导出工具的有说直接用pg_dump的还有说走ETL工具的。真正动手做一次全量抽取加增量同步坑比想象中多得多字符集乱码、大表导出内存溢出、主备切换后位点失效。这篇文章不聊概念直接把我实际跑过的抽取方案、参数配置、踩坑记录写下来给正在做这块的同行一个能照着复现的底稿。瀚高数据库本身基于PostgreSQL内核这决定了它的抽取工具选型和生态大部分PostgreSQL生态的工具都能直接对接但有一些细节——版本协议、授权模式、自带管理工具的行为差异——会让“通用方案”在瀚高上翻车。这篇文适合三类人一是刚接手瀚高数据迁移的运维或ETL开发二是做数据集成产品、需要适配国产数据库的工程师三是在评估“瀚高数据库抽取工具到底值不值得自己搭”的技术负责人。看完你能回答三个问题用什么抽、参数怎么设、出问题时看哪里。2. 瀚高数据库抽取工具的选型先看内核协议再决定用哪条路2.1 为什么瀚高能直接用PostgreSQL生态的抽取工具瀚高数据库的发行版基于PostgreSQL内核做二次开发这意味着它的网络协议、SQL语法、系统目录结构、复制接口walsender/walreceiver基本和PostgreSQL对齐。这个前提决定了抽取工具选型的底层逻辑所有能连PostgreSQL的抽取工具理论上都能连瀚高。但“理论上能连”和“生产环境敢用”是两码事。实际工作中我见过两种翻车一是用老版本PostgreSQL的pg_dump连新版本瀚高协议握手不通过报错类似“server version mismatch”二是用了瀚高管理工具内置的导出功能但没注意到它默认走的是PL/pgSQL存储过程做数据泵大字段多的表导出速度远不如二进制格式。所以选型的第一步不是挑工具而是先确认两个版本号瀚高的内核版本一般会标注兼容哪个PostgreSQL主版本以及你准备用的抽取工具的主版本。两者主版本号不一致直接放弃别硬调。2.2 四类抽取路线的对比全量、增量、实时、业务侧我一般把抽取工具分成四类按“从哪一层抽”来分路线代表工具/方式适用场景主要限制逻辑全量导出瀚高自带的导出工具、pg_dump、pg_dumpall数据迁移、备份归档停机窗口内完成数据量大时耗时长物理增量同步逻辑复制subscription、流复制槽持续同步、容灾、数仓实时入仓需要开启wal_levellogical占用复制槽外部表/联邦查询postgres_fdw、dblink跨库实时查询、小批量抽取不适合大数据量批量抽取业务侧时间戳抽取手写SQL按修改时间、自增ID分批拉取数仓T1抽取、无DBA权限场景依赖业务表的规范度删除操作难捕获这里先说结论数据量在百GB以内、能接受停机窗口的直接用pg_dump配合瀚高的兼容层做逻辑备份最简单可靠数据量大、又要持续同步的优先考虑逻辑复制没有超级权限、只能通过业务账号访问的老老实实写时间戳增量。后面第4章会展开讲增量方案这里先不铺开。2.3 抽取前的账号与权限准备最小授权清单无论选哪条路线抽取工具连库都需要一个专门的账号。我踩过最大的坑是直接用超级用户跑抽取任务结果因为权限过大工具初始化时把会话级参数改了导致生产库行为变化。正确的做法是创建专用抽取账号按最小权限授权。-- 创建抽取专用账号避免使用超级用户 CREATE ROLE etl_user WITH LOGIN PASSWORD your_strong_password; -- 全量抽取需要读所有目标表授权用法如下 GRANT CONNECT ON DATABASE your_db TO etl_user; GRANT USAGE ON SCHEMA public TO etl_user; -- 对业务表授予SELECT权限如果要抽取到文件需要访问pg_read_server_files GRANT SELECT ON ALL TABLES IN SCHEMA public TO etl_user; GRANT pg_read_server_files TO etl_user; -- 增量场景使用逻辑复制需要REPLICATION权限 GRANT pg_replication_slot TO etl_user;逻辑说明etl_user是一个独立账号不碰业务写入权限只做读取和复制。pg_read_server_files这个角色用于COPY ... TO PROGRAM或者pg_read_file类的服务端文件读取全量导出到服务端文件时必须有。逻辑复制则额外需要pg_replication_slot权限用来创建和管理复制槽。参数说明如果用瀚高自带的图形化工具创建用户注意它有两个选项“超级用户”和“复制用户”选后者即可满足多数抽取场景不要图省事选超级用户。3. 用pg_dump做全量抽取最小命令与参数调优3.1 最小可用命令一行导出三步还原瀚高数据库兼容PostgreSQL协议所以pg_dump是最好上手的全量抽取工具。最常见的做法是直接用PostgreSQL发行版自带的pg_dump连瀚高IP指定兼容模式导出。下面这套命令是我在测试环境验证过的最小可用集# 第一步导出为自定义压缩格式非纯SQL pg_dump -h 192.168.1.10 -p 5866 -U etl_user -d highgo_db \ -Fc --no-owner --no-privileges \ -f /data/backup/highgo_db_$(date %Y%m%d).dump # 第二步在目标端创建空库 createdb -h 192.168.1.20 -p 5432 -U postgres target_db # 第三步还原 pg_restore -h 192.168.1.20 -p 5432 -U postgres -d target_db \ --no-owner --no-privileges -j 4 \ /data/backup/highgo_db_$(date %Y%m%d).dump逻辑说明第一步用-Fc自定义格式这个格式不是纯SQL文本而是经过压缩的二进制归档好处是还原时可以用pg_restore并行并且支持选择性恢复单表。加--no-owner和--no-privileges是为了避免把瀚高库里的对象属主和权限原样搬到目标库目标端如果账号体系不同会直接还原失败。参数说明-p 5866是瀚高默认端口有些发行版可能改成5432以实际环境为准-j 4表示用4个并行进程还原实测对多表场景提速明显但注意不要超过目标端CPU核数。3.2 必调的5个参数格式、压缩、并行、表过滤、编码pg_dump的参数看着多真正需要每次确认的就五个第一个是-Fc自定义格式上面已经说了默认的-Fp纯文本格式不是不能用但还原时没法并行、也没法选择性恢复生产环境我基本不用。第二个是-Z压缩级别范围0到9默认是中等压缩但如果你要导出的库以文本字段为主压缩率很高建议拉到-Z 6以上如果是数值型为主压缩收益不大-Z 3更省CPU。第三个是-j并行度注意-j只在自定义格式下生效它影响的是导出阶段的表级并行不是单表单线程。第四个是表过滤这个最实用# 只抽取指定的业务表排除日志表、临时表 pg_dump -h 192.168.1.10 -p 5866 -U etl_user -d highgo_db \ -Fc -t public.order_* -T public.tmp_* -T public.*_log \ -f /data/backup/order_tables.dump逻辑说明-t指定包含哪些表支持通配符-T指定排除哪些表。这里-t public.order_*表示抽取order_前缀的所有表-T排除tmp_前缀和_log后缀的表。参数说明如果-t和-T同时用-T的优先级更高即表同时匹配两个规则时最终被排除。第五个是编码后面避坑章会详细讲这里先记住源库和目标库字符集不一致时导出阶段就显式指定--encodingUTF8不要赌默认值。3.3 定时全量抽取保留策略与文件命名全量抽取一旦上了定时任务就不能只写一行pg_dump。文件名要带日期、保留策略要自动清理、抽取日志要留底。下面是我常用的脚本骨架#!/bin/bash BACKUP_DIR/data/backup DB_HOST192.168.1.10 DB_PORT5866 DB_USERetl_user DB_NAMEhighgo_db RETENTION_DAYS7 # 导出并记录日志 pg_dump -h ${DB_HOST} -p ${DB_PORT} -U ${DB_USER} -d ${DB_NAME} \ -Fc --no-owner --no-privileges -Z 6 \ -f ${BACKUP_DIR}/${DB_NAME}_$(date %Y%m%d_%H%M%S).dump \ ${BACKUP_DIR}/export.log 21 # 校验导出文件是否生成成功 if [ $? -eq 0 ] [ -s ${BACKUP_DIR}/${DB_NAME}_$(date %Y%m%d_%H%M%S).dump ]; then echo $(date %Y-%m-%d %H:%M:%S) export success ${BACKUP_DIR}/export.log # 清理超过保留天数的旧文件 find ${BACKUP_DIR} -name ${DB_NAME}_*.dump -mtime ${RETENTION_DAYS} -delete else echo $(date %Y-%m-%d %H:%M:%S) export FAILED ${BACKUP_DIR}/export.log exit 1 fi逻辑说明脚本先执行导出$?拿到pg_dump的退出码-s检查文件非空两个条件同时满足才算成功。find按-mtime 7清理7天前的文件避免磁盘被占满。参数说明-Z 6是压缩级别文本多的库可以继续调高-s判断文件是否非空这能挡掉pg_dump退出码为0但文件内容为空的一半Bug。4. 增量抽取与持续同步从时间戳到逻辑复制4.1 时间戳增量抽取适用场景与三个前提全量抽取适合一次性迁移但数仓接入、报表同步这类场景需要每天或者每小时拉增量。最朴素的做法是时间戳增量业务表里有update_time或者modify_time字段抽取SQL带上WHERE update_time 上次游标。这个方法能跑但有三个前提缺一不可。前提一是业务表必须有统一的、有索引的修改时间字段且该字段由应用层维护不是数据库默认值——很多表只有创建时间没有更新时间这种表没法用时间戳增量。前提二是业务侧不能物理删除数据否则删除动作不会被时间戳捕获常见应对是逻辑删除标记位配合定时清理。前提三是时间戳精度要够如果业务表用timestamp(0)精确到秒而抽取频率是一分钟一次同一秒内修改的数据要么重复拉要么漏拉。解决办法是游标不存时间点存(时间戳, 主键)组合保证同一秒内的记录按主键排序后不重不漏。4.2 避免重复与遗漏游标位点设计时间戳增量最常见的翻车现场是重复数据把目标表主键顶爆或者漏数据导致对账不平。这两个问题本质上是游标位点设计不合理。下面这个设计我用了很久基本没出过事-- 抽取游标表记录每张表的增量位点 CREATE TABLE etl_cursor ( table_name text PRIMARY KEY, last_max_time timestamp not null, last_max_id bigint not null default 0, updated_at timestamp not null default now() ); -- 每次抽取时先取游标再按位点拉取 -- 注意这里用 last_max_time last_max_id 组合条件 SELECT * FROM business_table WHERE (update_time :last_max_time) OR (update_time :last_max_time AND id :last_max_id) ORDER BY update_time, id;逻辑说明游标里同时存last_max_time和last_max_id下一次抽取时用“时间大于游标时间或者时间等于游标时间且主键大于游标主键”这个条件。这就解决了同一秒多条记录的问题。参数说明updated_at字段用于监控游标本身有没有被更新如果抽取任务失败这个字段不会刷新排查时一眼就能看出来。注意这里的id必须是单调递增的主键如果不是改成业务上保证有序的字段也行。4.3 持续同步的正确姿势瀚高作为源端的逻辑复制配置如果增量场景对延迟要求高比如分钟级甚至秒级时间戳方案就不够了。瀚高兼容PostgreSQL的逻辑复制可以把瀚高当作发布端目标库作为订阅端。配置分三步容易出错的是第一步。-- 源端瀚高开启逻辑复制 -- 修改 postgresql.conf wal_level logical max_replication_slots 4 max_wal_senders 8 -- 创建发布PUBLICATION CREATE PUBLICATION pub_biz FOR ALL TABLES;-- 目标端PostgreSQL或另一个瀚高实例创建订阅 CREATE SUBSCRIPTION sub_biz CONNECTION host192.168.1.10 port5866 dbnamehighgo_db useretl_user passwordxxx PUBLICATION pub_biz;逻辑说明wal_levellogical是逻辑复制的前提它会让WAL日志记录足够的信息来重建行变更。改这个参数需要重启瀚高数据库所以要在维护窗口做。max_replication_slots和max_wal_senders是配套参数建议数值根据后续要加多少订阅端来定。参数说明FOR ALL TABLES表示发布所有表如果只想发布部分表改成FOR TABLE table1, table2。订阅端的CONNECTION字符串里不要写超级用户账号用之前建好的etl_user即可。逻辑复制的坑在于一是发布端表结构变更比如新增列不会自动同步到订阅端需要手动操作二是主备切换后订阅的位点可能失效需要重建订阅三是大事务在逻辑复制下会放大延迟比如一次性UPDATE一百万行订阅端要等这个事务全部应用完才能继续。5. 抽取工具的避坑清单字符集、版本、内存与位点5.1 中文乱码源库、目标库、客户端三层字符集不一致现象导出文件里中文正常还原到目标库后变成一堆问号或者“锟斤拷”。原因pg_dump执行时会读取源库的server_encoding和客户端字符集。如果客户端字符集没设置默认继承操作系统的locale。比如源库是UTF8客户端是SQL_ASCII导出过程中字符集转换就会产生不可逆损失。解决导出命令里显式加PGCLIENTENCODINGUTF8环境变量或者在pg_dump参数里加--encodingUTF8。还原时同理目标端执行SET client_encoding TO UTF8后再跑pg_restore。测试环境验证方式很简单导出后直接pg_restore -l列出归档内容如果表名或注释里的中文还是正常的再走还原流程。5.2 pg_dump版本不匹配识别不出归档文件现象用PostgreSQL 14的pg_dump连瀚高报“unsupported version (1.14) in archive”或者“server version mismatch”。原因瀚高内核版本对应的pg_dump版本和连接端版本不一致。pg_dump只向前兼容一个主版本跨两个主版本就不认了。解决第一优先用瀚高自带的导出工具或者安装目录下的pg_dump版本一定匹配第二优先从瀚高官方网站下载对应版本的客户端工具包实在没有用PostgreSQL官方pg_dump时确保主版本号和瀚高标注的兼容版本一致。这里注意不是版本越新越好pg_dump版本高于服务端主版本也会报错。5.3 大表抽取OOM服务端内存被查询拖垮现象抽取一张5亿行的大表时pg_dump进程没有崩但数据库服务端的内存持续上涨最后OOM killer把postmaster干掉了。原因逻辑导出大表时服务端会为每个表建立快照并执行COPY操作。如果业务表上有大字段text、bytea且同时有多个并行抽取任务每个后端进程占用的内存会线性叠加。数据库shared_buffers和work_mem不够时就会触发OOM。解决控制并行度-j不要超过4对单张超大表拆成多个分区按范围抽取检查work_mem配置如果单次抽取排序量很大把work_mem从默认4MB调到64MB或128MB但要小心——它会影响所有会话调太高反而更容易OOM。另外同步检查max_connections连接数满了会直接拒绝抽取工具建立新连接。5.4 主备切换后增量位点失效现象瀚高主库宕机备库提升为主库后逻辑复制订阅端报“replication slot does not exist”。原因逻辑复制槽是存在主库上的主备切换后备库没有复制槽信息订阅端拿着旧位点去找新主库自然找不到。解决接管后重建发布和订阅。具体步骤先在订阅端执行ALTER SUBSCRIPTION sub_biz DISABLE然后删除订阅DROP SUBSCRIPTION sub_biz再在新主库上确认pg_publication存在且表结构一致最后重新CREATE SUBSCRIPTION。注意重建订阅会重新初始化快照数据如果数据量很大这段时间目标端的延迟会比较大建议在业务低峰期操作。还有一个更稳的替代方案用pg_sync_replication_slots之类的第三方扩展做复制槽迁移但瀚高生产环境不一定装了这种扩展别在没验证过的环境下上。我一般直接选择重建订阅简单可控。5.5 瀚高数据库是免费的吗授权模式对抽取工具的隐性约束很多人在选型时问“瀚高数据库是免费的吗”这其实不只是成本问题它直接影响你能用什么抽取工具。瀚高有社区版和企业版的区别社区版可以免费用于学习测试但生产环境商用需要购买授权。关键在于企业版可能默认启用了一些管理组件或安全模块这些模块会改变数据库的对外行为。实际影响抽取工具的点有两个一是企业版如果开启了透明加密用pg_dump导出的文件是明文还是密文取决于导出通道二是企业版自带的管理工具可能要求通过它的统一认证直接绕过账号密码用pg_dump连库会被拒绝。我的建议是部署前先确认版本类型和授权边界然后找对应的官方文档确认抽取工具的兼容性列表。如果用的是社区版直接按PostgreSQL生态工具走基本没额外限制。6. 抽取结果验证行数对得上、数据对得上才算完成6.1 行数与checksum双重校验抽取完不校验等于白干。最简单的校验是行数对比但只对比行数不够——如果源表有100万行目标表也有100万行但中间有10万行的数据和源表错位了行数完全看不出来。我一般做两层校验。第一层批处理跑完先对比每张表的行数。第二层对关键业务表做checksum校验。PostgreSQL生态没有内置的跨库checksum函数但可以用md5(string_agg())的方式做。注意大表别直接跑要分段。-- 源端瀚高执行把整表的关键列拼接后算md5 SELECT md5(string_agg(t.row_hash, ORDER BY t.pk)) AS source_checksum FROM ( SELECT pk, md5(col1 || | || col2 || | || col3) AS row_hash FROM business_table ORDER BY pk ) t;-- 目标端执行同样的SQL对比两个checksum是否一致 SELECT md5(string_agg(t.row_hash, ORDER BY t.pk)) AS target_checksum FROM ( SELECT pk, md5(col1 || | || col2 || | || col3) AS row_hash FROM target_business_table ORDER BY pk ) t;逻辑说明先对每行数据算一个md5再把所有行的md5按主键顺序拼接后算一个总md5。任何一行数据的任何字段变化总md5都会变。参数说明||拼接时注意字段里如果本身包含|字符要选一个不会出现的分隔符或者用concat_ws函数替代。ORDER BY pk保证两端的拼接顺序一致否则即使数据完全相同总md5也会不一致。对大表全表md5非常耗时我通常只对最近7天的增量数据做checksum全量数据靠抽样加行数兜底。6.2 增量场景的对账怎么快速定位漏掉的行增量同步跑了一段时间后源库和目标库的数据差是慢慢积累的。对账SQL要做到能快速定位差异行而不是全表扫。常见做法是以源端为准用主键反查目标端-- 找出源端有、目标端没有的行只拉最近一天控制扫描范围 SELECT s.pk, s.update_time FROM source_business_table s LEFT JOIN target_business_table t ON s.pk t.pk WHERE t.pk IS NULL AND s.update_time now() - interval 24 hours;逻辑说明LEFT JOIN加WHERE t.pk IS NULL是标准的“找缺失”写法。这里限定update_time是最近24小时避免每次对账都全表扫描。参数说明如果两端主键类型不同比如源端是字符串、目标端是数值先把主键转换统一再JOIN否则这个SQL会走全表扫描慢得没法看。如果两端数据量大追求性能的替代方案是导出主键列表到文件用sort和comm做差集。这个技巧在处理上亿行大表时比SQL JOIN快得多代价是占用磁盘空间写中间文件。6.3 抽取任务的监控与补偿失败后别急着重跑定时抽取任务跑挂了新手最常见的操作是直接重跑一遍。但如果是增量抽取重跑可能造成重复数据入目标库。我现在的习惯是第一所有抽取任务写日志到独立文件不混在应用日志里。日志至少包含任务开始时间、抽取类型全量/增量、涉及表数量、成功/失败状态、耗时、失败原因。没有日志的定时任务等于没有后悔药。第二增量任务失败后先查游标表etl_cursor有没有更新。如果游标没动说明任务在拉取阶段就失败了可以安全重跑如果游标已经推进但目标表没有对应数据那就是写入阶段部分成功需要做一次对账再决定是续跑还是回滚目标库。第三配置一个简单的超时保护。pg_dump有个--statement-timeout参数但它是作用于单个语句的对整个导出任务不生效。我一般用timeout 7200 pg_dump ...这种方式超过2小时直接杀掉进程然后告警通知。这比等进程自己hang住再被人发现强得多。用这套方式我接管过的抽取任务基本没有再出现“跑完了但数据不对”的尴尬。做数据抽取这行工具选型只占三分剩下七分全是验证和兜底。每次接新的抽取需求我都会先问一句目标端怎么证明数据是对的这个问题问清楚了后面的活就好干了。希望帮到你。本文还有配套的精品资源点击获取
