ホームページ > データベース > mysql チュートリアル > MySQL GTID レプリケーションを適用する方法

MySQL GTID レプリケーションを適用する方法

PHPz
リリース: 2023-05-27 11:25:43
転載
686 人が閲覧しました

MySQL GTID レプリケーションを適用する方法

MySQL 5.6.5 以降、グローバル トランザクション識別子 (GTID) ベースのレプリケーション方法が導入されました。 GTID により、クラスター内のメイン データベースに送信されるすべてのトランザクションが一意の識別子を持つことが保証されます。この方法により、データベースのプライマリおよびセカンダリの整合性、障害回復、および耐障害性の機能が強化されます。

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 の仕組み

  1. #トランザクションがメイン ライブラリ側で実行および送信されると、GTID が生成され、バイナリ ログに記録されます。ログ。

  2. ビンログがスレーブに転送され、スレーブのリレーログに保存されたら、GTID の値を読み取り、gtid_next 変数を設定します。これにより、次に実行される GTID 値がスレーブに指示されます。 。

  3. SQL スレッドはリレー ログから GTID を取得し、スレーブ側の binlog を比較して GTID が存在するかどうかを確認します。

  4. レコードがある場合は、GTID のトランザクションが実行されたことを意味し、スレーブはそれを無視します。

  5. レコードがない場合、スレーブは GTID トランザクションを実行し、GTID を自身の binlog に記録します。トランザクションを読み取って実行する前に、最初に他のセッションがそのトランザクションを保持しているかどうかを確認します。繰り返し実行されないことを保証するための 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 GTID レプリケーションを適用する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

関連ラベル:
ソース:yisu.com
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
最新の問題
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート