MySQL レプリケーション インスタンス GTID レプリケーションの詳細な説明

この記事では、mysql に関する関連知識を提供します。主に GTID レプリケーションに関連する問題を紹介します。GTID は、送信されたトランザクションの番号であり、グローバルに一意の番号です。一緒に見てみましょう。皆様のお役に立てれば幸いです。

推奨学習: mysql ビデオ チュートリアル

MySQL 5.6.5 から、新しい GTID ベースのレプリケーション方法が追加されました。 。 GTID により、メイン データベースに送信された各トランザクションがクラスター内で一意の ID を持つことが保証されます。この方法により、データベースのプライマリおよびセカンダリの整合性、障害回復、および耐障害性の機能が強化されます。

GTID とは

#GTID (グローバル トランザクション ID) は、送信されたトランザクションの番号であり、世界的に一意の番号です。 GTID は実際には UUID TID で構成されます。 UUID は、MySQL インスタンスの一意の識別子です。 TID は、このインスタンスでコミットされたトランザクションの数を表し、トランザクションがコミットされるにつれて単調に増加します。

GTID の具体的な形式は次のとおりです: 3E11FA47-71CA-11E1-9E33-C80AA9429562:23. コロンは、前にある uuid と後ろにある TID を区切ります。

GTID コレクションには、複数の MySQL インスタンスからのトランザクションをカンマで区切って含めることができます。

同じ MySQL インスタンスのトランザクション シーケンス番号に複数の範囲間隔がある場合は、コロンを使用して範囲の各グループを区切ります。例: e6954592-8dba-11e6-af0e-fa163e1cf111:1-5:11-18、e6954592-8dba-11e6-af0e-fa163e1cf3f2:1-27。

GTID の改善点は何ですか?

元のバイナリ ログベースのレプリケーションでは、スレーブ ライブラリは増分同期を実行するオフセットをマスター ライブラリに伝える必要があります。指定した場合、エラーによりデータが省略され、データの不整合が生じる可能性があります。 GTID の助けを借りて、マスターとスレーブの切り替えが発生した場合、MySQL の他のスレーブ データベースは新しいマスター データベース上の正しいレプリケーションの場所を自動的に見つけることができます。これにより、複雑なレプリケーション トポロジでのクラスターのメンテナンスが大幅に簡素化され、問題の発生が軽減されます。レプリケーション場所の手動設定 悪用のリスク。さらに、GTID ベースのレプリケーションでは、すでに実行されたトランザクションを無視できるため、データの不整合のリスクが軽減されます。

gtid セットに基づいて、マスター データベースはスレーブ データベースにどのデータが欠落しているかを正確に知ることができ、ネットワーク帯域幅の無駄を避けるためにスレーブ データベースに多少のデータを提供することはありません。

Mysql のマスター/スレーブ構造は、マスターとスレーブが 1 つずつの場合、GTID に関しては何の利点もありませんが、マスターが 2 つ以上の場合の利点は非常に明白であり、新しいマスターを切り替えることなく切り替えることができます。データの損失。

注: マスター/スレーブ レプリケーションを構築する前に、マスターとなるインスタンスでいくつかの操作 (データ クリーニングなど) を実行し、GTID を介してレプリケートします。マスターとスレーブが確立され、操作はスレーブ サーバーにもコピーされるため、レプリケーションが失敗します。つまり、GTID によるレプリケーションは、これらの操作がレプリケーション前に実行された場合でも、常に最も古いトランザクション ログから開始されます。たとえば、server1 でドロップおよび削除のクリーンアップ操作を実行し、その後、server2 で変更操作を実行すると、server2 は、server1 でクリーンアップ操作も実行します。

GTID の仕組み

トランザクションがメイン ライブラリ側で実行および送信されると、GTID が生成され、binlog ログに記録されます。
1. ビンログがスレーブに転送され、スレーブのリレーログに保存されたら、GTID の値を読み取り、gtid_next 変数を設定します。これにより、次に実行される GTID 値がスレーブに指示されます。
2. SQL スレッドはリレー ログから GTID を取得し、スレーブ側の binlog を比較して GTID が存在するかどうかを確認します。
3. レコードがある場合は、GTID を持つトランザクションが実行されたことを意味し、スレーブはそれを無視します。
4. レコードがない場合、スレーブは GTID トランザクションを実行し、GTID を自身の binlog に記録します。トランザクションを読み取って実行する前に、まず他のセッションが GTID を保持しているかどうかをチェックして、GTID が保持されていることを確認します。繰り返し実行されない。

1 つのマスターと 1 つのスレーブ GTID コピーのセットアップ

ホスト計画:

マスター: docker、ポート 3312
• スレーブ: docker 、ポート 3313

マスター構成

構成ファイル my.cnf の内容は次のとおりです:

$ cat /home/mysql/docker-data/3313/conf/my.cnf
# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.7/en/server-configuration-defaults.html

[mysqld]
#
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
#
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
#
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M
#datadir=/home/mysql/docker-data/3307/data
#socket=/home/mysql/docker-data/3307/mysql.sock

character_set_server=utf8
init_connect='SET NAMES utf8'

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

#log-error=/home/mysql/docker-data/3307/logs/mysqld.log
#pid-file=/home/mysql/docker-data/3307/mysqld.pid
lower_case_table_names=1
server-id=1403311
log-bin=mysql-bin
binlog-format=ROW
auto_increment_increment=1
auto_increment_offset=1
# 开启gtid
gtid_mode=ON
enforce-gtid-consistency=true

#rpl_semi_sync_master_enabled=1
#rpl_semi_sync_master_timeout=10000

Docker インスタンスを作成します:

$ docker run --name mysql3312 -p 3312:3306 --privileged=true -ti -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=order -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -v /home/mysql/docker-data/3312/conf:/etc/mysql/conf.d -v /home/mysql/docker-data/3312/data/:/var/lib/mysql -v /home/mysql/docker-data/3312/logs/:/var/log/mysql -d mysql:5.7

コピーされたユーザーと認証を追加します:

mysql> GRANT REPLICATION SLAVE,FILE,REPLICATION CLIENT ON *.* TO 'repluser'@'%' IDENTIFIED BY '123456';
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

スレーブ構成

構成ファイル my.cnf の内容はマスターと一致しています。それを維持するためにサーバー ID を変更するように注意してください。個性的。

Docker インスタンスの作成:

$ docker run --name mysql3313 -p 3313:3306 --privileged=true -ti -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=order -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -v /home/mysql/docker-data/3313/conf:/etc/mysql/conf.d -v /home/mysql/docker-data/3313/data/:/var/lib/mysql -v /home/mysql/docker-data/3313/logs/:/var/log/mysql -d mysql:5.7

GTID 同期の有効化:

mysql> change master to master_host='172.23.252.98',master_port=3310,master_user='repluser',master_password='123456',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> start slave;
Query OK, 0 rows affected (0.02 sec)

ステータスの表示:

mysql> show master status;
+------------------+----------+--------------+------------------+----------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                      |
+------------------+----------+--------------+------------------+----------------------------------------+
| mysql-bin.000008 |      154 |              |                  | cd2eaa0a-7a59-11ec-b3b4-0242ac110002:1 |
+------------------+----------+--------------+------------------+----------------------------------------+
1 row in set (0.00 sec)

mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 172.23.252.98
                  Master_User: repluser
                  Master_Port: 3312
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000006
          Read_Master_Log_Pos: 419
               Relay_Log_File: 5dfbef024732-relay-bin.000003
                Relay_Log_Pos: 632
        Relay_Master_Log_File: mysql-bin.000006
             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: 419
              Relay_Log_Space: 846
              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: 1403311
                  Master_UUID: cd2eaa0a-7a59-11ec-b3b4-0242ac110002
             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: cd2eaa0a-7a59-11ec-b3b4-0242ac110002:1
            Executed_Gtid_Set: cd2eaa0a-7a59-11ec-b3b4-0242ac110002:1
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

master.order テーブルへのデータの挿入:

mysql> insert into t_order values(4,"V");

データがスレーブに同期されていることがわかりました:

mysql> select * from order.t_order;
+------+------+
| id   | name |
+------+------+
|    4 | V    |
+------+------+
3 rows in set (0.00 sec)

まずスレーブを停止してから、master.order テーブルにデータを挿入します:

mysql> insert into t_order values(5,"X");

次に、スレーブを起動します。データが自動的に同期されていることを確認します。

mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql> select * from order.t_order;
+------+------+
| id   | name |
+------+------+
|    4 | V    |
+------+------+
3 rows in set (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.02 sec)

mysql> select * from order.t_order;
+------+------+
| id   | name |
+------+------+
|    4 | V    |
|    5 | X    |
+------+------+
4 rows in set (0.00 sec)

問題が発生しました

スレーブ サーバーのスレーブ ステータスを表示します:

Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

まず、マスターとスレーブのサーバー ID が一致しているかどうかを確認します。一貫性がある場合は、my.cnf ファイルのserver_id を変更します。フィールド:

mysql> show variables like 'server_id';

次に、マスターとスレーブの uuid が一貫しているかどうかを確認します:

mysql> show variables like '%uuid%';

If the uuid is一貫性を保つには、データ ディレクトリの auto.cnf ファイルを変更し、データ ディレクトリ全体をコピーし、auto.cnf ファイルを置き換えます。これもコピーしました。データベースの uuid が記録されています。各ライブラリの uuid は異なるはずです。

推奨学習: mysql ビデオ チュートリアル

以上がMySQL レプリケーション インスタンス GTID レプリケーションの詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。