13.9 Cluster の運用

Cluster 操作は、ノード構成、役割、複製・データ状態を確認した後、検証済みの運用手順書で行います。 このページの点検順序で変更の影響と復旧経路を確認し、インストール済みバージョンの管理コマンドを 運用手順書に反映します。

構成要素

ノード数と配置は、可用性、スループット、障害ドメインの要件を基準に設計します。 固定のノード数やハードウェア仕様をすべての環境に当てはめないでください。

状態確認

変更前後に、Coordinator から見た全体のノード構成と、各ノードのプロセス・リソースを確認します。 状態文字列とコマンドオプションは、インストール済みツールのヘルプを基準にします。

machcoordinatoradmin --help
machclusterctl --help

• 予定したノードがすべて登録されているか。
• ノードの役割、ホスト、ポート、グループがデプロイ記録と一致するか。
• サービス・複製・scrap の状態が正常か。
• ノード間で CPU・メモリ・ディスク・ネットワークの偏りがあるか。
• Broker 経由の実際の接続とクエリが成功するか。

接続と設定のエクスポート

machclusterctl connect では対象 Broker とネイティブポートを明示し、CURRENT_DATABASE() と サンプルクエリを確認します。設定のエクスポートにはホスト・ポート・パス・運用情報が含まれるため、 アクセスを制限し、インポート前に差分を確認します。

ノードの起動と停止

ノード制御の前に次を確認します。

1. 対象ノード名・別名・ホスト・役割
2. クライアント接続と進行中のクエリ・Appender
3. Warehouse グループの冗長性とデータ状態
4. ノード停止中に残る処理容量
5. 起動・停止順序とロールバック
6. メンテナンス後の正常性判定基準

強制停止は正常停止が繰り返し失敗し、データと復旧への影響を判断した場合だけ使用します。 単なるタイムアウトに対して直ちに kill しないでください。

Cluster 全体の制御と destroy

全体の起動・停止では、Coordinator、Deployer、Broker、Warehouse、Lookup の依存順序を 現行リリースの運用手順で確認します。destroy はノード構成とデータを削除し得る破壊的操作です。

• 似た名前の別クラスターでないことを確認。
• 最新バックアップとリストアの検証。
• サービス所有者の承認とクライアントの遮断。
• 外部 DBS_PATH を含む削除範囲の確認。
• ロールバックできない範囲の明示。
• 実行後に各ホストの残存プロセスとパスを確認。

通常の状態復旧に destroy を使用しないでください。

ノードの追加と削除

追加前にパッケージ、バージョン、ポート、パス、ファイルシステム、ネットワークを確認します。 削除前にはデータの冗長性と移行完了、対象ノードを参照する別名・グループ・監視を確認します。 ノードの remove はホームとデータパスを削除する場合があるため、正確な範囲をヘルプと検証環境で確認します。

状態変更

Broker の無効化、Warehouse グループの読み取り専用化、ノードの scrap は目的が異なります。 問題のあるノードを隠すために状態を任意変更してはいけません。

Warehouse の復旧

1. 障害時刻と最初のエラーを保存します。
2. プロセス、ディスク、ネットワーク、複製状態を確認します。
3. 残存ノードの冗長性とサービス影響を評価します。
4. 再起動、reattach、rebuild から対応する経路を選びます。
5. 復旧の進捗とエラーを監視します。
6. 完了後にノード別の行数・時間範囲とクエリ結果を比較します。

データ破損を確認せず、ノードを normal に強制変更しないでください。

制約とチェックリスト

Edition 別の SQL、ROLLUP、バックアップ、ALTER SYSTEM の対応は サポート範囲を確認してください。

• 全ノードとクライアント SDK のリリースが互換か。
• メンテナンス中に許可する読み書きの範囲が定義されているか。
• バックアップ・リストアとノード復旧の訓練を完了したか。
• ホスト・ポート・パスを2名で相互確認したか。
• 監視と通知が新しいノード構成を反映しているか。
• 変更後に Broker 接続、クエリ、Append、メタデータを検証したか。