現在、データベースを別のサーバー/データセンターに複製することは非常に一般的であり、場合によっては必須でもあります。データベースを完全に別の環境に複製する理由はいくつかあります。
- アップグレード（ハードウェア/ソフトウェア）要件。
- ディザスタリカバリ（DR）サイトで完全に同期された運用システムを維持し、いつでも引き継ぐことができます
- ジオロケーション要件の場合（データは特定の国にローカルに存在する必要があります）。
そして、このレプリケーションタスクを実行するにはさまざまな方法があります：
- バックアップ/復元 ：本番データベースをバックアップして新しいサーバー/環境に復元するのがこれを行うための古典的な方法ですが、データを最新の状態に保つことができず、待つ必要があるため、これは昔ながらの方法でもあります。最近のデータが必要な場合は、復元プロセスごとに。クラスタ（マスタースレーブ、マルチマスター）があり、それを再作成する場合は、最初のバックアップを復元してから、残りのノードを再作成する必要があります。これは、時間のかかる作業になる可能性があります。 >
- クローンクラスター ：前のものと似ていますが、バックアップと復元のプロセスは、1つの特定のデータベースサーバーだけでなく、クラスター全体に対して行われます。このようにして、同じタスクでクラスター全体のクローンを作成でき、残りのノードを手動で再作成する必要はありません。この方法には、クローン間でデータを最新の状態に保つという問題があります。
- レプリケーション ：この方法にはバックアップ/復元オプションが含まれますが、最初の復元後、レプリケーションプロセスによってデータがマスターノードと同期されたままになります。このように、データベースクラスタがある場合は、バックアップを1つのノードに復元し、すべてのノードを手動で再作成する必要があります。
このブログでは、このタスクを改善するために前述の方法を組み合わせて使用できる新しいClusterControl1.7.4機能を紹介します。
2つのクラスター間のレプリケーションは、2つのデータセンターにまたがって実行するようにクラスターを拡張することと同じではありません。 2つのクラスター間でレプリケーションを設定する場合、実際には、自律的に動作できる2つの別個のシステムがあります。レプリケーションはそれらの同期を維持するために使用されるため、スレーブシステムは更新された状態になり、引き継ぐことができます。
ClusterControl 1.7.4から、実行中のソースクラスターを直接複製するか、ソースクラスターの最近のバックアップを使用して、新しいクラスターを作成できます。
クラスターのクローンを作成すると、データを受信するスレーブクラスター（SC）と、スレーブクラスターに変更を送信するマスタークラスター（MC）が作成されます。
ClusterControlは、次のクラスタータイプのクラスター間レプリケーションをサポートします。
- PerconaXtraDBClusterバージョン5.6.x以降。
- MariaDBGaleraClusterバージョン10.x以降。
- PostgreSQL9.6以降。
Percona XtraDB /MariaDBGaleraクラスターのクラスター間レプリケーション
MySQLベースのエンジンの場合、この機能を使用するにはGTIDが必要であり、マスタークラスターとスレーブクラスター間の非同期レプリケーションが使用されます。
このジョブのために現在のクラスターを準備するために、実行するアクションがいくつかあります。まず、現在のクラスターの少なくとも1つのノードで、バイナリログを有効にする必要があります。次に、データベースノードで構成されたバックアップユーザーをClusterControl構成ファイルに追加する必要があります。これは管理タスクに使用されます。これらのアクションはすべて、ClusterControlUIまたはClusterControlCLIを使用して実行できます。
これで、Percona XtraDB /MariaDBGaleraクラスター間レプリケーションを作成する準備が整いました。ジョブが終了すると、次のようになります。
- スレーブクラスター内の1つのノードは、マスタークラスター内の1つのノードから複製されます。
- スレーブクラスター内のすべてのノードは、デフォルトで読み取り専用になります。ノードの読み取り専用フラグを1つずつ無効にすることができます。
- アクティブ-アクティブクラスタリングは、エンジンが競合の検出または解決を提供しないため、アプリケーションがいずれかのクラスター上のばらばらのデータセットにのみアクセスしている場合にのみ推奨されます。
ClusterControlUIまたはClusterControlCLIの両方から、次のことができるようになります。
- レプリケーションスレーブをリセットします（ClusterControl CLI atmを使用してのみ実装されます）。
- バックアップユーザーの資格情報は、現在のクラスターと新しいクラスターの両方で同じである必要があります。
- スレーブクラスターの作成時に指定するMySQLルートパスワードは、マスタークラスターで使用されるルートパスワードと同じである必要があります。
- ClusterControl UIにはまだ実装されていないため、ClusterControlCLIからレプリケーションスレーブを「リセット」することのみが可能です。
PostgreSQLのクラスター間レプリケーション
ClusterControlクラスター間レプリケーションは、ストリーミングレプリケーションを使用するPostgreSQLでサポートされています。
要件として、ClusterControlロール'master'を持つPostgreSQLサーバーが必要であり、スレーブクラスターをセットアップするとき、管理者の資格情報はマスタークラスターと同一である必要があります。
これで、PostgreSQLクラスター間レプリケーションを作成する準備が整いました。ジョブが終了すると、次のようになります。
- スレーブクラスター内の1つのノードは、マスタークラスター内の1つのノードから複製されます。
ClusterControlUIまたはClusterControlCLIの両方から、次のことができるようになります。
- 管理者資格情報は、マスタークラスターとスレーブクラスターで同一である必要があります。
この新しいClusterControl機能を使用すると、クラスターレプリケーションを個別にまたは手動で作成するために各手順を実行する必要がなく、使用した結果、時間と労力を節約できます。試してみてください！