1. Hintergrund
Lassen Sie mich auf die Fallstricke der Master-Slave-Replikationsbeschränkungen hinweisen, die beim Projektbetrieb und bei der Wartung auftreten. Die Projektarchitektur besteht aus einem Master-Cluster + einem Disaster-Recovery-Cluster, und jeder Cluster ist ein Master-Slave-Modell. Die Synchronisierung zwischen dem Hauptcluster und dem Disaster-Recovery-Cluster erfolgt über eine Master-Slave-Replikation. Gemäß den Geschäftsanforderungen muss der Disaster-Recovery-Cluster die Systembibliothek und bestimmte Konfigurationstabellen ignorieren, sodass diese Einschränkung ausgelöst wird. Wenn wir auf diese Einschränkung nicht gestoßen sind vorher, dann Es ist auch relativ schwierig zu untersuchen.
2. Beschreibung der Einschränkungen
1. Bei der Master-Slave-Synchronisation ist ein Fehler aufgetreten.
greatsql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.xxx.xxx
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: greatsql-bin.000990
Read_Master_Log_Pos: 92274290
Relay_Log_File: greatsql-relay.002963 -----
Relay_Log_Pos: 701548899
Relay_Master_Log_File: greatsql-bin.000988
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB: mysql,dbscale,dbscale_tmp,information_schema,performance_schema,sys
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table: A.ab,B.bc
Last_Errno: 1146
Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '9e668a93-2618-11ee-93ee-bc16954181bb:47508257' at master log greatdb-bin.000988, end_log_pos 701570116. 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_Master_Log_Pos: 701548690
Relay_Log_Space: 2246320360
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: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1146
Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '9e668a93-2618-11ee-93ee-bc16954181bb:47508257' at master log greatdb-bin.000988, end_log_pos 701570116. 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:
Master_Server_Id: 1943306
Master_UUID: 9e668a93-2618-11ee-93ee-bc16954181bb
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 230822 14:14:18
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 9e668a93-2618-11ee-93ee-bc16954181bb:2-47565802
Executed_Gtid_Set: 30873cfe-8750-11ed-b56f-744aa4073024:1-270,
9e668a93-2618-11ee-93ee-bc16954181bb:1-47508256
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
Dies ist aus den Slave-Statusinformationen ersichtlich
- Die im Fehler gemeldete GTID lautet:
'9e668a93-2618-11ee-93ee-bc16954181bb:47508257' - Das Binlog des Hauptclusters der Anwendung lautet:
greatsql-bin.000988 - Das Relay-Protokoll des Disaster-Recovery-Clusters lautet:
greatsql-relay.002963
performance_schema.replication_applier_status_by_workerDetaillierte Informationsansichtstabelle
2. Überprüfen Sie die Fehlerdetails
greatsql> select * from performance_schema.replication_applier_status_by_worker\G
*************************** 1. row ***************************
CHANNEL_NAME:
WORKER_ID: 1
THREAD_ID: NULL
SERVICE_STATE: OFF
LAST_SEEN_TRANSACTION: 9e668a93-2618-11ee-93ee-bc16954181bb:47508257
LAST_ERROR_NUMBER: 1146
LAST_ERROR_MESSAGE: Worker 1 failed executing transaction
'9e668a93-2618-11ee-93ee-bc16954181bb:47508257' at master log greatdb-bin.000988,
end_log_pos 701570116; Error executing row event: 'Table 'abs_xxx.tmp_xxx_info' doesn't exist'
LAST_ERROR_TIMESTAMP: 2023-08-22 14:14:18
Die obigen Informationen zeigen, dass anhand performance_schema.replication_applier_status_by_workerder detaillierten Fehlerinformationen in der Tabelle festgestellt werden kann, dass die Clustertabelle für die Notfallwiederherstellung abs_xxx.tmp_xxx_infonicht vorhanden ist, was zu einem Synchronisierungsfehler führt.
3. Problemanalyse
3.1. Bestätigen Sie, ob die Zieltabelle im Disaster-Recovery-Cluster vorhanden ist
greatsql> show create table abs_xxx.tmp_xxx_info;
ERROR 1146 (42S02): Table 'abs_xxx.tmp_xxx_info' doesn't exist
greatsql> desc abs_xxx.tmp_xxx_info;
ERROR 1146 (42S02): Table 'abs_xxx.tmp_xxx_info' doesn't exist
**Schlussfolgerung:** Die Zieltabelle im Disaster-Recovery-Cluster existiert nicht
3.2. Analysieren Sie das Binlog des Hauptclusters basierend auf den Master-Slave-Fehlerinformationen und der Fehler-SQL
Analysieren Sie das Binlog des Hauptclusters
SET @@SESSION.GTID_NEXT= '9e668a93-2618-11ee-93ee-bc16954181bb:47508257'/*!*/;
……
#230822 14:14:18 server id 1943306 end_log_pos 701570000 Table_map: `abs_xxx`.`tmp_xxx_info` mapped to number 1595
# at 701570000
#230822 14:14:18 server id 1943306 end_log_pos 701570116 Write_rows: table id 1595 flags: STMT_END_F
### INSERT INTO `abs_xxx`.`tmp_xxx_info`
### SET
### @1=2
### @2='自动化'
### @3='2300121212120000'
### @4='90000000'
### @5='1'
### @6='202001290231001'
### @7='2021-01-31 00:00:00'
# at 701570116
#230822 14:14:18 server id 1943306 end_log_pos 701570143 Xid = 800998400
COMMIT/*!*/;
# at 701570143
#230822 14:14:18 server id 1943306 end_log_pos 701570204 GTID last_committed=26491 sequence_number=26521 rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
**Schlussfolgerung:** Gemäß der kopierten Fehlermeldung können wir die spezifische GTID-Nummer und die Binlog-Datei des Hauptclusters erfahren. Durch das Parsen des Binlogs können wir erfahren, dass es sich bei dieser Transaktion um eine INSERT-Anweisung handelt. Die Zieltabelle im Die Aussage stimmt mit den Informationen in der Tabelle überein performance_schema.replication_applier_status_by_worker.
3.3. Finden Sie heraus, ob im Binlog der Hauptcluster-Zieltabelle eine Tabellenerstellungsanweisung vorhanden ist
Suchen Sie nach Tabellenerstellungsanweisungen im selben Binlog-Protokoll
SET TIMESTAMP=1692684495/*!*/;
CREATE DATABASE IF NOT EXISTS `abs_xxx` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_bin */
/*!*/;
……
use `information_schema`/*!*/;
SET TIMESTAMP=1692684495/*!*/;
CREATE TABLE `abs_xxx`.`tmp_xxx_info` (
`ID` int(64) NOT NULL AUTO_INCREMENT,
`CUSTOMER_NAME` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`CUSTOMER_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`PRODIST_SKU_NUM` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
`STATUS` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
`AGREEMENT_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`END_DATE` datetime DEFAULT NULL,
PRIMARY KEY (`ID`),
KEY `PK_PRODIST_SKU_NUM_AGREEMENT` (`PRODIST_SKU_NUM`) USING BTREE,
KEY `IDX_AGREEMENT_NUM` (`AGREEMENT_NUM`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC
/*!*/;
# at 475864451
**Schlussfolgerung:** Die Tabellenerstellungsanweisung der Zieltabelle wurde im Binlog-Protokoll des Hauptclusters gefunden, was darauf hinweist, dass der Hauptcluster das Binlog-Protokoll beim Ausführen von DDL nicht geschlossen hat. Überprüfen Sie dann weiterhin, ob eine DDL-Anweisung vorhanden ist im Relay-Protokoll des Disaster-Recovery-Clusters.
3.4. Analysieren Sie das Relay-Protokoll des Disaster-Recovery-Clusters und bestätigen Sie, ob es in den Disaster-Recovery-Cluster gezogen wird.
#230822 14:08:15 server id 1943306 end_log_pos 475863662 GTID last_committed=16341 sequence_number=16342 rbr_only=no
SET @@SESSION.GTID_NEXT= '9e668a93-2618-11ee-93ee-bc16954181bb:47498079'/*!*/;
……
use `information_schema`/*!*/;
SET TIMESTAMP=1692684495/*!*/;
CREATE TABLE `abs_xxx`.`tmp_xxx_info` (
`ID` int(64) NOT NULL AUTO_INCREMENT,
`CUSTOMER_NAME` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`CUSTOMER_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`PRODIST_SKU_NUM` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
`STATUS` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
`AGREEMENT_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`END_DATE` datetime DEFAULT NULL,
PRIMARY KEY (`ID`),
KEY `PK_PRODIST_SKU_NUM_AGREEMENT` (`PRODIST_SKU_NUM`) USING BTREE,
KEY `IDX_AGREEMENT_NUM` (`AGREEMENT_NUM`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC
/*!*/;
# at 475864660
#230822 14:08:15 server id 1943306 end_log_pos 475864512 GTID last_committed=16342 sequence_number=16343 rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
**Schlussfolgerung:** Im Relay-Protokoll des Disaster-Recovery-Clusters gibt es eine Anweisung zur Erstellung einer DDL-Tabelle, die darauf hinweist, dass kein Problem mit dem E/A-Thread vorliegt.
3.5. Überprüfen Sie die ignorierte Bibliothekstabelle der Replikationskonfiguration
Replicate_Ignore_DB: mysql,dbscale,dbscale_tmp,information_schema,performance_schema,sys
Replicate_Wild_Ignore_Table: A.ab,B.bc
**Schlussfolgerung:** Die Zieltabelle ist nicht in der ignorierten Bibliothekstabelle enthalten. Gemäß dem oben analysierten Protokoll wurde jedoch festgestellt, dass im Binlog-Protokoll des Hauptclusters eine Anweisung vor der Tabellenerstellungsanweisung vorhanden ist. Diese Bibliothek use information_schema/!/; ist Eine Systembibliothek, die von der Synchronisierung ignoriert wird und daher die Spezifikationseinschränkungen von GreatSQL auslöst. Das Aufzeichnen von Anweisungen im Anweisungsmodus funktioniert standardmäßig nicht für Vorgänge, die in der Ignorierungsbibliothek nicht ignoriert werden (Details: https://dev.mysql.com/doc) . /refman/5.7/en/replication-options-replica.html#option_mysqld_replicate-do-db)
4. Beheben Sie Synchronisierungsfehler
Erstellen Sie eine Zieltabelle im Disaster-Recovery-Cluster
greatsql> CREATE TABLE `abs_xxx`.`tmp_xxx_info` (
`ID` int(64) NOT NULL AUTO_INCREMENT,
`CUSTOMER_NAME` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`CUSTOMER_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`PRODIST_SKU_NUM` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
`STATUS` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
`AGREEMENT_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`END_DATE` datetime DEFAULT NULL,
PRIMARY KEY (`ID`),
KEY `PK_PRODIST_SKU_NUM_AGREEMENT` (`PRODIST_SKU_NUM`) USING BTREE,
KEY `IDX_AGREEMENT_NUM` (`AGREEMENT_NUM`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC;
greatsql> stop slave;
greatsql> start slave;
**Schlussfolgerung:** Nach der Erstellung der Zieltabelle im Disaster-Recovery-Cluster waren Replikation und Wiederherstellung erfolgreich.
3. Vermeidung von Beschränkungen
1. Der erste Weg, dies zu vermeiden
Geben Sie beim Ausführen von DDL die Zielbibliothek ein
greatsql> use abs_cust
greatsql> DDL 语句（CREATE\DROP\ALTER）
**Hinweis:** Wenn die Anwendung eine Verbindung zur Datenbank herstellt, verwendet sie möglicherweise standardmäßig information_schemadie Bibliothek, und diese Umgebung ignoriert alle Systembibliotheken. Um ähnliche Probleme zu vermeiden, verwenden Sie daher bitte die Zielbibliothek der Zieltabelle, bevor Sie ausführen SQL-Anweisung.
2. Der zweite Weg, dies zu vermeiden
Ändern Sie die Master-Slave-Replikationskonfiguration. Die folgenden Schritte gelten für die Testumgebung
Fahren Sie den Disaster-Recovery-Cluster während der Replikationssynchronisierung herunter
greatsql> stop slave;
Query OK, 0 rows affected, 1 warning (0.03 sec)
Ändern Sie die Ignorierbibliothek
greatsql> change replication filter Replicate_Ignore_DB=();
Ignoriertabelle ändern
greatsql> change replication filter replicate_wild_ignore_table =('mysql.%','information_schema.%','sys.%','performance_schema.%');
Starten Sie die Synchronisierung
greatsql> start slave;
Query OK, 0 rows affected, 1 warning (0.37 sec)
Testverifizierung
Hauptcluster:
greatsql> use mysql
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
greatsql> create table test111.test111(id int primary key);
Query OK, 0 rows affected (0.06 sec)
greatsql> show tables;
+-------------------+
| Tables_in_test111 |
+-------------------+
| test111 |
+-------------------+
1 row in set (0.00 sec)
Disaster-Recovery-Cluster:
greatsql> use test111
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
greatsql> show tables;
+-------------------+
| Tables_in_test111 |
+-------------------+
| test111 |
+-------------------+
1 row in set (0.00 sec)
**Hinweis:** Wenn die Parameter in der Kopierkonfiguration Replicate_Ignore_DBauf leer gesetzt sind, können ähnliche Probleme auch vermieden werden , indem replicate_wild_ignore_tabledie Parameter auf gesetzt werdenshema_name.%
4. Besondere Anweisungen
- Diese Einschränkung besteht auch in den MySQL-Versionen 5.7 und 8.0
Viel Spaß mit GreatSQL :)
Über GreatSQL
GreatSQL ist eine inländische unabhängige Open-Source-Datenbank, die für Anwendungen auf Finanzebene geeignet ist. Sie verfügt über viele Kernfunktionen wie hohe Leistung, hohe Zuverlässigkeit, hohe Benutzerfreundlichkeit und hohe Sicherheit. Sie kann als optionaler Ersatz für MySQL oder Percona Server verwendet werden und wird in Online-Produktionsumgebungen verwendet. , völlig kostenlos und kompatibel mit MySQL oder Percona Server.
Verwandte Links: GreatSQL Community Gitee GitHub Bilibili
GreatSQL-Community:
Vorschläge und Feedback zu Community-Belohnungen: https://greatsql.cn/thread-54-1-1.html
Details zur preisgekrönten Einreichung des Community-Blogs: https://greatsql.cn/thread-100-1-1.html
(Wenn Sie Fragen zu dem Artikel haben oder einzigartige Erkenntnisse gewinnen möchten, können Sie diese auf der offiziellen Community-Website stellen oder teilen~)
Technische Austauschgruppe:
WeChat- und QQ-Gruppe:
QQ-Gruppe: 533341697
WeChat-Gruppe: Fügen Sie GreatSQL Community Assistant (WeChat-ID:) wanlidbcals Freund hinzu und warten Sie, bis der Community-Assistent Sie der Gruppe hinzufügt.