GA

2023/03/11

MySQL 8.0ならGTIDのスキップはもっと簡単になる

TL;DR


とはいえそもそもSQL Threadが止まってイベントをスキップしなければならないような事態になったら、レプリカを真っ新に作り直した方が良いというのは相変わらず思っている。
MySQL 8.0ならCloneプラグインもあるしね。

slave1 [localhost] {msandbox} ((none)) > SHOW REPLICA STATUS\G
*************************** 1. row ***************************
             Replica_IO_State: Waiting for source to send event
                  Source_Host: 127.0.0.1
                  Source_User: rsandbox
                  Source_Port: 25440
                Connect_Retry: 60
              Source_Log_File: mysql-bin.000002
          Read_Source_Log_Pos: 586561
               Relay_Log_File: mysql-relay.000002
                Relay_Log_Pos: 315878
        Relay_Source_Log_File: mysql-bin.000002
           Replica_IO_Running: Yes
          Replica_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1396
                   Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '00025440-1111-1111-1111-111111111111:758' at master log mysql-bin.000002, end_log_pos 315888. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
                 Skip_Counter: 0
          Exec_Source_Log_Pos: 315662
              Relay_Log_Space: 586983
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Source_SSL_Allowed: No
           Source_SSL_CA_File:
           Source_SSL_CA_Path:
              Source_SSL_Cert:
            Source_SSL_Cipher:
               Source_SSL_Key:
        Seconds_Behind_Source: NULL
Source_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1396
               Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '00025440-1111-1111-1111-111111111111:758' at master log mysql-bin.000002, end_log_pos 315888. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
  Replicate_Ignore_Server_Ids:
             Source_Server_Id: 1
                  Source_UUID: 00025440-1111-1111-1111-111111111111
             Source_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
    Replica_SQL_Running_State:
           Source_Retry_Count: 86400
                  Source_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp: 230311 12:03:58
               Source_SSL_Crl:
           Source_SSL_Crlpath:
           Retrieved_Gtid_Set: 00025440-1111-1111-1111-111111111111:1-1406
            Executed_Gtid_Set: 00025440-1111-1111-1111-111111111111:1-757
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Source_TLS_Version:
       Source_public_key_path:
        Get_Source_public_key: 0
            Network_Namespace:
1 row in set (0.00 sec)

たとえばこんなの。
00025440-1111-1111-1111-111111111111:758 のイベントが「本当にスキップしてよいものなのかどうか」をよく確認した上でスキップするには、

ドキュメントにも紹介されている手順

SET SESSION gtid_next = '00025440-1111-1111-1111-111111111111:758';
COMMIT;
SET SESSION gtid_next = AUTOMATIC;
START REPLICA sql_thread;

gitd_purgedで直接いじる手順

SET GLOBAL gtid_purged = '+00025440-1111-1111-1111-111111111111:758';
START REPLICA sql_thread;

複数のgtidを一気に飛ばさないといけない場合はきっと後者の方が楽(ただ複数のgtidを本当に飛ばして良いのかなんて調べるのが大変なので、やっぱりCLONEなりなんなりで作り直した方が良いと思うの)

0 件のコメント :

コメントを投稿