sql >> データベース >  >> RDS >> Mysql

バックアップからMySQLまたはPostgresクラスターのデプロイを自動化する

    ClusterControl 1.7.1には、バックアップからクラスターを作成と呼ばれる新機能が導入されています。これにより、新しいMySQLまたはPostgresベースのクラスターをデプロイし、バックアップからそのクラスター上のデータを復元できます。このブログ投稿では、この新機能がどのように機能するか、およびこのタイプの自動化によってインフラストラクチャの運用がどのように改善されるかを示しています。

    紹介：バックアップからクラスターを作成

    バックアップ管理はユーザーに最も愛されている機能であり、私たちはそれを次のレベルに引き上げました。この新機能は単純に聞こえます。ClusterControl1.7.1は、既存のバックアップから新しいクラスターをデプロイできます。ただし、本番環境グレードのクラスターをバックアップから直接デプロイするには、複数の手順とチェックが必要です。復元自体には、次のような独自の課題があります。

    • 完全または部分的な復元の結果
    • ベースバックアップとその増分バックアップの順序（増分バックアップの場合）
    • バックアップの復号化（暗号化されている場合）
    • 復元ツールのオプション
    • 解凍（圧縮されている場合）
    • ソースサーバーから宛先サーバーへのバックアップストリーミング
    • 復元中および復元後のディスクスペース使用率
    • 復元の進捗状況の報告

    上記をデータベースクラスター展開タスクの複雑さと反復性と組み合わせると、時間を節約し、エラーが発生しやすい手順を実行する際のリスクを減らすことができます。ユーザーの観点から最も難しい部分は、復元元のバックアップを選択することです。 ClusterControlは、舞台裏でのすべての面倒な作業を処理し、終了したら最終結果を報告します。

    手順は基本的に簡単です：

    1. ClusterControlノードから新しいサーバーへのパスワードなしのSSHをセットアップします。
    2. バックアップリストから論理バックアップを1つ選択するか、バックアップ->バックアップの作成で論理バックアップを作成します。 。
    3. [復元]->[バックアップからクラスターを作成]をクリックします 展開ウィザードに従います。

    この機能は、現時点ではMySQLGaleraClusterとPostgreSQL用に特別に構築されています。既存のバックアップで[復元]をクリックすると、UIに表示される内容は次のとおりです。

    一番下のオプションは私たちが探しているものです。次に、展開構成の前に選択したバックアップの概要ダイアログを示します。

    次に、それぞれのクラスター（MySQL Galera ClusterまたはPostgreSQL）の同じデータベースクラスター展開ウィザードが表示され、新しいクラスターを構成します。

    バックアップにあるものと同じデータベースroot/adminユーザー名とパスワードを指定する必要があることに注意してください。そうしないと、最初のノードを起動するときに展開が途中で失敗します。通常、復元と展開の手順は次の順序で行われます。

    1. 必要なソフトウェアと依存関係をすべてのデータベースノードにインストールします。
    2. 最初のノードを開始します。
    3. 最初のノードでバックアップをストリーミングおよび復元します（自動再起動フラグを使用）。
    4. 残りのノードを構成して追加します。

    ジョブが完了すると、新しいデータベースクラスターがClusterControlクラスターダッシュボードの下に一覧表示されます。

    それから何を得ることができますか？

    次のセクションで説明するように、この機能からメリットを得ることができるものはたくさんあります。

    さまざまな条件でデータセットをテストする

    場合によっては、新しいデータベースバージョンがデータベースのワークロードに対して機能または実行されるのではないかと思うかもしれません。それをテストすることが、知る唯一の方法です。ここで、この機能が役立ちます。これにより、データベースの安定性やパフォーマンスに影響を与える可能性のある多くの変数、たとえば、基盤となるハードウェア、ソフトウェアバージョン、ベンダー、データベース、またはアプリケーションのワークロードに対してテストとベンチマークを実行できます。

    簡単な例として、MySQL5.6とMySQL5.7の間でDDLの実行が大幅に改善されています。 1,000万行のテーブルに対する次のDROP操作は、すべてを証明しています。

    mysql-5.7> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (1 min 58.12 sec)
    mysql-5.6> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (2 min 23.74 sec)

    比較する別のクラスターがあると、実際に改善を測定し、移行を正当化することができます。

    論理バックアップを使用したデータベースの移行

    mysqldumpのような論理バックアップ およびpg_dumpall あるバージョンまたはベンダーから別のバージョンにデータをアップグレード、ダウングレード、または移行するための最も安全な方法です。すべての論理バックアップを使用して、データベースの移行を実行できます。データベースのアップグレード手順は基本的に簡単です：

    1. 論理バックアップを作成（またはスケジュール）します-MySQLの場合はmysqldump、PostgreSQLの場合はpg_dumpall
    2. ClusterControlノードから新しいサーバーへのパスワードなしのSSHをセットアップします。
    3. バックアップリストから作成した論理バックアップを1つ選択します。
    4. [復元]->[バックアップからクラスターを作成]をクリックします 展開ウィザードに従います。
    5. 新しいクラスターでのデータの復元を確認します。
    6. アプリケーションを新しいクラスターにポイントします。

    クラスターの合計リカバリ時間の短縮

    クラスターの実行を妨げる壊滅的な障害を想像してみてください。たとえば、クラスターに接続しているすべての仮想マシンに影響を与える集中型ストレージの障害の場合、ほぼすぐに代替クラスターを取得できます（バックアップファイルが障害のあるデータベースノードの外部に保存されている場合） 、 明白なことを述べます）。この機能は、s9sクライアントを介して自動化できます。この場合、コマンドラインインターフェイスを介してジョブをトリガーできます。例：

    $ s9s cluster \
--create \
--cluster-type=postgresql \
--nodes="192.168.0.101?master;192.168.0.102?slave;192.168.0.103?slave" \
--provider-version=11 \
--db-admin=postgres \
--db-admin-passwd='s3cr3tP455' \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--cluster-name="PostgreSQL 9.6 - Test"
--backup-id=214 \
--log

    この機能を使用する際の注意点の1つは、バックアップに保存されているものと同じ管理者ユーザー名とパスワードを使用することです。また、すべてのデータベースノードへのパスワードなしのSSHを事前に設定する必要があります。それ以外の場合、インタラクティブに構成する場合は、WebUIインターフェイスを使用してください。

    非同期レプリケーションによるスケールアウト

    MySQL Galera Clusterの場合、新しく作成されたクラスターは、MySQL非同期レプリケーションを介してスケールアウトされる可能性があります。次の図に示すように、データセンターの本番クラスターからの最新のバックアップに基づいてオフィス内の新しいクラスターを既に復元し、オフィスクラスターに本番クラスターからの複製を継続させたいとします。

    >

    次に、次の方法を使用して非同期レプリケーションリンクを設定できます。

    1. 本番環境で1つのノードを選択し、バイナリロギングを有効にします（無効になっている場合）。 [ノード]->[ノードの選択]->[ノードアクション]->[バイナリログの有効化]に移動します。

    2. Officeクラスターのすべてのノードでバイナリロギングを有効にします。このアクションにはローリングリスタートが必要です。これは、[ノードの自動再起動]ドロップダウンで[はい]を選択すると自動的に実行されます。

      それ以外の場合は、[管理]->[アップグレード]->[ローリングリスタート]を使用して（または一度に1つのノードを手動でリスタートする）、ダウンタイムなしでこの操作を実行できます。

    3. [管理]->[スキーマとユーザー]->[ユーザー]->[新しいユーザーの作成]を使用して、本番クラスターにレプリケーションユーザーを作成します。

    4. 次に、本番クラスターのマスターノードにレプリケートするノードを1つ選択し、レプリケーションリンクを設定します。

      mysql> CHANGE MASTER master_host = 'prod-mysql1', master_user = 'slave', master_password = 'slavepassw0rd', master_auto_position = 1;
mysql> START SLAVE;

    5. レプリケーションが実行されているかどうかを確認します：

      mysql> SHOW SLAVE STATUS\G
      Slave_IO_ThreadとSlave_SQL_threadが「はい」を報告していることを確認してください。遅れている場合、オフィスのクラスターはマスターノードに追いつき始めるはずです。

    今のところは以上です！


    1. データベースはMySQLとPythonで自動的に更新されません

    2. SQL Serverクエリでテーブル構造を表示するにはどうすればよいですか？

    3. Windowsコマンドスクリプトでsql*plusを使用してフローを制御するにはどうすればよいですか？

    4. アップグレードされたdbForgeStudiofor MySQL、v.8.1でのMariaDB10.4のサポート