この記事では、物理バックアップの過程でデータバックアップに失敗した場合のトラブルシューティングと問題特定方法について説明します。
このドキュメントでは、OceanBaseデータベースのインストールディレクトリを /home/admin/oceanbase として説明します。ドキュメント内で言及されているログの実際の保存パスは、実際の環境に基づいてください。
課題1:データバックアップタスクの開始に失敗
データバックアップタスクの開始に失敗した場合は、以下の手順でトラブルシューティングを行うことができます。
rootユーザーでクラスタのsysテナントにログインします。以下のステートメントを実行して、タスクが失敗した原因を確認します。
SELECT * FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY WHERE module='backup_data' AND event ='start_backup_data';クエリ例は次のとおりです:
+----------------------------+-------------+-------------------+-----------+--------+--------+--------+-------+--------+-------+--------+-------+--------+-------+--------+------------+----------------+-------------+ | TIMESTAMP | MODULE | EVENT | NAME1 | VALUE1 | NAME2 | VALUE2 | NAME3 | VALUE3 | NAME4 | VALUE4 | NAME5 | VALUE5 | NAME6 | VALUE6 | EXTRA_INFO | RS_SVR_IP | RS_SVR_PORT | +----------------------------+-------------+-------------------+-----------+--------+--------+--------+-------+--------+-------+--------+-------+--------+-------+--------+------------+----------------+-------------+ | 2023-08-17 15:56:02.023265 | backup_data | start_backup_data | tenant_id | 1002 | result | -9040 | | | | | | | | | | 11.xx.xx.xx | 4000 | | 2023-08-17 15:56:13.116237 | backup_data | start_backup_data | tenant_id | 1002 | result | -9040 | | | | | | | | | | 11.xx.xx.xx | 4000 | | 2023-08-17 15:56:38.050299 | backup_data | start_backup_data | tenant_id | 1002 | result | -9040 | | | | | | | | | | 11.xx.xx.xx | 4000 | | 2023-08-17 15:57:11.236784 | backup_data | start_backup_data | tenant_id | 1002 | result | -9040 | | | | | | | | | | 11.xx.xx.xx | 4000 | 4 rows in setクエリ結果では、特に以下の列の値に注意してください:
NAME1、VALUE1:tenant_idとその対応する値を表示します。NAME2、VALUE2:resultとその対応する値を表示します。RS_SVR_IP:Root Serviceが存在するマシンのIPアドレスです。
実際のクエリ結果に基づいて、
NAME2列のresultに対応するVALUE2の値が0でない場合は、次のステップに進んでエラー箇所を確認する必要があります。前のステップで取得した
RS_SVR_IPに基づいて、Root Serviceが存在するマシンにログインし、rootservice.logログファイルを検索してエラー箇所を確認します。Root Serviceが存在するマシンにログインします。
ログファイルがあるディレクトリに移動します。
cd /home/admin/oceanbase/log以下のコマンドを実行して、
ret=\resultのログを検索し、エラー箇所を見つけます。grep "ret=\result" rootservice.log* | grep "ob_backup_data_scheduler"ここで、
resultは前のステップでresultに対応するVALUE2の値に置き換える必要があります。以下はresultに対応する値が-9040の場合の例です:grep "ret=\-9040" rootservice.log* | grep "ob_backup_data_scheduler"検索したログ情報に基づいて、バックアップタスクの開始に失敗した原因が以下の場合は、予想どおりです:
データバックアップの宛先
data_backup_destが設定されていません。バックアップ宛先の設定方法の詳細については、バックアップ前の準備を参照してください。
ログアーカイブが有効になっていません。
ログアーカイブを有効にする方法の詳細については、アーカイブモードの有効化を参照してください。
テナントがバックアップ中です。
テナントの状態がNormalではありません。
その他の理由によりデータバックアップタスクの開始に失敗した場合は、検索したログエラー情報を取得した後、技術サポート担当者に連絡して支援を依頼してください。
質問2:データバックアップが特定の状態で終了しない
データバックアップが特定の状態で終了しない場合は、以下の手順でトラブルシューティングを行うことができます:
rootユーザーでクラスタのsysテナントにログインします。以下のステートメントを実行して、タスクが停止した状態を確認します。
SELECT * FROM oceanbase.CDB_OB_BACKUP_TASKS WHERE tenant_id = xxx;クエリ結果に基づき、特に
STATUS列の値に注目してください。この列はバックアップ状態を示しています。通常、データバックアップが停止して終了しない場合、BACKUP_META、BACKUP_DATAなどの状態が表示されます。STATUS列の値がBACKUP_METAまたはBACKUP_DATAの場合、次のステップを実行してさらに調査する必要があります。以下のステートメントを実行して、タスクの実行情報を取得します。
SELECT * FROM oceanbase.__all_virtual_backup_schedule_task WHERE tenant_id = xxx;クエリ結果の例は次のとおりです:
+-----------+--------+---------+-------+------+-----------------------------------+-------------------+-------------+------------------+------------------+------------------+ | tenant_id | job_id | task_id | ls_id | type | trace_id | destination | is_schedule | generate_ts | schedule_ts | executor_ts | +-----------+--------+---------+-------+------+-----------------------------------+-------------------+-------------+------------------+------------------+------------------+ | 1002 | 339 | 3 | 1001 | 0 | YB42C0A80C44-0005F637014C8DE6-0-0 | 192.xx.xx.xx:2882 | True | 1679378679020065 | 1679378679205546 | 1679378679302303 | +-----------+--------+---------+-------+------+-----------------------------------+-------------------+-------------+------------------+------------------+------------------+ 1 row in setクエリ結果に基づき、特に
destinationとtrace_id列の値に注目してください:trace_id:データバックアップタスクに対応するtrace_id。destination:データバックアップタスクを実行するマシンのIPアドレスとポート番号。
前のステップで取得した情報に基づいて、
destination列に表示されているマシンにログインし、以下のコマンドを実行してログを検索します。grep 'YB42C0A80C44-0005F637014C8DE6-0-0' observer.logここで、
YB42C0A80C44-0005F637014C8DE6-0-0は前のステップでクエリしたtrace_idの値です。注意
observer.logファイル内で関連ログをgrepで検索できない場合は、observer.logファイルが切り替わった可能性があります。その場合は、grep 'YB42C0A80C44-0005F637014C8DE6-0-0' observer.log.*を実行してください。検索したログのエラーメッセージを取得した後、技術サポート担当者に連絡して処理を依頼します。
質問3:バックアップタスクの実行に失敗
データバックアップを開始した後、ビューCDB_OB_BACKUP_JOB_HISTORYまたはDBA_OB_BACKUP_JOB_HISTORYを確認すると、クエリ結果が以下の図のようになり、対応するバックアップタスクのSTATUS列がFAILEDであることがわかります。これはバックアップタスクの実行に失敗したことを示します。
*************************** 1. row ***************************
TENANT_ID: 1004
JOB_ID: 8
INCARNATION: 1
BACKUP_SET_ID: 8
INITIATOR_TENANT_ID: 1
INITIATOR_JOB_ID: 10
EXECUTOR_TENANT_ID: 1004
PLUS_ARCHIVELOG: OFF
BACKUP_TYPE: INC
JOB_LEVEL: USER_TENANT
ENCRYPTION_MODE: NONE
PASSWD:
START_TIMESTAMP: 2023-04-27 12:41:27.451141
END_TIMESTAMP: 2022-04-27 12:42:24.352493
STATUS: FAILED
RESULT: 4016
COMMENT:(server)ls_id: 1002,addr: 11.xx.xx.xx:4004,module:BACKUP_DATA,result: -4016(Internal error),trace_id: YFA40BA2D90B-005FA487348F363-0-0
DESCRIPTION:
PATH:file:///data/nfs/backup/backup_1682565410121
1 row in set
ビューのCOMMENT列には、バックアップタスクに関連するいくつかの情報が表示されています:
(server):現在のバックアップタスクを実行しているマシンのタイプ。serverは現在のバックアップタスクを実行しているのが特定のOBServerノードであることを示し、rootserviceは現在のバックアップタスクを実行しているのがRoot Serviceが配置されているマシンであることを示します。addr: 11.xx.xx.xx:4004:現在のバックアップタスクを実行しているマシンのIPアドレスとポート番号。result: -4016(Internal error):現在のバックアップタスクが失敗したエラーコード情報。trace_id: YFA40BA2D90B-005FA487348F363-0-0:現在のバックアップタスクに対応するtrace_id。
COMMENT列の情報を使用してログを検索し、さらに特定する手順は以下のとおりです:
addr: 11.xx.xx.xx:4004に対応するマシンにログインします。ログが保存されているディレクトリに移動します。
cd /home/admin/oceanbase/log以下のコマンドを実行して、ログを検索します。
このマシンがOBServerノードの場合、以下のコマンドを実行して、タスクの時間点付近のログを検索します。
grep 'YFA40BA2D90B-005FA487348F363-0-0' observer.log注意
observer.logファイルで関連ログをgrepできない場合は、observer.logファイルが切り替わった可能性があります。grep 'YFA40BA2D90B-005FA487348F363-0-0' observer.log.*と入力してみてください。このマシンがROOT Serviceの場合、以下のコマンドを実行して、タスクの時間点付近のログを検索します。
grep 'YFA40BA2D90B-005FA487348F363-0-0' rootservice.log注意
rootservice.logファイルで関連ログをgrepできない場合は、rootservice.logファイルが切り替わった可能性があります。grep 'YFA40BA2D90B-005FA487348F363-0-0' rootservice.log.*と入力してみてください。
検索したログのエラーメッセージを取得した後、テクニカルサポート担当者に連絡して、対処を依頼します。
よくあるエラーコードとトラブルシューティング方法
-4012 および -9086
-4012 および -9086 のエラーコードが発生した場合は、本記事で紹介されているトラブルシューティング方法に従ってエラーログを確認することができます。例えば、検索したログは次のとおりです:
[2023-05-19 13:23:25.238790] WDIAG [STORAGE] advance_checkpoint_by_flush (ob_backup_task.cpp:141) [8999][T1004_BACKUP][T1004][Y509E645869DC-0005FC029426456E-0-0] [lt=26][errcode=0] clog checkpoint scn has not passed start scn, retry again(i=0, tenant_id=1004, ls_id={id:1}, clog_checkpoint_scn={val:1684465461355302830}, start_scn={val:1684465461355303000}, need_advance_checkpoint=true, advance_checkpoint_interval=2000000, cur_ts=1684473805238742, last_advance_checkpoint_ts=1684472010015535)
ログ情報から、このようなエラーは通常チェックポイントの進行が遅いことに関連していることがわかります。フリーズダンプに問題がないか確認する必要があります。また、フィジカル・スタンバイ・データベースでデータバックアップを実行している場合は、スタンバイデータベースのログ同期が停止していないかどうかも考慮する必要があります。
-4554
-4554 のエラーコードが発生した場合、Root Serviceがタスクの状態を検出した際に対応するタスクがタイムアウトしたことを示します。
タスクがタイムアウトする可能性のある理由は以下のとおりです:
検索したエラーログが
backup dest server is not existまたはserver status may not active or in serviceである場合、対応するOBServerノードにアクセスできません。上記のログ情報がない場合、Root ServiceがOBServerノードから返されたバックアップ結果情報を受信していない可能性があります。ログ内の
ls_taskに記録されているtrace_idを使用して対応するOBServerノードにログインし、ログを検索して確認することができます。