この記事は、Huawei クラウドコミュニティ「GaussDB (DWS) バックアップの問題特定のアイデア」 (著者: yd_216390446) から共有されたものです。

序文

データベースシステムでは、障害はトランザクション内部障害、システム障害、メディア（ディスク）障害に分けられます。トランザクションの内部障害やシステム障害については、ログを利用して人手を介さずに自動復旧します。ただし、メディアの障害に備えて、事前にデータをバックアップする必要があります。

では、DWS をバックアップするにはどうすればよいでしょうか? また、バックアッププロセス中にどのような問題が発生する可能性があり、そのトラブルシューティングと解決方法は何でしょうか?

この記事では主に、DWS バックアップツール roach のバックアップ原理、一般的な問題解決ルーチンおよび関連ケースについて説明します。

1. バックアップの原則

完全バックアップ

この記事で説明するバックアップはすべて物理バックアップです。つまり、データベースは物理ファイルをコピーすることによってバックアップされ、バックアップされたデータファイル、ログ、およびその他のファイルを通じてデータベースを完全に復元できます。

フルバックアップは大きく分けて、ラインストレージのバックアップ、バリアポイントの作成、xlogのバックアップ、カラムのバックアップの各段階に分かれます。

バックアップラインストレージ: 各ノードのメインDNのデータが圧縮され、rchファイルに保存されます。
バリアポイントの作成: CNDN 上のすべてのトランザクションが一貫した状態であることを確認します。この時点まで復元する方が信頼性が高くなります。レコードは作成時に XLog に書き込まれます。
xlog のバックアップ: startLSN と stopLSN の間の xlog をバックアップします。
バックアップカラムストレージ：カラムストレージはxlogを書き込まないため最後尾に配置され、バックアップラインストレージ段階でカラムストレージ内のcudescファイルがバックアップされています。

全体的なプロセスを次の図に示します。

起こりやすい問題:

xlog リサイクルを無効にすると、クラスターが読み取り専用になる可能性があります
DDL の遅延によりクラスターが読み取り専用になる場合もあります

注意点:

バックアッププロセスではFPWを開く必要があります
バックアップ XLog は start_lsn と end_lsn の間で xlog をコピーします
DDL はバックアップ列が保存された場合にのみ有効になります。

DDL が遅延するのはなぜですか?

DDL 操作: alter/truncate/autovacuum/drop/vacuum full/insert overwrite これらは relfilenode のステートメントを変更します。DDL 操作で行と列のストレージリストを取得した後、ユーザーがドロップ操作を実行すると、存在を確認するために、ファイルの遅延 DDL を有効にする必要があります

増分バックアップ

増分バックアップは特定のバックアップに基づいており、どのバックアップに基づいているかを示すために、パラメータ –prior-backup-key を増分バックアップコマンドに追加する必要があります。cbm ファイルを使用して増分ページを識別します。増分バックアップは、累積増分と差分増分に分けられます。

累積増分: 各バックアップは同じ完全バックアップに基づいており、バックアップの内容は完全バックアップと現在のデータ変更です。
差分増分: 各バックアップは前のバックアップに基づいており、バックアップの内容は 2 つのバックアップ間のデータ変更です。

増分バックアップの原理:

前回およびこれまでにバックアップしたデータの変更部分のみをコピーします。コピーの最小単位はブロック（8KB）です。
クラスターが初めてバックアップされるとき、GaussDB カーネルは guc パラメーター (enable_cbm_tracking=on) を有効にし、その後カーネルはデータベースファイルのどのブロックが変更されたかを記録し続け、それらを pg_cbm ディレクトリに記録します。
増分バックアップ中に、cbm ファイルをクエリして変更されたブロックを正確に取得してメモリに保存し、lz4/zlib 圧縮アルゴリズムを実装してバックアップメディアに書き込みます。
増分リカバリ中に、増分バックアップセットから各増分のブロックコンテンツを取得し、それに応じてデータベースファイルの対応するブロックを変更します。
注: guc パラメータがオフになった後、または cbm ファイルが誤って削除された後は、完全バックアップのみを再度実行でき、増分バックアップを続行することはできません。

.cbm ファイルとは何ですか?

外部データページの変更情報と外部インターフェイスを提供するブロックマップが変更されました。cbm 情報に従って、2 つのバックアップ間のデータファイル (行ストレージと列ストレージ) の増分変更情報を直接取得してバックアップできます。

バックアップがシステムに及ぼす影響:

バックアップがシステム IO を占有し、ビジネスが遅くなる
DDL の遅延により xlog バックログが発生し、ディスク容量が増加する
増分バックアップでは cbm ファイルのバックログが簡単に発生し、読み取り専用クラスターが発生する可能性があります

2. 問題特定ルーチン

1) バックアップ呼び出し処理

DWS コントロールプレーン/FI コントロールプレーン -> GaussRoach.py/SyncDataToStby.py -> gs_roach カーネル

コントロールプレーンは、roach の Python スクリプトを呼び出します。これにより、パラメーターが解析され、カーネル側で gs_roach コマンドが呼び出されます。

2) バックアップが失敗した場合は、ログパスを確認する必要があります。

HC/HCS/HCSO クラスター
- コントロールプレーンの呼び出しログ: サンドボックスの外側 /home/Ruby/log/cloud-dws-deploy.log
- コントロールプレーンアーカイブログ: サンドボックスの外側 /home/Ruby/archivelog
- カーネルログ: サンドボックス内の /var/chroot/DWS/manager/backup/log
オフラインクラスター
- カーネルログ: $GAUSSLOG/roach/agent
- Python サイドログ: $GAUSSLOG/roach/controller
観測ログ:
- サンドボックス内の $GAUSSLOG/bin/gs_obs を cd
- Vi gs_obs.run.log で対応するエラー番号を表示します。ここで、obs ログは特定のエラーノードで表示する必要があることに注意してください。

3) 一般的に使用される grep コマンド:

マスターノード IP を表示します: grep “Master Ip” roach_agent*.log

バックアップの進行状況を表示: grep “エージェントの状態を次のように設定しています” roach_agent*.log

バックアップ時間を表示: grep “所要時間” roach_agent*.log | grep “MASTER”

バックアップが成功したかどうかを確認します: grep “バックアップ操作成功。バックアップキー” roach_agent*.log

查看roach_client ip：grep “接続されたリモートメディアへの成功” roach_agent*.log

スレッド割り当ての表示: grep “allotInstanceForMyProc” roach_agent*.log

バックアップコマンドパラメータの表示: grep “command_dict” roach_controller*.log

ファイルがパッケージ化されている場合は、「zgrep コマンドを使用して表示します」

4) キーログのバックアップ

キーワード	説明する
Thread Roach エージェントの作成	エージェントプロセスの作成を開始する
RAGENT_EXEC_PREPARING_METADATA com	メタデータリストの準備を開始する
行ストアコピーのコールバックを入力します	バックアップを開始する
バックアップを実行します	実際に rch へのディスク転送の実行を開始します
Col ファイルのコピーの前に DDL リサイクルを開始するのを遅らせます	遅延 DDL を有効にする
エージェントの状態を [AGENT_CREATING_BARRIER] に設定する	バリアの作成を開始する
RAGENT_EXEC_BACKUP_XLOGFILES が来ます	エージェントが xlog のバックアップを開始します
Colstoreコピーのコールバックを入力します	バックアップを開始する
すべての Col ファイルをコピーした後、遅延 DDL リサイクルを停止します	遅延 DDL をオフにする
マスター状態を [PERFORM_BOOKKEEPING_INFO] に設定する	バックアップが終了すると、マスターノードは結果の要約を開始します。

3. 関連事例

(1) 詳細バックアップエラー libqp 経由で gauss(xxx) に接続できませんでした

[問題の説明] エージェントは、libpq 経由で gauss(host:local、port: 25308) に接続できませんでした、エラー: バックアップ中に接続ポインタが NULL であるというエラーを報告しました。

【トラブル対応計画】

接続エラーとして「host:25308」が報告されるため、該当するタイムノードのcnログを確認してください
cn が致命的なエラーを報告しました: 「base/2278052」は有効なデータディレクトリではありません。データベースに問題があると思われます
データベースに手動で接続しても接続できないことが判明する
残留物が原因で、DN インスタンスディレクトリにディレクトリが存在しません。
データベースを削除すると、データベースが削除され、正常にバックアップされます。

【問題の原因】データベースにファイルが残っている

【回避策】データベース配下に残っているファイルを削除してください。

(2) バックアップがランダムに失敗する

[問題の説明] NBU の問題によりランダムにバックアップが失敗する

【トラブル対応計画】

コントローラーのログを確認すると、最初のエラーノードが xx.xx.xx.148 であることが示されています。
上記のノードに移動してエージェントログを確認し、「Roach クライアントからの不完全なメッセージ」というエラーを報告すると、ログがメディアサーバーを指していることがわかります。そのため、roach クライアントログを確認します。
nbu の問題である可能性があり、対応する roach_client ノードの対応するログを確認し、grep "Success to Connected Remote Media" roach_agent*.log で roach_client の IP アドレスを見つけ、対応する roach_client ノードに ssh で接続し、対応するエラーを確認します。レポートは NBU のエラーレポート、「call NbuManager::CreateFile error」です。NBU 側の同僚と協力してチェックしてください

[問題の原因] 一般に、上記の状況は、roach 側の同時実行が多すぎるため、NBU の負荷が大きくなり、バックアップでエラーが発生することが原因ですが、具体的な詳細については NBU と調整して、実行時に確認する必要があります。同時

[注意事項] 同時実行の問題の場合は、filesplit-size パラメーターを増やし、Parallel-process パラメーターを減らし、バックアップを再開することをお勧めします。

どのような状況で NBU の同僚と協力して調査する必要がありますか?

通常、xbsa や create file などのキーワードが roach_client ログに表示されると、

(3) マスターとエージェント間の接続に失敗し、バックアップが失敗する

【問題内容】マスターとエージェント間の接続に失敗し、バックアップに失敗します。

【関連バージョン】

[トラブルシューティングの解決策] ログには、マスターとエージェント間の接続が失敗し、エージェントが 600 秒以内に接続しなかったことが報告されています。

【問題の原因】

HCS 環境では、ポート 55000 と 56000 のみが開かれており、ポートが開いていないため、エラーが発生します。

【問題回避】

解決策 1: roach コマンドポートを変更する

解決策 2: 対応するポートを開く

(4) 詳細バックアップでファイル情報が見つからず、エラーが報告される

[問題の説明] 詳細なバックアップでエラーが報告されるエラー: ファイル情報の取得に失敗しました。

【関連バージョン】

[トラブルシューティングの解決策] エラー報告ノードのエージェントログを確認し、リレーション xxx のバックアップメインフォークが失敗しました。エラー: ファイル情報の取得に失敗しました。

[問題の原因] 詳細なバックアップ中は DDL 操作がサポートされていません。詳細なバックアップの前に、すべてのテーブルの MAP ファイルが生成され、関係するテーブルの名前とテーブルの関連テーブルが記録されます。relfilenode の DDL 操作の変更を伴うすべてのステートメントにより、バックアップが行われます。失敗（alter/truncate/autovacuum/drop/vacuum full/insert overwrite など）

【問題回避】

シナリオ 1: バックアップおよび DDL 関連の業務時間をずらす

解決策 2: 各バックアップに含まれるテーブルを適切に減らすことで、DDL が原因で発生するバックアップの失敗率を減らすことができます。

(5) バックアッププロセスで、メモリが一時的に利用できないというエラーが報告される

【問題内容】ダンプメタデータのバックアップ段階でエラーメモリが一時的に利用できなくなりました。

【トラブル対応計画】

コントローラーのメモリが一時的に利用できなくなりました。

[問題の理由] パラメータ cpu-cores が大きすぎるため、メモリが遅くなります

[問題回避] cpu-cores パラメータを減らします。

(6) 大規模なクラスター内でゴキブリが頻繁に cms を読み取ると、クラスターの状態が不安定になります。

【問題内容】バックアップ開始時に管理・コントロールパネルにクラスタの状態が異常と表示される大規模クラスタでgs_roachを起動すると頻繁にcmsにアクセスしてクラスタの状態を読み出し、cm_ctlがクラスタの状態を問い合わせる不安定。

【関連バージョン】 821未満のバージョン（バージョン821を除く）

【トラブル対応計画】

cm_server ログ (ローチが開始された後の時点) をクエリし、エラー「CmPqPutMessage return error ret=xx」を報告します。
$GAUSSLOG/bin/cm_ctl ログ、エラー「cm_server へのクエリメッセージの送信に失敗しました」

【問題の原因】

roach の起動中に cm_ctl コマンドが頻繁に呼び出され、クラスターノードの数が多く同時実行数が高いため、ページクラスターの状態監視スクリプトが cm_ctl の実行に失敗します。

【問題回避】

バージョン 821 にアップグレードする

データウェアハウスのバックアップエクスペリエンスの共有丨ローチバックアップの原則と問題解決ルーチンの詳細な説明

序文

1. バックアップの原則

完全バックアップ

増分バックアップ

2. 問題特定ルーチン

1) バックアップ呼び出し処理

2) バックアップが失敗した場合は、ログパスを確認する必要があります。

3) 一般的に使用される grep コマンド:

4) キーログのバックアップ

3. 関連事例