Ansibleを使用してスタンドアロンMySQLからGaleraクラスターへの移行を自動化する方法

データベースの移行は適切に拡張できません。通常、トリガーを引いて古いものから新しいものに切り替える前に、大量のテストを実行する必要があります。ほとんどのプロセスは自動化に役立たないため、移行は通常手動で行われます。しかし、それは移行プロセスに自動化の余地がないという意味ではありません。新しいソフトウェアを使用して多数のノードをセットアップし、それらをデータでプロビジョニングし、古い環境と新しい環境の間で手動でレプリケーションを構成することを想像してみてください。これには数日かかります。自動化は、新しい環境をセットアップしてデータをプロビジョニングするときに非常に役立ちます。このブログ投稿では、スタンドアロンのPerconaServer5.7から3ノードのPerconaXtraDBCluster5.7への非常に単純な移行について説明します。これを実現するためにAnsibleを使用します。

環境の説明

まず、重要な免責事項の1つです。ここで示すのは、本番環境で実行したいもののドラフトにすぎません。テスト環境では機能しますが、環境に適したものにするために変更が必要になる場合があります。テストでは、Vagrantを使用してデプロイされた4つのUbuntu16.04VMを使用しました。 1つにはスタンドアロンのPerconaServer5.7が含まれ、残りの3つはPerconaXtraDBクラスターノードに使用されます。また、ansibleプレイブックを実行するために別のノードを使用しますが、これは必須ではなく、プレイブックはノードの1つから実行することもできます。さらに、SSH接続はすべてのノード間で利用できます。 ansibleを実行するホストからの接続が必要ですが、ノード間でsshを実行する機能があると便利です（特にマスターと新しいスレーブ間で-プレイブックではこれに依存しています）。

プレイブックの構造

Ansible Playbookは通常、共通の構造を共有します。つまり、異なるホストに割り当てることができる役割を作成します。各ロールには、実行されるタスク、使用されるテンプレート、アップロードされるファイル、この特定のプレイブック用に定義された変数が含まれます。私たちの場合、プレイブックは非常にシンプルです。

.
├── inventory
├── playbook.yml
├── roles
│   ├── first_node
│   │   ├── my.cnf.j2
│   │   ├── tasks
│   │   │   └── main.yml
│   │   └── templates
│   │       └── my.cnf.j2
│   ├── galera
│   │   ├── tasks
│   │   │   └── main.yml
│   │   └── templates
│   │       └── my.cnf.j2
│   ├── master
│   │   └── tasks
│   │       └── main.yml
│   └── slave
│       └── tasks
│           └── main.yml
└── vars
    └── default.yml

いくつかの役割を定義しました。マスターの役割があります。これは、スタンドアロンノードでいくつかの健全性チェックを実行することを目的としています。スレーブノードがあります。これは、Galeraノードの1つで実行され、レプリケーション用に構成し、非同期レプリケーションをセットアップします。次に、すべてのGaleraノードの役割と、そこからクラスターをブートストラップする最初のGaleraノードの役割があります。 Galeraロールの場合、my.cnfファイルの作成に使用するテンプレートがいくつかあります。また、ローカルの.my.cnfを使用してユーザー名とパスワードを定義します。パスワードと同じように、カスタマイズしたい変数がいくつか含まれているファイルがあります。最後に、プレイブックを実行するホストを定義するインベントリファイルがあります。また、物事を正確に実行する方法に関する情報を含むプレイブックファイルもあります。個々のビットを見てみましょう。

インベントリファイル

これは非常に単純なファイルです。

[galera]
10.0.0.142
10.0.0.143
10.0.0.144

[first_node]
10.0.0.142

[master]
10.0.0.141

3つのグループがあります。「galera」にはすべてのGaleraノードが含まれ、「first_node」はブートストラップに使用され、最後に「master」にはスタンドアロンのPerconaServerノードが含まれます。

Playbook.yml

ファイルplaybook.ymlには、プレイブックの実行方法に関する一般的なガイドラインが含まれています。

-   hosts: master
    gather_facts: yes
    become: true
    pre_tasks:
    -   name: Install Python2
        raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)
    vars_files:
        -   vars/default.yml
    roles:
    -   { role: master }

ご覧のとおり、スタンドアロンノードから開始し、「マスター」の役割に関連するタスクを適用します（これについては、この投稿の後半で詳しく説明します）。

-   hosts: first_node
    gather_facts: yes
    become: true
    pre_tasks:
    -   name: Install Python2
        raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)
    vars_files:
        -   vars/default.yml
    roles:
    -   { role: first_node }
    -   { role: slave }

次に、「first_node」グループで定義されたノードに移動し、「first_node」と「slave」の2つの役割を適用します。前者は単一ノードのPXCクラスターをデプロイすることを目的としており、後者はスレーブとして機能するように構成し、レプリケーションをセットアップします。

-   hosts: galera
    gather_facts: yes
    become: true
    pre_tasks:
    -   name: Install Python2
        raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)
    vars_files:
        -   vars/default.yml
    roles:
    -   { role: galera }

最後に、すべてのGaleraノードを調べて、それらすべてに「galera」の役割を適用します。

データベース管理に関するSevereninesDevOpsガイドオープンソースデータベースを自動化および管理するために知っておくべきことを学ぶ無料でダウンロード

変数

役割の調査を開始する前に、このプレイブック用に定義したデフォルトの変数について説明します。

sst_user: "sstuser"
sst_password: "pa55w0rd"
root_password: "pass"
repl_user: "repl_user"
repl_password: "repl1cati0n"

すでに述べたように、これは非常にシンプルなプレイブックであり、カスタマイズのオプションはあまりありません。ユーザーとパスワードを設定できます。これが基本です。 1つの落とし穴-スタンドアロンノードのルートパスワードがここで「root_password」と一致することを確認してください。一致しないと、プレイブックがそこに接続できなくなります（拡張して処理できますが、それについては説明しませんでした）。

このファイルにはあまり価値がありませんが、経験則として、資格情報を含むすべてのファイルを暗号化する必要があります。明らかに、これはセキュリティ上の理由によるものです。 Ansibleにはansible-vaultが付属しており、ファイルの暗号化と復号化に使用できます。ここでは詳細については説明しません。知っておく必要のあることはすべて、ドキュメントに記載されています。つまり、パスワードを使用してファイルを簡単に暗号化し、ファイルからのパスワードを使用してプレイブックを自動的に復号化するか、手動で渡すことができるように環境を構成できます。

ロール

このセクションでは、プレイブックで定義されている役割について説明し、それらが実行することを意図していることを要約します。

マスターの役割

すでに述べたように、この役割はスタンドアロンMySQLの構成に対して健全性チェックを実行することを目的としています。 percona-xtrabackup-24などの必要なパッケージをインストールします。また、マスターノードにレプリケーションユーザーを作成します。 server_idおよびその他のレプリケーションとバイナリログ関連の設定が設定されていることを確認するために、構成が確認されます。 GTIDは、レプリケーションに依存するため、有効になっています。

First_nodeの役割

ここでは、最初のGaleraノードがインストールされています。 Perconaリポジトリが構成され、my.cnfがテンプレートから作成されます。 PXCがインストールされます。また、いくつかのクリーンアップを実行して、不要なユーザーを削除し、必要なユーザーを作成します（rootユーザーと選択したパスワード、SSTに必要なユーザー）。最後に、クラスターはこのノードを使用してブートストラップされます。クラスタを初期化する方法として、空の「wsrep_cluster_address」を使用します。これが、後で最初のノードで「galera」ロールを実行する理由です。つまり、クラスターのすべてのメンバーと「wsrep_cluster_address」を含む最初のmy.cnfを最後のノードと交換します。覚えておく価値のあることの1つは、パスワードを使用してrootユーザーを作成する場合、Ansibleがプレイブックの他のステップを実行できるように、MySQLからロックされないように注意する必要があります。これを行う1つの方法は、.my.cnfに正しいユーザーとパスワードを提供することです。もう1つは、「mysql_user」モジュールで常に正しいlogin_userとlogin_passwordを設定することを忘れないでください。

スレーブの役割

この役割は、スタンドアロンノードとシングルノードPXCクラスター間のレプリケーションの構成に関するものです。 xtrabackupを使用してデータを取得し、xtrabackup_binlog_infoで実行されたgtidをチェックして、バックアップが適切に復元され、レプリケーションを構成できることを確認します。また、スレーブノードがGTIDレプリケーションを使用できることを確認するために、少し構成を実行します。ここにはいくつかの落とし穴があります。Ansible2.7.10以降、「mysql_replication」モジュールを使用して「RESETMASTER」を実行することはできません。2.8ではいつでも実行できるはずです。 MySQLCLIコマンドを実行するには「シェル」モジュールを使用する必要がありました。外部ソースからGaleraノードを再構築するときは、必要なユーザー（少なくともSSTに使用されるユーザー）を再作成することを忘れないでください。そうしないと、残りのノードはクラスターに参加できなくなります。

ガレラの役割

最後に、これは残りの2つのノードにPXCをインストールする役割です。すべてのノードで実行します。最初のノードは、「ブートストラップ」バージョンではなく「本番」my.cnfを取得します。残りの2つのノードにはPXCがインストールされ、クラスター内の最初のノードからSSTを取得します。

概要

ご覧のとおり、Percona XtraDB Clusterをデプロイし、スタンドアロンMySQLノードのスレーブとして構成するために使用できるシンプルで再利用可能なAnsibleプレイブックを簡単に作成できます。正直なところ、単一のサーバーを移行する場合、同じことを手動で行う方が高速になるため、これはおそらく意味がありません。それでも、このプロセスを数回再実行する必要があると予想される場合は、自動化して時間効率を高めることは間違いなく理にかなっています。冒頭で述べたように、これは決して本番環境に対応したプレイブックではありません。これは概念実証であり、環境に適したものにするために拡張できるものです。プレイブックのアーカイブは次の場所にあります：http：//severalnines.com/sites/default/files/ansible.tar.gz

このブログ投稿がおもしろくて価値のあるものであると感じていただければ幸いです。遠慮なくご意見をお聞かせください。