1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

MySQL NDB Cluster 9.xの変更点を整理

1
Posted at

MySQL NDB Cluster 9.xでは、可観測性、障害時の挙動、NDB APIワークロード、リストア、管理操作が改善されています。
本記事では、公式ドキュメントとリリースノートを基に、変更点を整理します。

機能は9.x系列の複数のInnovationリリースとLTSリリースにまたがります。
導入前には、必ず対象バージョンのリリースノートで提供状況を確認してください。

MySQL NDB Cluster 9.7 Reference Manual
MySQL NDB Cluster 9.7 Release Notes

ノードログのタイムスタンプがマイクロ秒精度になる

NDB 9.4以降、データノードと管理ノードのログは、既定でUTCかつマイクロ秒精度のタイムスタンプを出力します。
短時間に連続して発生するノードイベントを、アプリケーションログや他ノードのログと突き合わせやすくなります。

たとえば、ノード離脱の直前に発生したAPI切断、遅延したハートビート、Redoログの警告を、同じ時間範囲で確認できます。
従来の秒精度へ戻す必要がある場合は、--ndb-log-timestamps=LEGACY を使用します。
Changes in MySQL NDB Cluster 9.4.0
NDB Cluster Log Messages

データノード自身のログから障害を追跡しやすくなる

ノードの参加と離脱、API切断、起動、再起動などのイベントについて、データノードのローカルログに残る情報が増えました。
管理ノードとの接続にも問題が起きている障害では、データノード側のログが有力な調査材料になります。

ノードグループIDも、ノード起動時とノードグループの変更時にログへ記録されます。
障害がどのノードグループに影響したかを、ログから素早く確認できます。
Changes in MySQL NDB Cluster 9.5.0
Changes in MySQL NDB Cluster 9.7.2

Redoログの逼迫をログから区別する

Redoログバッファ不足、Redoログ領域不足、ファイル変更の問題、Redo I/O過負荷などの状態がログに記録されます。
これにより、アプリケーション処理が待機列に積まれている状態と、処理を中止すべき状態を区別しやすくなります。

たとえば、アプリケーション遅延と同じ時刻にRedo I/O過負荷のログが出ていれば、ストレージやRedoログ設定を調査する根拠になります。
ログだけで原因を断定せず、ワークロード、ディスクI/O、データノードの状態も併せて確認します。
Changes in MySQL NDB Cluster 9.5.0

ndbinfoでハートビートと通信遅延を確認する

ndbinfo は、NDB Clusterのノード状態、リソース使用量、進行中の操作をSQLで確認するための情報データベースです。
9.xでは、transporterとハートビートに関する情報が強化され、ノードを停止と判定する前の通信遅延を調べやすくなっています。

まずは利用可能な情報を確認します。

SHOW TABLES FROM ndbinfo;

通信遅延が増えている場合は、ネットワーク、CPU飽和、ノード間の負荷偏りなどを確認します。
ndbinfo の情報はオンデマンドで生成され、一貫した単一時点のスナップショットではない点に注意が必要です。
ndbinfo: The NDB Cluster Information Database

同一行を繰り返し更新するトランザクションを制御する

MaxRowVersionsPerTransaction は、1つのトランザクション内で同じ行を繰り返し更新するワークロードを対象としたデータノードのパラメータです。
行バージョンの連鎖が長くなり、コミットまたはロールバック時のクリーンアップ処理が肥大化することを抑えます。
上限に達した場合、NDBは無制限に後処理を増やす代わりに明示的なエラーを返します。
値は一律には決められないため、対象トランザクションの更新回数と失敗時の再試行設計を確認して設定します。
Defining NDB Cluster Data Nodes

NDB APIのイベント処理とBLOB処理を安定化する

NdbEventOperation には、イベント購読の開始と停止時に利用できる制御が追加されています。
移行中のepochに含まれる不完全なイベントを扱いやすくし、バイナリログやイベントコンシューマーの安定性向上につながります。
BLOB列を含む結合では、BLOBの close() と unlock() に伴う不要な往復が削減されます。
NDB APIを直接利用するアプリケーションでは、イベント購読とBLOBアクセスを含む負荷試験を実施し、更新前後のレイテンシを比較します。
NdbEventOperation Class

ndb_restoreで大規模リストアを調整する

ndb_restore では、並列度、ログレコードの適用、読み取りバッファなどを調整できます。
複数ファイルセットを含むバックアップでは、データノードの負荷を確認しながら --parallelism を増やすことで、リストアの並列処理を高められます。
外部キーをインデックス再構築で再有効化する制御されたリストアでは、既存復元行の整合性検査を省略する --skip-fk-checks を利用できます。
このオプションは検査を省略するため、利用前にバックアップの整合性と復元先の前提条件を確認します。

ndb_restore \
  --backupid 123 \
  --rebuild-indexes \
  --skip-fk-checks \
  --parallelism=256

--parallelism を大きくするとクラスタへの負荷も増えるため、段階的に調整します。
ndb_restore — Restore an NDB Cluster Backup

ダウングレード判断とノードID割り当てを安全に扱う

NDBスキーマに保存された埋め込みメタデータを確認できるため、新しいMySQL Serverで作成された辞書情報を含むテーブルを把握しやすくなります。
ダウングレードの可否を判断するときは、対象テーブルと互換性を事前に確認します。
クラウドやサービスメッシュでは、接続元アドレスと設定済みホスト名が一致せず、ノードID割り当てが失敗する場合があります。
--skip-nodeid-address-check はホスト名照合だけを無効化し、従来の --no-nodeid-checks より限定的にプロキシ経由の接続を許可します。
Changes in MySQL NDB Cluster 9.7.2

運用で確認したいポイント

NDB Cluster 9.xの変更は、性能を上げるための設定項目だけではありません。
ログ、ndbinfo、NDB API、リストア、ノード管理の各所で、障害時に必要な情報を残し、処理を制御しやすくする改善が中心です。
導入時には、次の順序で確認するとよいでしょう。

  • 対象バージョンに必要な機能が含まれるかをリリースノートで確認する。
  • ノードログと管理ノードログを集約し、マイクロ秒精度の時刻で検索できるようにする。
  • ndbinfo を利用した平常時のベースラインを取得する。
  • ndb_restore の並列度と外部キー再構築を、検証環境で試す。
  • NDB APIを使うアプリケーションでは、イベント購読、BLOB処理、タイムアウト時の挙動を回帰試験する。

参考資料

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?