vb：邏輯備份恢復(fù)失敗常見原因分析及案例2025

1.非標(biāo)準(zhǔn)操作類

1.1 vb_dump -h 遠(yuǎn)程備份: 查詢失敗:ERROR: unrecognized configuration parameter "enable_duplicate_indexnames"

  • 數(shù)據(jù)庫版本：Vastbase G100 2.2 Build 15.8

  • 兼容模式：A

  • 問題現(xiàn)象
    使用2.2 Build 15.6中的vb_dump工具，通過指定-h參數(shù)去備份遠(yuǎn)端2.2 Build 15.8的數(shù)據(jù)，執(zhí)行發(fā)生報(bào)錯(cuò)，兩邊都是A兼容模式，報(bào)錯(cuò)內(nèi)容為

  • 問題原因
    原因是這個(gè)參數(shù)是2.2.15 psu8引入的，之前的版本識別不了。

  • 解決辦法
    不同版本之間不要使用vb_dump進(jìn)行遠(yuǎn)端備份。
    不僅是因?yàn)閰?shù)不識別的原因，還因?yàn)椴煌姹驹獢?shù)據(jù)、系統(tǒng)表等也存在差異。

1.2 vb_dump源庫100G+,備份文件3G+，恢復(fù)后數(shù)據(jù)不完全

  • 數(shù)據(jù)庫版本：Vastbase G100 2.2 Build 10.11

  • 兼容模式：A

  • 問題現(xiàn)象
    目標(biāo)庫導(dǎo)入存在value too long報(bào)錯(cuò)

以cm_mbox表為例進(jìn)行排查，違反了非空約束。
在源端查看表結(jié)構(gòu)、數(shù)據(jù)及兼容模式，源端為B兼容模式

查看目標(biāo)端兼容模式，發(fā)現(xiàn)是A兼容模式。
在目標(biāo)端重建庫指定兼容模式為B，重新導(dǎo)入沒有報(bào)錯(cuò)，查詢兩邊數(shù)據(jù)一致。

查看表統(tǒng)計(jì)信息，發(fā)現(xiàn)源端表數(shù)據(jù)update頻繁，存在膨脹，create table as select*from 原表，實(shí)際只有30MB。

  • 問題原因
    1.恢復(fù)數(shù)據(jù)不全原因: 源庫為B兼容模式，目標(biāo)庫為A兼容模式，導(dǎo)入數(shù)據(jù)存在value too long及違反非空約束相關(guān)報(bào)錯(cuò)，導(dǎo)致部分?jǐn)?shù)據(jù)未導(dǎo)入成功。
    2.備份數(shù)據(jù)量不一致原因:源庫表DML頻繁，存在很多dead元組，表膨脹嚴(yán)重，因此備份文件大小和看到的庫表大小差異很大。

  • 解決辦法
    重建目標(biāo)端數(shù)據(jù)庫指定兼容模式為B兼容模式，重新導(dǎo)入數(shù)據(jù)即可。

1.3 包名加引號時(shí)無法被vb_dump導(dǎo)出

  • 數(shù)據(jù)庫版本： Vastbase G100 2.2 Build 15.7
  • 兼容模式：A
  • 問題現(xiàn)象：

  • 問題原因：
    問題原因
    "my_pkg.package_test"并不表示在my_pkg這個(gè)schema下建立包package_test，而是表示在public下建立名為"my_pkg.package_test"的包，dump語句中只添加的-n參數(shù)規(guī)定只導(dǎo)出my_pkg下的對象，所以在public下的"my_pkg.package test"無法被導(dǎo)出。

  • 解決方法：
    改成"my_pkg"."package_test"

1.4 備庫vb_dump導(dǎo)出數(shù)據(jù)報(bào)錯(cuò)ERROR:canceling statement due to conflict with recovery

  • 數(shù)據(jù)庫版本：Vastbase G100 2.2 Build 15.5
  • 問題現(xiàn)象
    由于與恢復(fù)操作沖突，正在取消語句命令。

  • 問題原因
    客戶數(shù)據(jù)庫為集群環(huán)境，使用備節(jié)點(diǎn)進(jìn)行vb_dump導(dǎo)出操作，此時(shí)如果WAL回放與vb dump查詢相同的對象，此時(shí)wal日志回放會(huì)等待查詢執(zhí)行完成，但等待時(shí)間由參數(shù)max_standby_streaming_delay確定（默認(rèn)是3s），wal回放線程在等待超過max_standby_streaming_delay參數(shù)配置的時(shí)間，wal回放線程會(huì)殺掉備節(jié)點(diǎn)的查詢進(jìn)程，來保障wal回放順利進(jìn)行。

  • 解決辦法

  • vb_dump操作避免在備節(jié)點(diǎn)執(zhí)行，存在概率造成導(dǎo)出線程中斷。(物理備份恢復(fù)也是一樣)

  • 如必須在備節(jié)點(diǎn)完成，則選擇業(yè)務(wù)低峰操作，或在vb_dump操作前臨時(shí)增大max_standby_streaming_delay參數(shù)值，操作后回調(diào)，無需重啟即可生效。

2.參數(shù)配置類

2.1 MySQL兼容模式lower_case_table_names=1時(shí)，vb_dump導(dǎo)出大寫的表報(bào)錯(cuò) no

matching tables were found for pattern "S1.Tea'

  • 數(shù)據(jù)庫版本：Vastbase G100 2.2 Build 15.7
  • 兼容模式：B
  • 問題現(xiàn)象：
  • 問題原因
    vb dump中即使添加雙引號，獲取到的字符串也是雙引號內(nèi)的內(nèi)容如Tea，由于設(shè)置的lower_case_table_names =1對象名統(tǒng)一使用小寫樣式保存，會(huì)導(dǎo)致對象找不到。
  • 解決辦法
    參考官網(wǎng)說明，使用反斜杠轉(zhuǎn)義。
    如果攜帶雙引號，則只會(huì)獲取雙引號內(nèi)的內(nèi)容，即 -t Tea 和 -t"Tea"的效果是一樣的，又因?yàn)?br> lowercase tablenames 設(shè)置為1（大小寫不敏感），因此查詢時(shí)會(huì)全部轉(zhuǎn)為小寫，要導(dǎo)出大寫的表按照規(guī)避方法即可 -t"Tea"
  • 成功案例

2.2 vb_restore -p 5432 -f /data/backup/tcxc_test.dmp -d test_db報(bào)錯(cuò):必須為gs_restore指定轉(zhuǎn)儲文件名/路徑

  • 數(shù)據(jù)庫版本：Vastbase G100 2.2 Build 10 commit 14301
  • 兼容模式：A
  • 問題現(xiàn)象：vb_dump 導(dǎo)出，在其他庫上還原vb_restore失敗。

  • 問題原因
    vb_restore恢復(fù)時(shí)直接指定備份文件即可，不需要加-f(-f 指定生成腳本的輸出文件，-d和-f不能同時(shí)使用)

  • 解決辦法
    -d和-f不同時(shí)使用。

2.3 備庫開啟極致rto后，vb_dump報(bào)錯(cuò):ERROR SETTRANSACTION ISOLATION LEVEL must be called before any query

  • 數(shù)據(jù)庫版本：Vastbase G100 2.2 Build 15.7
  • 兼容模式：A
  • 問題原因
    極致RTO不支持商用，建議不要上生產(chǎn)。
  • 解決辦法
    關(guān)閉備庫極致RTO。

3.已修復(fù)缺陷

3.1 SQL Server兼容模式下，vb_dump導(dǎo)出包含關(guān)鍵字top的表報(bào)錯(cuò)，查詢失敗: ERROR:syntax error at or near "top"

  • 問題原因
    MSSOL兼容模式的導(dǎo)出場景下，缺少檢測名稱是否是關(guān)鍵詞的邏輯
  • 解決辦法
    升級數(shù)據(jù)庫至Vastbase G100 2.2 Build 15.7或以上版本。
    規(guī)避方案:在vb_exclude_reserved_words中配置top，屏蔽關(guān)鍵字(但需要重啟數(shù)據(jù)庫生效，且涉及top關(guān)鍵字的功能可能無法使用，需要結(jié)合實(shí)際業(yè)務(wù)場景考慮)。

3.2 vb dump備份帶auto_increment序列的數(shù)據(jù)，當(dāng)使用-a導(dǎo)出時(shí)，報(bào)錯(cuò):不允許修改由

auto increment擁有的序列

  • 問題原因
    auto_increment列會(huì)自動(dòng)創(chuàng)建一個(gè)sequence，該sequence不能手動(dòng)setval，全量導(dǎo)出時(shí)，表信息會(huì)記錄autoinc對應(yīng)的sequence的名字，后續(xù)導(dǎo)出sequence時(shí)可以忽略。僅數(shù)據(jù)導(dǎo)出時(shí)，表信息沒有記錄autoinc對應(yīng)的sequence的名字，導(dǎo)致該sequence沒有被忽略，最后導(dǎo)致導(dǎo)入報(bào)錯(cuò)。
  • 解決辦法
    升級至2.2 Build 15.8或以上版本,

3.3 vb_dump導(dǎo)出帶有out參數(shù)的存儲過程，導(dǎo)入時(shí)報(bào)錯(cuò)

  • 問題描述
    vb_dump導(dǎo)出帶有out參數(shù)的存儲過程，導(dǎo)入時(shí)報(bào)錯(cuò)。
  • 測試用例

導(dǎo)出正常：

導(dǎo)入報(bào)錯(cuò)：

  • 問題原因
    sqlserver兼容模式下存儲過程含0ut參數(shù)匹配時(shí)考慮不全，導(dǎo)致某些場景無法正確匹配
  • 發(fā)布計(jì)劃
    V2.2.15.8補(bǔ)丁

3.4 vb_restore導(dǎo)入大量臨時(shí)表時(shí)，導(dǎo)入速度慢

vb_restore導(dǎo)入速度越來越慢，接近10000條每導(dǎo)入100條數(shù)據(jù)接近1分鐘。由于太慢，沒有完成導(dǎo)入。
導(dǎo)入數(shù)據(jù)中存在大量臨時(shí)表。換成G1002215.5數(shù)據(jù)庫導(dǎo)入，速度正常。

測試用例：

  • 問題原因
    客戶用到了多個(gè)全局臨時(shí)表，代碼原本設(shè)計(jì)中，如果一個(gè)會(huì)話中有多個(gè)臨時(shí)表帶有on_commit_delete，當(dāng)會(huì)話中的某個(gè)事務(wù)即使只是用到了其中一張也會(huì)做所有臨時(shí)表的truncate。這個(gè)邏輯本身是錯(cuò)誤的。
  • 解決方案
    在事務(wù)中新增一個(gè)hash表，當(dāng)它提及某個(gè)臨時(shí)表就把臨時(shí)表加入這個(gè)hash表，最后做truncate的時(shí)候，通過hash表來找到與這個(gè)事務(wù)相關(guān)的臨時(shí)表進(jìn)行truncate。
  • 發(fā)布計(jì)劃
    2.2.10 PSU19

3.5 B兼容模式，lower_case_column_names=0，vb_dump返回的列名大小寫不敏感

  • 問題描述
    B兼容模式，lower_case_column_names=0，vb_dump返回的列名大小寫不敏感
  • 測試用例
  • 問題原因
    本問題的場景就是關(guān)鍵字直接作為列名，在導(dǎo)出元數(shù)據(jù)的時(shí)候誤判為應(yīng)該帶雙引號，并且選擇了轉(zhuǎn)小寫的版本。實(shí)際這種情況應(yīng)該不帶雙引號導(dǎo)出。
  • 發(fā)布計(jì)劃
    V2.2.15.7補(bǔ)丁、V2.2.10.19補(bǔ)丁

3.6 恢復(fù)備份后索引名后面自動(dòng)增加了“數(shù)字”

  • 問題描述
    備份索引后，vsql恢復(fù)的時(shí)候索引名稱后會(huì)被加”數(shù)字"，當(dāng)使用force index時(shí)，因?yàn)檎也坏剿饕鴪?bào)錯(cuò)。
  • 測試用例
    備份中的索引DDL: CREATE INDEX idx_alarmevent_type_502047 ON ipc_alarmevent USING btree (alarmtype,cttime,ipcarea,chktimes, alarmno, procstatus);
    但是在圖中可以看到，索引名變成了:idx_alarmevent_type_502047_55462
  • 問題原因
    原因是B模式實(shí)現(xiàn)重復(fù)索引名是通過在索引名后增加關(guān)系表的oid后綴進(jìn)行區(qū)分，（備份時(shí)這樣做是沒問題的），恢復(fù)時(shí)遺漏了 pg_get_indexdef 中截?cái)噙@個(gè)后綴。
  • 解決方案
    已將該特性合入2215最新版本
  • 發(fā)布計(jì)劃
    V2.2.15.8補(bǔ)丁

3.7 創(chuàng)建有發(fā)布或訂閱的庫，vb_dump導(dǎo)出報(bào)錯(cuò)Segmentation fault或invalid dumpId 32665或 invalid dumpId 0.(數(shù)字不固定)

  • 問題原因
    問題原因是vb_dump對sub和pub做備份時(shí)，提前釋放了object的內(nèi)存
  • 解決辦法
    升級到2210 psu14及以上版本。2215也已修改。

3.8 去掉vastbase_sql_mode 中的ansi_quotes值，vb_dump報(bào)錯(cuò)

  • 問題原因
    當(dāng)沒有啟用ANSI_QUOTES時(shí)，雙引號引用內(nèi)容被解釋為字符串。
  • 解決辦法
    規(guī)避方案:vastbase_sql_mode中添加ansi_quotes，導(dǎo)出后再修改還原參數(shù)配置
    預(yù)計(jì)2215 PSU9修復(fù)。

4.規(guī)劃中

4.1 性能：vb_dump導(dǎo)出效率較低，和mysqldump導(dǎo)出相比相差時(shí)間較大

  • 問題現(xiàn)象
    測試兩張空表的導(dǎo)出速度如下，mysqldump耗時(shí)為0.018s，pg_dump耗時(shí)為2.011S。

測試結(jié)果:在2.2 Build 15.7、2215.8(包括重新初始化實(shí)例)、V3.0.8測試
2215.7和8均比較慢，V308效率高。

查看2215日志發(fā)現(xiàn)存在很多個(gè)pg_catalog.gs_is_recycle_obj函數(shù)調(diào)用。
而V3.0.8僅調(diào)用了3次該函數(shù)。

通過打開server的 log_statement，記錄dump期間所有的SOL，發(fā)現(xiàn)幾個(gè)大量被執(zhí)行的SOL:
1.gs_is_recycle_obj，被執(zhí)行7000+次
2.SELECT * FROM pg_proc a LEFT JOIN pg_namespace b on a.pronamespace=b.oid WHERE a.proname='gs_is_recycle_obj' and b.nspname='pg_catalog'; 查詢gs_is_recycle_obj 函數(shù)是否存在，被執(zhí)行 7000+次
3.select count(*) from pg_depend xxx;查詢pg_depend確認(rèn)package，被執(zhí)行700+ 次。
4.working_version_num()函數(shù)，被執(zhí)行3000+次

  • 問題原因
    舊版dump代碼設(shè)計(jì)問題，相當(dāng)于一次簡單的vb_dump，即使只導(dǎo)出一個(gè)表，也要執(zhí)行 2W+條SQL，所以CPU被占用高。導(dǎo)出效率低。
  • 解決辦法
    計(jì)劃2215 psu9、2210 psu21修復(fù)。

4.2 性能：308導(dǎo)出10w空表，postgres導(dǎo)出1分半導(dǎo)入1分鐘，vb導(dǎo)出2h+導(dǎo)入83分鐘

  • 問題原因
    vb_dump代碼設(shè)計(jì)原因。執(zhí)行了一些無謂的sql，導(dǎo)致性能下降。

  • 解決辦法
    預(yù)計(jì)308 PSU3修復(fù)。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容