2台のmysqlサーバーでデュアルマシン相互バックアップ構成とテストデータ同期を実現

この記事では、2 台のマシンの相互バックアップ構成について詳しく説明します。テスト データが同期された後、10.168.1.44 サーバー データベース内のデータを変更すると、データが同期されたことがわかります。逆に、10.168.0.126 のデータを変更すると、10.168.1.44 データベース内の対応するテーブル データの変更も確認できます。この時点で、10.168.0.126 と 10.168.1.44 は相互にマスター/スレーブ データベース関係を持っています。

推奨される mysql ビデオ チュートリアル: "mysql チュートリアル"

apache php mysql

準備

2 つのサーバー: 10.168.1.44

10.168.0 。 126

動作環境: Linuxシステム( Centos6.5)

Mysql バージョン: 5.7.22

設定を変更する

2 つのサーバーで /etc/my.conf 設定ファイルの情報が次のように変更されました: 10.168 の

.1.44 server/etc/my.conf 設定ファイルに追加します:

server_id=10

log-bin=master_01 //バイナリ ログを有効にします。目的は、別のサーバーが実行操作を決定するためにログを使用できるようにすることです

binlog-do-db =test_db //同期テーブル

binlog-do-db=my_test //同期テーブル

10.168.0.126のserver/etc/my.conf設定ファイルに追加します:

server_id=20

log -bin= master_02 //バイナリログを有効にします。その目的は、別のサーバーがログを使用して実行操作を決定できるようにすることです

binlog-do-db=test_db //同期テーブル

binlog-do-db=my_test //同期テーブル

追加後、service mysqld restart コマンドを実行してデータベースを再起動し、変更を有効にします

mysql アカウントを追加します

mysql アカウントを追加し、権限のあるユーザーに付与してデータ同期を実行します

10.168 .1.44 コマンドを実行します:

GRANT FILE ON *.* TO 'copyuser'@'10.168.0.126' IDENTIFIED BY 'Admin@123';

GRANT REPLICATION SLAVE ON *.* TO 'copyuser'@'10.168.0.126' IDENTIFIED BY 'Admin@123';

flush privileges;

10.168。 0.126 コマンドを実行します:

GRANT FILE ON *.* TO 'copyuser'@'10.168.1.44' IDENTIFIED BY 'Admin@123';

GRANT REPLICATION SLAVE ON *.* TO 'copyuser'@'10.168.1.44' IDENTIFIED BY 'Admin@123';

flush privileges;

スレーブデータベースを構成します

構成:

現在のマスターデータベースのステータスを表示します:

mysql> マスターステータスを表示;

現在のファイルと位置の値を記録します。

データベースにアクセスしてメインデータベースのステータスを確認します

10.168.1.44で実行します

mysql>CHANGE MASTER TO

MASTER_HOST='10.168.0.126',

MASTER_USER='copyuser',

MASTER_PASSWORD='Admin@123',

MASTER_PORT=3306,

MASTER_LOG_FILE='master_02.000002',

MASTER_LOG_POS=1771,

MASTER_CONNECT_RETRY=10;

在10.168.0.126执行：

mysql>CHANGE MASTER TO

MASTER_HOST='10.168.1.44',

MASTER_USER='copyuser',

MASTER_PASSWORD='Admin@123',

MASTER_PORT=3306,

MASTER_LOG_FILE='master_01.000008',

MASTER_LOG_POS=154,

MASTER_CONNECT_RETRY=10;

注：若slave开启状态无法执行以上命令，需要首先执行 stop slave；关闭slave，执行完上述命令后执行start slave；命令开启slave。

上述命令执行完后，查看从服务状态：

执行命令：

mysql> show slave status\G;

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

               Slave_IO_State: Waiting for master to send event

                  Master_Host: 10.168.1.44

                  Master_User: copyuser

                  Master_Port: 3306

                Connect_Retry: 10

              Master_Log_File: master_01.000008

          Read_Master_Log_Pos: 154

               Relay_Log_File: cdh-2-relay-bin.000004

                Relay_Log_Pos: 367

        Relay_Master_Log_File: master_01.000008

             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: 154

              Relay_Log_Space: 740

              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: 10

                  Master_UUID: 778beb1e-8f0f-11e8-a815-00505695cd8c

             Master_Info_File: /var/lib/mysql/master.info

                    SQL_Delay: 0

          SQL_Remaining_Delay: NULL

      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

           Master_Retry_Count: 86400

                  Master_Bind:

      Last_IO_Error_Timestamp:

     Last_SQL_Error_Timestamp:

               Master_SSL_Crl:

           Master_SSL_Crlpath:

           Retrieved_Gtid_Set:

            Executed_Gtid_Set:

                Auto_Position: 0

         Replicate_Rewrite_DB:

                 Channel_Name:

           Master_TLS_Version:

1 row in set (0.00 sec)

注Slave_IO_Running: YesおよびSlave_SQL_Running: Yesのみいつどちらも「はい」であれば、構成は成功です。

データ同期のテスト

10.168.1.44 サーバーデータベース内のデータを変更します:

変更前:

変更後:

10 .168.0.126 を表示データベース内の対応テーブル 媒体データ：

同期されていることが分かります。

逆に、10.168.0.126 のデータを変更すると、10.168.1.44 データベース内の対応するテーブル データの変更も確認できます。

この時点で、10.168.0.126 と 10.168.1.44 の間の相互のマスターとスレーブのデータベース関係に問題がある可能性があります

1. スレーブのステータスを確認すると、

   Slave_IO_ が見つかります。ランニング: 接続中

この問題には主に 3 つの理由があります:

1. ネットワークが利用できない (お互いに ping を実行して、正常に ping できるかどうかを確認してください)

2. パスワードが間違っています:スレーブの設定時に実行したコマンドのパスワードが正しいか確認してください

3. 位置が間違っています: スレーブの設定時に、対応する位置が正しい位置で埋められていません (スレーブサーバーに対応するマスターのステータスを確認してください)データベース: マスターステータスを表示して検索します)

この問題が発生する理由は、データの同期に使用されるユーザー「copyuser」が一方のサーバーでのみ作成され、もう一方のサーバーのデータベースにはユーザーが作成されないためです。作成後でもOKです。

4. スレーブのステータスを確認すると、Slave_SQL_Running: No

この現象の主な理由は、2 つのデータベース間のデータに違いがあることです。 mysql ログを参照して異常を確認してください

Mysql ログは通常 /var/log/mysqld.log にあります

マスター データベースのデータを同期するようにスレーブ データベースのみを設定し、各データベースと同期するように設定しない場合は注意が必要ですその他、スレーブ データベースのデータを変更すると、同期が失敗する可能性があります。

関連記事:

Mysql データベースのデュアルマシンホットバックアップ構成_MySQL

Mysql リアルタイム同期 - デュアルマシン相互バックアップ (デュアルマスター)

関連ビデオ:

MySQL データ管理のバックアップとリカバリケース分析ビデオチュートリアル

以上が2台のmysqlサーバーでデュアルマシン相互バックアップ構成とテストデータ同期を実現の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。