sql >> データベース >  >> NoSQL >> MongoDB

ClusterControlをバックアップおよび復元する方法

    ClusterControl 1.7.1では、ClusterControlサーバーをバックアップし、それを（管理対象データベースに関するメタデータとともに）別のサーバーに復元できる新機能が導入されました。 ClusterControlアプリケーションとそのすべての構成データをバックアップします。 ClusterControlを新しいサーバーに移行するのは以前は面倒でしたが、今はもう苦労していません。

    このブログ投稿では、この新機能について説明しています。

    ClusterControlをあるサーバーから別のサーバーに移行し、すべての構成と設定を保持します。

    また、クラスターの管理を1つのClusterControlインスタンスから別のインスタンスに移す方法も示します。

    このアーキテクチャの例は、2つの本番クラスターから始まりました（下のスクリーンショットに示されています）：

    • クラスターID1：3つのGaleraノード（PXC）+1つのHAProxy+1つのProxySQL（5ノード）
    • クラスターID2：1つのMySQLマスター+2つのMySQLスレーブ+1つのProxySQL（4ノード）

    はじめに

    ClusterControl CLI（s9s）は、ClusterControlプラットフォームを使用してデータベースクラスターを操作、制御、および管理するためのコマンドラインインターフェイスツールです。バージョン1.4.1以降、インストーラスクリプトはこのパッケージをClusterControlノードに自動的にインストールします。

    「s9sbackup」コマンドで導入された基本的に4つの新しいオプションがあり、これらを使用して目的を達成できます。

    ）からコントローラー全体を復元します
    フラグ 説明
    -save-controller コントローラーの状態をtarballに保存します。
    -restore-controller 以前に作成されたtarball（--save-controllerを使用して作成された
    -save-cluster-info コントローラーが1つのクラスターについて持っている情報を保存します。
    -restore-cluster-info 以前に作成されたアーカイブファイルから、コントローラーがクラスターに関して持っている情報を復元します。

    このブログ投稿では、これらのオプションの利用方法に関するユースケースの例を取り上げます。現在、リリース候補の段階にあり、ClusterControlCLIツールを介してのみ利用できます。

    ClusterControlのバックアップ

    これを行うには、ClusterControlサーバーが少なくともv1.7.1以降である必要があります。 ClusterControlコントローラーをバックアップするには、rootユーザーとして（またはsudoを使用して）ClusterControlノードで次のコマンドを実行するだけです。

    $ s9s backup \
--save-controller \
--backup-directory=$HOME/ccbackup \
--output-file=controller.tar.gz \
--log

    --output-fileは、ファイル名または物理パス（--backup-directoryフラグを省略したい場合）である必要があり、ファイルは事前に存在していてはなりません。 ClusterControlは、出力ファイルがすでに存在する場合、それを置き換えません。 --logを指定すると、ジョブが実行され、ターミナルにジョブログが表示されるまで待機します。同じログには、ClusterControlUIのActivity-> Jobs-> Save Controllerからアクセスできます。 ：

    「コントローラーの保存」ジョブは、基本的に次の手順を実行します。

    1. コントローラー構成を取得してJSONにエクスポートします
    2. CMONデータベースをMySQLダンプファイルとしてエクスポート
    3. すべてのデータベースクラスターの場合：
      1. クラスター構成を取得してJSONにエクスポートします

    出力では、見つかったジョブが N + 1であることがわかります。 クラスタ、たとえば、データベースクラスタが2つしかない場合でも、「保存する3つのクラスタが見つかりました」。これには、クラスターID 0が含まれます。これは、グローバルに初期化されたクラスターとしてClusterControlで特別な意味を持ちます。ただし、ClusterControl管理下のデータベースクラスタであるCmonClusterコンポーネントには属していません。

    ClusterControlを新しいClusterControlサーバーに復元する

    ClusterControlが新しいサーバーにすでにインストールされていると仮定して、新しいサーバーによって管理されるデータベースクラスターを移行したいと思います。次の図は、移行の演習を示しています。

    まず、バックアップを古いサーバーから新しいサーバーに転送します。

    $ scp $HOME/ccbackup/controller.tar.gz 192.168.0.190:~

    復元を実行する前に、新しいClusterControlサーバーからすべてのノードにパスワードなしのSSHを設定する必要があります。

    $ ssh-copy-id 192.168.0.11 #proxysql cluster 1
$ ssh-copy-id 192.168.0.12 #proxysql cluster 1
$ ssh-copy-id 192.168.0.21 #pxc cluster 1
$ ssh-copy-id 192.168.0.22 #pxc cluster 1
$ ssh-copy-id 192.168.0.23 #pxc cluster 1
$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2

    次に、新しいサーバーで復元を実行します。

    $ s9s backup \
--restore-controller \
--input-file=$HOME/controller.tar.gz \
--debug \
--log

    次に、[グローバル設定]->[クラスター登録]->[クラスターの同期]に移動して、UIでクラスターを同期する必要があります。 。次に、ClusterControlのメインダッシュボードに戻ると、次のように表示されます。

    パニックにならない。新しいClusterControlUIは、RPC APIトークンが正しくないため、監視および管理データを取得できません。それに応じて更新する必要があります。まず、それぞれのクラスターのrpc_key値を取得します。

    $ cat /etc/cmon.d/cmon_*.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=8fgkzdW8gAm2pL4L
cluster_id=2
rpc_key=tAnvKME53N1n8vCC

    UIで、[ここでRPCAPIトークンを変更する]行の[ここ]リンクをクリックします。次のダイアログが表示されます：

    それぞれのrpc_key値をテキストフィールドに貼り付け、[保存]をクリックします。次のクラスターに対して繰り返します。しばらく待つと、クラスターリストが自動的に更新されます。

    最後のステップは、新しいClusterControlIPアドレスの変更に対するMySQLcmonユーザー権限192.168.0.190を修正することです。 PXCノードの1つにログインし、以下を実行します。

    $ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

    **を/etc/cmon.cnf内のmysql_password値と同じcmonMySQLパスワードに置き換えます。 2番目のクラスターであるMySQLレプリケーションで同じ手順を繰り返しますが、マスターノードで1回だけ実行します。

    特権が設定されると、古いものと同様に、クラスターリストが緑色で表示されます。

    別のClusterControlインスタンスとの競合状態を回避するために、デフォルトでは、ClusterControlはクラスターの自動回復を無効にします（「クラスター」という単語の横にある赤いアイコンが表示されます）。古いサーバーが廃止されたら、この機能を有効にすることをお勧めします（アイコンをクリックして緑色にします）。

    これで移行が完了しました。古いサーバーのすべての構成と設定が保持され、新しいサーバーに転送されます。

    クラスターの管理を別のClusterControlサーバーに移行する

    クラスター情報のバックアップ

    これは、クラスターのメタデータと情報をバックアップして、それを別のClusterControlサーバーに転送できるようにすることです。これは部分バックアップとも呼ばれます。それ以外の場合は、「既存のサーバー/クラスターのインポート」を実行して、それらを新しいClusterControlに再インポートする必要があります。これは、古いサーバーからの監視データが失われることを意味します。ロードバランサーまたは非同期スレーブインスタンスがある場合、クラスターがインポートされたら、一度に1つのノードでこれをインポートする必要があります。したがって、本番環境のセットアップの完全なセットがある場合は、少し面倒です。

    クラスタの「マネージャ」移行の演習を次の図に示します。

    基本的に、MySQLレプリケーション（クラスターID：2）を移行して、別のClusterControlインスタンスで管理する必要があります。これには、-save-cluster-infoオプションと--restore-cluster-infoオプションを使用します。 --save-cluster-infoオプションは、対応するクラスター情報をエクスポートして、別の場所に保存します。 MySQLレプリケーションクラスター（クラスターID：2）をエクスポートしてみましょう。現在のClusterControlサーバーで、次の手順を実行します。

    $ s9s backup \
--save-cluster-info \
--cluster-id=2 \
--backup-directory=$HOME/ccbackup \
--output-file=cc-replication-2.tar.gz \
--log

    バックアップジョブが実行中であることを示す一連の新しい行がターミナルに印刷されます（出力には、 ClusterControl-> Activity-> Jobsからもアクセスできます。 ）：

    ジョブログをよく見ると、ジョブがクラスターID 2のすべての関連情報とメタデータをエクスポートしようとしていることがわかります。出力は圧縮ファイルとして保存され、-backupを使用して指定したパスの下に配置されます。 -ディレクトリフラグ。このフラグを無視すると、ClusterControlは出力をデフォルトのバックアップディレクトリ（SSHユーザーのホームディレクトリ）の$ HOME/backupsに保存します。

    クラスター情報の復元

    ここで説明する手順は、ClusterControl完全バックアップの復元手順と同様です。現在のサーバーから他のClusterControlサーバーにバックアップを転送します：

    $ scp $HOME/ccbackup/cc-replication-2.tar.gz 192.168.0.190:~

    復元を実行する前に、新しいClusterControlサーバーからすべてのノードにパスワードなしのSSHを設定する必要があります。

    $ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2
$ ssh-copy-id 192.168.0.19 #prometheus cluster 2

    次に、新しいサーバーで、MySQLレプリケーションのクラスター情報の復元を実行します。

    $ s9s backup \
--restore-cluster-info \
--input-file=$HOME/cc-replication-2.tar.gz \
--log

    進行状況は、アクティビティ->ジョブ->クラスタの復元で確認できます。 ：

    ジョブメッセージをよく見ると、ClusterControlがこの新しいインスタンスでクラスターIDを1に自動的に再割り当てしていることがわかります（古いインスタンスではクラスターID 2でした）。

    次に、[グローバル設定]->[クラスター登録]->[クラスターの同期]に移動して、UIでクラスターを同期します 。 ClusterControlのメインダッシュボードに戻ると、次のように表示されます。

    このエラーは、RPC APIトークンが正しくないため、新しいClusterControlUIが監視および管理データを取得できないことを意味します。それに応じて更新する必要があります。まず、クラスターID 1のrpc_key値を取得します：

    $ cat /etc/cmon.d/cmon_1.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=tAnvKME53N1n8vCC

    UIで、[ここでRPCAPIトークンを変更する]行の[ここ]リンクをクリックします。次のダイアログが表示されます：

    それぞれのrpc_key値をテキストフィールドに貼り付け、[保存]をクリックします。しばらく待つと、クラスターリストが自動的に更新されます。

    最後のステップは、新しいClusterControlIPアドレスの変更に対するMySQLcmonユーザー権限192.168.0.190を修正することです。マスターノード（192.168.0.31）にログインし、次のステートメントを実行します。

    $ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

    **を/etc/cmon.cnf内のmysql_password値と同じcmonMySQLパスワードに置き換えます。

    古いユーザー権限を取り消す（取り消してもユーザーは削除されません）か、単に古いユーザーを削除することもできます：

    $ mysql -uroot -p -e 'DROP USER [email protected]"192.168.0.19"'

    特権が設定されると、すべてが緑色になっているはずです：

    この時点で、私たちのアーキテクチャは次のようになっています。

    これで移行の演習は完了です。

    最終的な考え

    ClusterControlインスタンスとそれらが管理するクラスターの完全および部分的なバックアップを実行できるようになり、わずかな労力でホスト間で自由に移動できるようになりました。提案やフィードバックは大歓迎です。


    1. アトミック操作で1つのドキュメントのブールフィールドを切り替える方法は？

    2. MongoDBの正規化、外部キー、および結合

    3. Springデータを使用した$projectMongoDB内の$filter

    4. Python3.5でのjson.loadsとRedis