本番データベースを管理している場合、データベースを本番サーバー以外の別のサーバーに複製しなければならなかった可能性が高くなります。クローンを作成する基本的な方法は、最近のバックアップから別のデータベースサーバーにデータベースを復元することです。もう1つの方法は、実行中にソースデータベースから複製することです。この場合、元のデータベースがクローン作成手順の影響を受けないことが重要です。
データベースのクローンを作成する必要があるのはなぜですか？
クローンデータベースクラスターは、さまざまなシナリオで役立ちます。
- データベースで破壊的な操作を実行しながら、テスト環境の安全性でクローン化された本番クラスターのトラブルシューティングを行います。
- 複製されたデータベースのパッチ/アップグレードテスト。本番クラスターに適用する前に、アップグレードプロセスを検証します。
- クローンクラスターを使用して、本番クラスターのバックアップとリカバリを検証します。
- ライブの本番クラスターにデプロイする前に、クローン化された本番クラスターで新しいアプリケーションを検証またはテストします。
- たとえば、データベースのコンテンツを変更してはならない四半期または年末までに、監査または情報コンプライアンス要件のためにデータベースのクローンをすばやく作成します。
- レポート生成中のデータ変更を回避するために、レポートデータベースを定期的に作成できます。
- データベースを新しいサーバー、新しい展開環境、または新しいデータセンターに移行します。
データベースインフラストラクチャをクラウドで実行する場合、ホスト（共有または専用の仮想マシン）を所有するコストは、データセンターのスペースを借りたり、物理サーバーを所有したりする従来の方法と比較して大幅に低くなります。さらに、ほとんどのクラウド展開は、プロバイダーAPI、クライアントソフトウェア、およびスクリプトを介して簡単に自動化できます。したがって、クラスターのクローンを作成することは、たとえば、開発からステージング、本番、またはその逆に、デプロイメント環境を複製する一般的な方法です。
この機能が市場の誰からも提供されているのを見たことがないので、ClusterControlでどのように機能するかを紹介できることを光栄に思います。
MySQLGaleraクラスターのクローン作成
ClusterControlの優れた機能の1つは、既存のMySQL Galeraクラスターのクローンをすばやく作成できるため、他のクラスターにデータセットの正確なコピーを作成できることです。 ClusterControlは、既存のクラスターをロックしたりダウンタイムを発生させたりすることなく、オンラインでクローン作成操作を実行します。同期が完了した後、両方のクラスターが互いに独立していることを除けば、クラスターのスケールアウト操作に似ています。クローン化されたクラスターは、必ずしも既存のクラスターと同じクラスターサイズである必要はありません。 1ノードのクラスターから始めて、後の段階でより多くのデータベースノードでスケールアウトすることができます。
この例では、「ステージング」というクラスターがあり、「プロダクション」という別のクラスターとしてクローンを作成します。前提となるのは、間もなく本番環境に移行する必要のあるデータがすでに格納されているステージングクラスターです。本番クラスターは、本番仕様を備えた別の3つのノードで構成されています。
次の図は、達成したいことの最終的なアーキテクチャをまとめたものです。
最初に行うことは、ClusterControlサーバーからパスワードなしのSSHを設定することです。本番サーバーに。 ClusterControlサーバーで、次を実行します。
$ whoami
root
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]プロンプトが表示されたら、ターゲットサーバーのルートパスワードを入力します。
ClusterControlデータベースクラスターリストから、[クラスターアクション]ボタンをクリックし、[クラスターのクローン化]を選択します。次のウィザードが表示されます：
新しいクラスターのIPアドレスまたはホスト名を指定し、指定されたホストの横にあるすべての緑色のチェックマークアイコン。緑のアイコンは、ClusterControlがパスワードなしのSSHを介してホストに接続できることを意味します。 [クラスターのクローン]ボタンをクリックして、展開を開始します。
- 1つのノードで構成される新しいクラスターを作成します。
- SSTを介して新しい1ノードクラスターを同期します。ドナーはソースサーバーの1つです。
- クローン化されたクラスターのドナーがクラスターと同期された後、残りの新しいノードがクラスターに参加します。
完了すると、展開ジョブが完了すると、新しいMySQLGaleraクラスターがClusterControlクラスターダッシュボードの下に一覧表示されます。
クラスターの複製はデータベースサーバーのみを複製し、クラスターのスタック全体は複製しないことに注意してください。つまり、ロードバランサー、仮想IPアドレス、Galeraアービトレーター、非同期スレーブなど、クラスターに関連する他のサポートコンポーネントは、ClusterControlによってクローン化されません。それでも、既存のデータベースインフラストラクチャの正確なコピーとして複製する場合は、データベースの複製操作の完了後にこれらのコンポーネントを個別に展開することで、ClusterControlを使用して複製できます。
ClusterControlが提供するもう1つの同様の機能は、「バックアップからクラスターを作成する」です。この機能は、ClusterControl 1.7.1で導入されました。特に、既存のバックアップから新しいクラスターを作成できるGaleraクラスターおよびPostgreSQLクラスター向けです。クラスタのクローン作成とは対照的に、この操作ではソースクラスタに追加の負荷が発生せず、クローン作成されたクラスタのトレードオフはソースクラスタとしての現在の状態にはなりません。
バックアップからクラスターを作成するには、動作するバックアップを作成する必要があります。 Galera Clusterの場合、すべてのバックアップ方法がサポートされていますが、PostgreSQLの場合、新しいクラスターのデプロイメントではpgbackrestのみがサポートされていません。 ClusterControlから、ClusterControl-> Backups->CreateBackupでバックアップを簡単に作成またはスケジュールできます。作成されたバックアップのリストから、[バックアップの復元]をクリックし、リストからバックアップを選択して、復元オプションから[バックアップからクラスターを作成]を選択します。
この例では、新しいPostgreSQLストリーミングレプリケーションクラスターをデプロイしますステージング環境の場合、本番クラスターにある既存のバックアップに基づきます。次の図は、最終的なアーキテクチャを示しています。
最初に行うことは、ClusterControlサーバーからパスワードなしのSSHを設定することです。本番サーバーに。 ClusterControlサーバーで、次を実行します。
$ whoami
root
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]バックアップからクラスターを作成を選択すると、ClusterControlはデプロイメントウィザードダイアログを開き、新しいクラスターのセットアップを支援します。
選択したバックアップから、新しいPostgreSQLストリーミングレプリケーションインスタンスが作成されます。新しいクラスターのベースデータセットとして使用されます。選択したバックアップは、新しいクラスターのノードからアクセスできるか、ClusterControlホストに保存されている必要があります。
[続行]をクリックすると、標準のデータベースクラスター展開ウィザードが開きます。
このクラスターのroot/adminユーザーパスワードはバックアップに含まれているPostgreSQLのadmin/rootパスワード。それに応じて構成ウィザードに従い、ClusterControlは次の順序で展開を実行します。
- 必要なソフトウェアと依存関係をすべてのPostgreSQLノードにインストールします。
- 最初のノードを開始します。
- 最初のノードでバックアップをストリーミングおよび復元します。
- 残りのノードを構成して追加します。
完了すると、デプロイメントジョブが完了すると、新しいPostgreSQLレプリケーションクラスターがClusterControlクラスターダッシュボードの下に一覧表示されます。