Azure Database for MySQLでレプリケーションを試してみた

Azure,Database For MySQL

Azure Database for MySQLではレプリケーション機能が提供されています。

Azure Database for MySQL の読み取りレプリカ(MS社公式)

レプリケーション機能を使うと別リージョンに同じデータを保管するといった事が可能になります。
レプリケーションされたデータベースは読み取りも可能なので読み取り専用のDBを準備するような事も可能です。

今回はAzure Database for MySQLでレプリケーション設定、実際の設定や挙動確認、レプリケーション解除によるマスター昇格まで試してみました。

※非同期処理なので利用にあたってはレプリケーションに掛かる時間を考慮する必要があります。
※汎用とメモリ最適化の価格レベルでのみ使用可能です。開発の価格レベルでは使用できません。(Azure Database for MySQL フレキシブル サーバーの場合はすべてのレベルで可能です。)

スポンサーリンク

Azure Database for MySQLでレプリケーション設定

今回作成したAzure Database for MySQLの構成

今回は以下のような構成でAzure Database for MySQLのリソースを作成しました。検証目的ですので、スペック、ネットワーク設定等は最低限の設定で構成しています。

      • マスター(レプリケーション元)
        • サーバ名：rep-01
        • リージョン：米国東部2
        • バージョン：5.7
        • 価格レベル：汎用目的
        • コンピューティングとストレージ：仮想コア：2コア、ストレージサイズ：5GB
      • レプリカ(レプリケーション先)
        • サーバ名：rep-01-backup
        • リージョン：米国東部2
        • バージョン：5.7
        • 価格レベル：汎用目的
        • コンピューティングとストレージ：仮想コア：2コア、ストレージサイズ：5GB

※環境の都合上、リージョンはレプリケーション元も先も米国東部2を利用しておりますが、レプリカを別リージョンにした場合も同様の動作になります。

レプリケーション元のリソース作成

Azure Database for MySQLのリソースを作成します。

Azure Database for MySQLの作成手順

Azure PortalでAzure Database for MySQLのメニューを選択し作成を開始します。

作成画面でコンピューティングのストレージの選択や、サーバ名、管理者アカウントを設定します。
確認および作成をクリックします。

※管理者ユーザー名はrepdbadminとしています。

確認画面が表示されます。
作成をクリックします。

Azure Database for MySQLで接続設定

Azure Database for MySQLへの接続許可設定をします。

接続許可設定

接続のセキュリティメニューを選択します。
既存のクライアントIPアドレスを追加するを選択します。
自身がアクセスしているパブリックIPを許可するファイアウォール規則が設定されます。
保存をクリックします。

※デフォルトではインターネットからアクセス許可がされていない状態になります。自身の環境に併せて接続許可設定をします。(特定のIPから接続設定する場合は、開始IPと終了IPに同じIPを設定します。)

※接続のセキュリティ設定はレプリケーション設定時にレプリカへ引き継がれます(すべて引き継がれる訳ではありません。)。ただしレプリケーション開始後に行った変更はレプリケーションされずレプリカに自動で反映はされません。

Azure Database for MySQLでレプリカ作成

マスター側のAzure Database for MySQLでレプリケーション設定するだけで、レプリカのAzure Database for MySQLが自動的に作成されます。

Azure Database for MySQLのレプリカ作成手順

レプリケーションのメニューを選択します。レプリカの追加をクリックします。

レプリカの名前や場所を選択します。
OKをクリックします。

名前とレプリケーション先を指定するだけで、非常に簡単にAzure Database for MySQLのレプリカリソースを作成する事が出来ました。

レプリケーション設定後のリソース確認

Azure Portalでレプリケーション設定完了後のリソース作成状況を確認してみます。

レプリケーション設定確認

マスター(rep-01)とレプリカ(rep-01-backup)の2つが作成されている事が確認出来ます。

マスター(rep-01)でレプリケーション設定を確認してみます。
レプリカにrep-01-backupが表示されている事が確認出来ます。

レプリカ(rep-01-backup)側でレプリケーション設定を確認してみます。
マスターとしてrep-01が設定されている事が確認出来ます。

レプリカ(rep-01-backup)のサーバ設定を確認します。

サーバ名はrep-01-backupで作成されています。
サーバ管理者ログイン名はマスター(rep-01)と同じで作成されている事が分かります。

MySQLのレプリケーション動作確認

MySQLへの接続情報

今回はMySQL Workbenchを使ってSQLを実行しています。接続に関する情報はこんな感じになります。

    • マスター(rep-01)
      • ホスト名：rep-01.mysql.database.azure.com(サーバ名.mysql.database.azure.com)
      • Username：repdbadmin@rep-01(ユーザー名＠サーバ名)
      • Port:3306
      • パスワード：設定した値
    • レプリカ(rep-01-backup)
      • ホスト名：rep-01-backup.mysql.database.azure.com(サーバ名.mysql.database.azure.com)
      • Username：repdbadmin@rep-01-backup(ユーザー名＠サーバ名)
      • Port:3306
      • パスワード：設定した値(マスターと同じ)

MySQLのグローバル変数を確認

MySQLのグローバル変数でレプリケーションに関する設定を確認してみます。

グローバル変数を確認

MySQL Workbenchで接続設定を作成しDBへ接続します。

MySQL Workbenchを使った接続の詳細についてはこちらを参考下さい。(MariaDBの例になります。)

マスター(rep-01)へ接続しSQLを実行します。
redirect_server_hostに値が入っており、レプリカ設定されている事が分かります。

【マスター(rep-01)で実行したSQL】

select @@global.redirect_server_host;

【SQL実行結果】

マスター(rep-01)でSQLを実行します。
read_only設定を確認します。
マスター側ではOFFになっている事が確認出来ます。

【マスター(rep-01)で実行したSQL】

show global variables like 'read_only’;

【SQL実行結果】

 

レプリカ(rep-01-backup)へ接続しSQLを実行します。
read_only設定を確認します。
レプリカ側ではONになっている事が確認出来ます。

【レプリカ(rep-01-backup)で実行したSQL】

show global variables like 'read_only’;

【SQL実行結果】

レプリカ(rep-01-backup)側が読み取り専用となっている事が分かります。

MySQL上でテーブル作成や値をインサートしてレプリケーションを確認

実際にMySQL上でテーブルの操作をやって、レプリケーションの状況を確認してみます。

MySQLの操作

マスター(rep-01)上でSQLを実行しスキーマ作成します。
スキーマ名はreptestとしています。

【マスター(rep-01)で実行したSQL】

cerate schema 'reptest’;

【SQL実行結果】

マスター(rep-01)上でテーブル作成します。
テーブル名はuserとしています。

【マスター(rep-01)で実行したSQL】

cerate table reptest.user (id int, name varchar(8));

【SQL実行結果】

レプリカ(rep-01-backup)上で作成されているテーブルを確認してみます。
userテーブルが作成されている事が確認出来ます。

【レプリカ(rep-01-backup)で実行したSQL】

show table from ;

【SQL実行結果】

マスター(rep-01)で作成したuserテーブルに値を挿入します。
userテーブルに値が挿入されている事が確認出来ます。

【マスター(rep-01)で実行したSQL】

insert into reptest.user values (1, 'TamaNegi’);
select * from reptest.user;

【SQL実行結果】

 

レプリカ(rep-01-backup)でuserテーブルを確認すると、マスター(rep-01)で挿入された値が確認出来ます。

【マスター(rep-01)で実行したSQL】

select * from reptest.user;

【SQL実行結果】

レプリカ(rep-01-backup)でuserテーブルに値を挿入してみます。
レプリカ側はread-onlyの為、エラーになります。

【マスター(rep-01)で実行したSQL】

insert into reptest.user values (2, 'TamaNegi’);

【SQL実行結果】

Azure Database for MySQLのレプリケーション停止とマスター昇格

Azure Database for MySQLのレプリケーション停止

レプリケーション設定停止はマスター(rep-01)側で実施する必要があります。レプリケーションを停止すると自動的にレプリカがマスターへ昇格します。

レプリケーションの停止手順

マスター(rep-01)のレプリケーションメニューを選択します。
レプリケーションを停止するレプリカを選択します。
レプリケーションを停止をクリックします。

レプリケーション停止の確認メッセージが表示されます。OKをクリックします。
マスター側でレプリケーション停止させる事により、自動的にレプリカがマスターへ昇格します。再度レプリケーション設定を確認してみます。

マスター(rep-01)でレプリケーションを確認するとレプリカが表示されていない事が分かります。

レプリカ(rep-01-backup)でレプリケーションを確認すると、マスターへ昇格している事が分かります。

マスターに昇格したMySQLで動作確認

レプリケーション停止によりマスターに昇格したrep-01-backupでSQLを実行して確認してみます。

レプリケーション停止後の確認

マスターに昇格したrep-01-backupへ接続しSQLを実行します。
read_only設定を確認するとレプリケーション解除後はOFFになっている事が確認出来ます。

【マスター(rep-01)で実行したSQL】

show global variables like 'read_only’;

【SQL実行結果】

 

マスターに昇格したrep-01-backupでuserテーブルに値を挿入します。
レプリケーション停止前はエラーになりましたが、今回は値が挿入されている事が確認出来ました。

id1で設定したデータも確認出来ます。
レプリケーション停止前のデータも残っている事も確認出来ました。

【マスター(rep-01-backup)で実行したSQL】

insert into reptest.user values (2, 'TamaNegi’);
select * from reptest.user;

【SQL実行結果】

マスター(rep-01)でuserテーブルの値を確認すると、昇格したマスター(rep-01-backup)で実行したSQLの内容が反映されない事が確認出来ます。

【マスター(rep-01)で実行したSQL】

select * from reptest.user;

【SQL実行結果】

レプリケーション解除する事により、両方が独立したマスターとして動作している事が分かります。

【おまけ】MySQL WorkbenchでSafeモードを解除する方法

MySQL WorkbenchですがデフォルトではSafeモードが有効になっています。
Delete文やDrop文など削除系のコマンドを実行するとエラーになります。
解除をする為にはMySQL Workbenchで設定が必要になります。

MySQL Workbenchの設定

MySQL WorkbenchのEditにあるPreferencesを選択します。

SQL Editorの設定画面の一番下にSafeモードに関する設定があります。

このチェックを外す事でSafeモードが解除されます。

スポンサーリンク

Azure,Database For MySQL