GaussDB T分散クラスタデータベースの日常的なメンテナンスは知っておく必要があります

[[315820]]

「落とし穴なしで GaussDB T 分散クラスターをインストールおよび展開する方法」に従って、GaussDB T の日常的なメンテナンス タスクを開始します。新しい 1 日は、ホストの電源をオンにすることから始まります。仮想マシンの電源を入れた後、前回インストールしたデータベースが自動的に起動しないことがわかりました。すべてのノードによって開始された唯一の関連プロセスは cm_agent プロセスでした。

この時点で、まず ETCD を起動する必要があります。

OK、etcd は正常に起動しました。次に、クラスター全体を起動します。

クラスターは正常に起動されました。

その後、ETCD とクラスターを自動的にプルアップして、自己起動に参加させます。さて、冒頭の話題に戻り、日々のメンテナンスを始めましょう。

1. クラスターステータスチェック

もちろん、最初に行うことは、クラスター内の各ノードのリソース ステータスを確認することです。何を見るべきかについては、写真を使って重要なポイントを理解しましょう。

1. CM、CN、DN、ETCD など、各ノード リソースがオンラインかどうかを確認します。オンラインになっていない場合は、さらに調査する必要があります。

2. 各ノードをチェックし、昨日と比較して、ノードの切り替えが行われているかどうかを確認します。ノードに対応するホストを確認するだけです。もしそうなら、それは異常であり、原因をさらに調査する必要があります。

2. ホストのリソース使用状況を確認する（すべてのホスト）

1. ホストディレクトリの使用

df -h

2. CPU、メモリ、IOの使用状況

これを確認する方法はたくさんあります。ここでは、vmstat、iostat、free を使用します。下記の赤枠で囲まれた位置に特にご注意ください。

説明: id 列は CPU アイドル率を表し、free 列はページ単位の空きメモリを表します。

説明: rMB/s と wMB/s は 1 秒あたりの読み取りと書き込みを指し、%util は統計時間中のすべての IO 処理時間を合計統計時間で割った値を指します。たとえば、統計間隔が 1 秒で、デバイスが 0.8 秒間 IO を処理し、0.2 秒間アイドル状態の場合、デバイスの %util = 0.8/1 = 80% となり、このパラメーターはデバイスのビジー状態を示します。このパラメータが 100% の場合、デバイスがほぼ全容量で動作していることを意味します (もちろん、複数のディスクがある場合、%util が 100% であっても、ディスクの同時実行機能により、ディスク使用率が必ずしもボトルネックに達するとは限りません)。

説明: 無料かつ利用可能であることに焦点を当てます。

注: このセクションのリソース チェックは、ベースラインと比較する必要があります。差異が大きすぎる場合は、さらに調査する必要があります。

3. 各ノードのデータベースステータスを確認する

CN と DN が両方ともオープン状態であることを確認します。バックアップ DN がマウント状態であることに注意してください。

4. テーブルスペースの使用状況チェック

使用方法を確認する前に、まずはテーブルスペースの作成方法について説明します。

1. cnに接続する

zsql omm/[email protected]:8000 –q

2. テーブルスペースを作成する

テーブルスペース tbs_test1、データファイル 'tbs_test1'、サイズ 100m の SHARD を作成します。

注意: 表領域を作成するときに、SHARD キーワードを使用すると、表領域作成ステートメントが CN ノードと DN ノードに自動的に送信され、相対パスの使用のみがサポートされます。 SHARD キーワードを使用しない場合は、絶対パスを使用できます。同時に、この表領域の下にテーブルを正常に作成する前に、すべての CN およびプライマリ DN ノードにこの表領域を作成する必要があります。

3. データファイルを確認します。対応する表領域とデータ ファイルが CN と DN に作成されていることがわかります。

注: プライマリ DN に接続するには、次のコマンドを使用します。

zsql / sysdbaとして -D /gaussdb/data/data_dn1 -q

4. テーブルスペースの使用状況を確認する

300行目を設定する
セットページ 2000
タイミングを合わせる 
 a25の列 tablespace_name
 a15の列 sum_GB
 a15の列 free_GB
 a15の列 use_precent
 b.tablespace_nameを選択し、
       round(合計(b.bytes) / 1024 / 1024 / 1024, 0)合計GB,
       round(合計(nvl(a.bytes, 0)) / 1024 / 1024 / 1024, 0) free_GB,
       round((合計(b.bytes) -合計(nvl(a.bytes, 0))) /合計(b.bytes), 4) * 100 use_precent,
カウント（*）
 from ( select tablespace_name, file_id, sum (bytes) バイト
adm_free_spaceより
グループ テーブルスペース名、ファイルIDによる）a、
       adm_data_files b
ここで、 a.file_id(+) = b.file_id
そして、 a.tablespace_name(+) = b.tablespace_name
グループ  b.tablespace_nameより
round(( sum (b.bytes) - sum (nvl(a.bytes, 0))) / sum (b.bytes), 4) * 100 >= 0 となる
注文  4 descにより;

注: テーブル スペースの使用状況チェックは、すべてのプライマリ CN とプライマリ DN で実行する必要があります。

5. 異常待機イベントチェック

col イベント フォーム a38

DV_SESSIONS から LOCK_WAIT = 'Y' の場合にイベント、count(*) を選択し、イベントごとにグループ化し、順序を 2 で並べ替えます。

注: すべてのプライマリ DN をチェックして、異常な待機イベントがあるかどうかを確認します。

図に示すように、TX 待機があります。次の SQL を使用して、ロック ソースが何を実行しているかを確認できます。

 SID、シリアル番号、ユーザー名、CURR_SCHEMA、クライアントIP、クライアントポート、OSユーザー、マシン、プログラムを選択します。
 dv_sessionsからのSTATUS、LOCK_WAIT、EVENT、MODULE、CURRENT_SQL
 where sid in ( select WAIT_SID from v$session where event like   '%TX%' ); 

セッションステータスが非アクティブで、アプリケーションが接続されている場合は、アプリケーションに接続して正常かどうかを確認できます。強制終了できる場合は、ALTER SYSTEM KILL SESSION 'SID,SERIAL#'; を実行できます。セッションを終了します。

6. ログチェック

データベースの運用中は、データベースの日常的なメンテナンスのために、大量の操作、監査、デバッグ、アラームなどのログが生成されます。データベース障害が発生した場合、これらのログを使用して問題を特定し、データベースを復元できます。

以下に、よく使用されるログの種類を紹介します。

1. 操作ログ

GaussDB T データベースの実行情報を出力します。データベースに障害が発生した場合は、zengine.rlog を確認してください。

ログ ディレクトリ: デフォルトは、" $GSDB_DATA/log/run/zengine.rlog " または、パラメータ log_home に対応するパスの run サブディレクトリです。パスを変更する場合は、再起動して変更を有効にしてください。

CN ノード:

DN ノード:

実行ログを次のように確認します。

2. スロークエリログ

しきい値 (LONGSQL_TIMEOUT パラメータによって制御) を超えた GaussDB 100 データベース実行時間に関する SQL 情報を zengine.lsql ログ ファイルに出力します。

ログディレクトリ: デフォルトは「$GSDB_DATA/log/longsql/zengine.lsql」です。

3. アラームログ

GaussDB 100 データベース操作のアラーム情報を出力します。アラーム情報については、zenith_alarm.log を参照してください。

ログ ディレクトリ: "$GSDB_DATA/log/zenith_alarm.log"。

4. 操作ログ

ZSQL ツールを使用して、GaussDB 100 データベース上のユーザーの操作情報を記録します。操作ログを知りたい場合は、zsql.olog を確認してください。

ログ ディレクトリ: "$GSDB_DATA/log/oper/zsql.olog"。

5. TRACEログ

データベース セッションのデッドロックに関する情報を記録します。セッションデッドロック情報を表示するには、zengine_00003_xxxxxx.trc を参照してください。

ログディレクトリ: "$GSDB_DATA/trc/zengine_00003_xxxxxx.trc"。

一般的なエラーコード:

GS-00716: セッション (%u) で %s デッドロックが見つかりました

エラーの原因: 同じデータ バッチが異なるセッションで同時に操作されたため、デッドロックが発生しました。

解決：

• トレース ログまたは実行ログを確認します (デッドロック ログの場所はデータベースのバージョンによって異なります)。
• デッドロックの種類、SQL ステートメントなど、ログに記録された特定の情報に基づいて、ビジネス ステートメントのトラブルシューティングを行います。

GS-00715: スナップショットが古くなっています。

エラーの原因: スナップショットが古すぎます。

解決：

• SQL を再実行します。
• 実行時間が長くコストのかかる SQL ステートメントを最適化または分割します。

GS-00713: 空き元に戻すページがありません

エラーの原因: UNDO テーブル スペースが不足しています。

解決：

• UNDO 表領域のサイズを増やします。
• UNDO を解放するには、大規模なトランザクションを強制終了します。

GS-00305: %s タイムアウト

エラー理由: ネットワーク API タイムアウト。

解決：

• ホストネットワークが正常であることを確認してください。

GS-00774：フェイルオーバー中、接続できません

エラーの原因: スタンバイ マシンがフェイルオーバーを実行しているときに、マスター マシンのログ送信スレッドがスタンバイ マシンに接続します。

解決：

• マスターを停止し、スタンバイ マシンがマスターになるまで待機してから、元のマスターをスタンバイに降格します。

GS-00839: フラッシュREDOファイル:%s、オフセット:%u、サイズ:%luに失敗しました

エラーの原因: REDO ログ ファイルの書き込み中にエラーが発生しました。これは通常、ファイル システムまたはディスクの問題によって発生します。

解決：

• オペレーティング システムまたはディスクを確認してください。

GaussDB T データベースのメンテナンスには、やるべき作業がたくさんあります。上記の日常的なタスクに加えて、セッション接続の失敗、バッファ フラッシュの失敗、CN/DN ノードの異常な状態、CM サーバー ノードの異常な状態、プライマリ DN ノードとスタンバイ DN ノード間のログ同期の過度の遅延など、確認すべき問題もあります。それらの多くは、データベース マネージャーを使用するか、独自に開発したスクリプトを使用してアラームを実装することで分析および処理できます。

メンテナンスの目的は、システムをより安定させることです。メンテナンス作業が単純であればあるほど、メンテナンス担当者がミスをする可能性は低くなります。私たちの目標は、メンテナンス作業を可能な限りスクリプト化し、ツール化し、自動化して、人員をより価値のある作業に充てられるようにすることです。これからの道のりは長く困難ですが、一緒に頑張りましょう！