API Gateway: マルチノードクラスターでのレプリケーション再初期化
search cancel

API Gateway: マルチノードクラスターでのレプリケーション再初期化

book

Article ID: 275072

calendar_today

Updated On:

Products

CA API Gateway

Issue/Introduction

この手順では、メンテナンス期間中にマルチノード クラスターで失敗したレプリケーションを再初期化する方法について説明します。

CA API Gateway は、MySQL レプリケーションを使用して、1 つのGateway アプライアンスまたはデータベース サーバが使用不能になったり、機能が低下したりした場合に、データベース フェイルオーバーと可用性を提供します。MySQL レプリケーションでは、データベース オブジェクトの複製コピーが 1 つ以上の場所に確実に保持されます。Gatewayは、マルチノード環境でマスター/マスター実装を使用して、あるホストに対するデータベースの変更が他のデータベース ホストに確実にレプリケートされるようにします。

MySQL レプリケーションは、他のデータベース ノードが利用できない場合に、それ自体を修復できます。レプリケーションは、クラスター内のノードで正常なシャットダウン、MySQL サーバーのシャットダウン、またはネットワーク停止が発生した後、自動的に修復できます。データ整合性エラーが発生すると、レプリケーションは失敗します。

ローカル MySQL データベースに対して SHOW SLAVE STATUS クエリを実行すると、次のデータが表示される場合があります。

Slave_IO_Running: No 
Slave_SQL_Running: No 

次のログ エントリがゲートウェイ ログ ファイルに存在する場合があります。

2380 WARNING "Error accessing host/database 
2381 WARNING "Replication failing for host/database 

 

Environment

API Gateway 全バージョン

Cause

MySQL レプリケーションはさまざまな理由で中断する可能性がありますが、これについてはこの KB 記事の範囲外です。

Resolution

重要な注意事項:

  • 以下の処理はメンテナンス期間中に実行することを強くお勧めします。このプロセス中は API Gateway の「ssg」サービスを無効にする必要があります。
  • 以下の処理では、プライマリ ノードに最も正確な最新のデータベースが含まれていることを前提としています。最新のデータベースがプライマリ ノードではなくセカンダリ ノードにある場合は、調整が必要になります。
  • ローカル Gateway データベースに(通常 500,000 を超える)大量の監査データが存在する場合、以下の処理は長時間のダウンタイムが発生する可能性があります。この手順の前に、次の記事に従って監査記録をパージすることをお勧めします。
    • KB 42833 - Removing audit records from the Gateway database in a multi-node cluster without downtime

Gateway 10.x および 11.x の処理

マルチノード クラスタでレプリケーションを再初期化するには、Gateway アプライアンスで次の手順を実行する必要があります。

1. プライマリ/セカンダリおよびすべての処理中のノードで API Gateway 'ssg' サービスを停止します: service ssg stop

2. 予防措置として、まずプライマリ ノード上のデータベースをバックアップします: mysqldump --all-databases --set-gtid-purged=OFF | gzip > ~/all_databases_`date '+%Y%m%d_%T'`.sql.gz

  • 新しく作成した SQL ファイルの最終行に "-- Dump completed <date-time>" が含まれていることを確認してください。
  • データベースを復元する必要がある場合に備えて、ファイルを保存しておきます。
  • 仮想アプライアンスを最も簡単に復元するには、VM スナップショットを取得することも検討してください。

3. 両方のノードでスレーブ レプリケーションを停止します: mysqladmin stop-slave

以下の警告メッセージが表示された場合、次のコマンドで停止します: mysqladmin stop-replica

# mysqladmin stop-slave
WARNING: stop-slave is deprecated and will be removed in a future version. Use stop-replica instead.
Replication stopped

4. 両方のノードでマスター構成をリセットします: mysql -e "reset master"

5. 両方のノードでスレーブ構成をリセットします: mysql -e "reset slave; reset slave all"

6． セカンダリ ノードで create_slave.sh スクリプトを実行します: /opt/SecureSpan/Appliance/bin/create_slave.sh

次の点に留意して、スクリプトのプロンプトに従います。

  • プライマリ ノードの FQDN を指定します。
  • プロンプト "Do you want to clone a database from $Master (yes or no)?" に対して「yes」と入力します。

7． ステップ 6 が完了したら、セカンダリ ノードでマスター構成をもう一度リセットします: mysql -e "reset master"

8. プライマリ ノードで create_slave.sh スクリプトを実行します: /opt/SecureSpan/Appliance/bin/create_slave.sh

次の点に留意して、スクリプトのプロンプトに従います。

  • セカンダリ ノードの FQDN を指定します。
  • プロンプト "Do you want to clone a database from $Master (yes or no)?" に「no」と入力します。

9. プライマリ/セカンダリおよびすべての処理ノードでGateway 'ssg' サービスを開始します: service ssg start

10. 両方のノードのレプリケーションのステータスをクエリします: mysql -e "show slave status\G"

11. 両方のノードが次の行を返すことを確認します。

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0

この時点でレプリケーションが再初期化されています。上記の出力は、マスター/スレーブ関係が機能していることを示しています。

 

Powered by Wolken Software