MariaDBクラスターを使用したAmazonAWSでのホットスタンバイの構築

最後に、非同期レプリケーションを設定する必要があります

##マスターノード、つまりGaleraクラスター内のノードにレプリケーションユーザーを作成します

MariaDB [(none)]> CREATE USER 'cmon_replication'@'172.32.31.2' IDENTIFIED BY 'PahqTuS1uRIWYKIN';

Query OK, 0 rows affected (0.866 sec)

MariaDB [(none)]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'cmon_replication'@'172.32.31.2';

Query OK, 0 rows affected (0.127 sec)

##次のようにxtrabackup_binlog_infoからGTIDスレーブの位置を取得します。

$  cat /var/lib/mysql/xtrabackup_binlog_info

binlog.000002   71131632 1000-1000-120454

##次に、次のようにスレーブレプリケーションを設定します。

MariaDB [(none)]> SET GLOBAL gtid_slave_pos='1000-1000-120454';

Query OK, 0 rows affected (0.053 sec)

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='172.31.28.175', MASTER_USER='cmon_replication', master_password='PahqTuS1uRIWYKIN', MASTER_USE_GTID = slave_pos;

##ここで、スレーブのステータスを確認します

MariaDB [(none)]> show slave status \G

*************************** 1. row ***************************

                Slave_IO_State: Waiting for master to send event

                   Master_Host: 172.31.28.175

                   Master_User: cmon_replication

                   Master_Port: 3306

                 Connect_Retry: 60

               Master_Log_File: 

           Read_Master_Log_Pos: 4

                Relay_Log_File: relay-bin.000001

                 Relay_Log_Pos: 4

         Relay_Master_Log_File: 

              Slave_IO_Running: Yes

             Slave_SQL_Running: Yes

               Replicate_Do_DB: 

           Replicate_Ignore_DB: 

            Replicate_Do_Table: 

        Replicate_Ignore_Table: 

       Replicate_Wild_Do_Table: 

   Replicate_Wild_Ignore_Table: 

                    Last_Errno: 0

                    Last_Error: 

                  Skip_Counter: 0

           Exec_Master_Log_Pos: 4

               Relay_Log_Space: 256

               Until_Condition: None

                Until_Log_File: 

                 Until_Log_Pos: 0

            Master_SSL_Allowed: No

            Master_SSL_CA_File: 

            Master_SSL_CA_Path: 

               Master_SSL_Cert: 

             Master_SSL_Cipher: 

                Master_SSL_Key: 

         Seconds_Behind_Master: 0

 Master_SSL_Verify_Server_Cert: No

                 Last_IO_Errno: 0

                 Last_IO_Error: 

                Last_SQL_Errno: 0

                Last_SQL_Error: 

   Replicate_Ignore_Server_Ids: 

              Master_Server_Id: 1000

                Master_SSL_Crl: 

            Master_SSL_Crlpath: 

                    Using_Gtid: Slave_Pos

                   Gtid_IO_Pos: 1000-1000-120454

       Replicate_Do_Domain_Ids: 

   Replicate_Ignore_Domain_Ids: 

                 Parallel_Mode: conservative

                     SQL_Delay: 0

           SQL_Remaining_Delay: NULL

       Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

              Slave_DDL_Groups: 0

Slave_Non_Transactional_Groups: 0

    Slave_Transactional_Groups: 0

1 row in set (0.000 sec)

ホットスタンバイノードをClusterControlに追加する

ClusterControlを使用している場合は、データベースサーバーの状態を簡単に監視できます。これをスレーブとして追加するには、Galeraノードクラスターを選択し、次に示すように選択ボタンに移動してレプリケーションスレーブを追加します。

[レプリケーションスレーブの追加]をクリックして、以下のように既存のスレーブの追加を選択します。

私たちのトポロジーは有望に見えます。

お気づきかもしれませんが、ノード172.32.31.2がホットスタンバイとして機能していますノードには、172.32。％us-west-2（オレゴン）というプレフィックスが付いた異なるCIDRがあり、他のノードは172.31。％us-east-2（オハイオ）にあります。それらは完全に異なるリージョンにあるため、Galeraノードでネットワーク障害が発生した場合は、ホットスタンバイノードにフェイルオーバーできます。

結論

AmazonAWSでのホットスタンバイの構築は簡単で簡単です。必要なのは、容量要件と、セットアップが必要なネットワークトポロジ、セキュリティ、およびプロトコルを決定することだけです。

VPCピアリングを使用すると、パブリックインターネットにアクセスせずに、異なるリージョン間の相互通信を高速化できるため、接続はAmazonネットワークインフラストラクチャ内にとどまります。

もちろん、1つのスレーブで非同期レプリケーションを使用するだけでは不十分ですが、このブログは、これを開始する方法の基盤として機能します。これで、非同期スレーブが複製する別のクラスターを簡単に作成し、ディザスタリカバリノードとして機能する別の一連のGaleraクラスターを作成できます。また、Galeraでgmcast.segment変数を使用して、このブログのように同期的に複製することもできます。