So generieren Sie eine eindeutige Server-ID in MySQL

Vorwort

Wir alle wissen, dass MySQL die Server-ID zur eindeutigen Identifizierung einer Datenbankinstanz verwendet und sie in einer verketteten oder Dual-Master-Replikationsstruktur verwendet, um Endlosschleifen von SQL-Anweisungen zu vermeiden. In diesem Artikel erkläre ich mein Verständnis der Server-ID und vergleiche und wäge anschließend mehrere Möglichkeiten zum Generieren einer eindeutigen Server-ID ab.

Zweck der Server-ID

Kurz gesagt hat die Server-ID zwei Zwecke:

1. Wird verwendet, um den Ursprung des Binlog-Ereignisses zu markieren, d. h., woher die SQL-Anweisung stammt.

2. Wird für IO_thread verwendet, um das Binärprotokoll der Hauptbibliothek zu filtern. Wenn replicate-same-server-id=1 nicht festgelegt ist, wird das Ereignis übersprungen und nicht in das Relay-Protokoll geschrieben, wenn der io_thread des Slaves feststellt, dass die Quelle eines Ereignisses mit seiner eigenen Server-ID identisch ist. Der SQL_Thread der Slave-Bibliothek führt das Ereignis natürlich nicht aus. Dadurch können Endlosschleifen von SQL-Anweisungen in einer verketteten oder Dual-Main-Struktur vermieden werden.

Hinweis: Ereignisse mit derselben Server-ID werden auf der io_thread-Ebene gefiltert, während Regeln wie „replicate-(do|ignore)-“ auf der sql_thread-Ebene gefiltert werden. Sowohl io_thread als auch sql_thread haben Filterfunktionen.

Warum kann die Server-ID nicht wiederholt werden?

Wenn die Server-ID im selben Cluster wiederholt wird, können seltsame Probleme auftreten.

Betrachten Sie die folgenden beiden Fälle:

Abbildung 1: Die Server-IDs von Master und Slave sind unterschiedlich, aber zwei oder mehr Slaves haben die gleiche Server-ID

In diesem Fall schwankt die Replikation nach links und rechts. Wenn die Server-IDs der beiden Slave-Bibliotheken gleich sind und Slave-Bibliothek 1 mit der Master-Bibliothek verbunden ist, muss Slave-Bibliothek 2 ebenfalls eine Verbindung mit der Master-Bibliothek herstellen. Wenn festgestellt wird, dass eine vorherige Verbindung mit derselben Server-ID besteht, wird die Verbindung zunächst abgebrochen und dann erneut registriert.

Siehe den folgenden Codeausschnitt:

int register_slave(THD* thd, uchar* Paket, uint Paketlänge)
{
 int-res;
 SLAVE_INFO *si;
...
 wenn (!(si->master_id= uint4korr(p)))
 si->master_id= Server-ID;
 si->thd= thd;
 pthread_mutex_lock(&LOCK_slave_list);
/* Melde dich zuerst von der Verbindung mit der gleichen Server-ID ab*/
 unregister_slave(thd,0,0); 
/* Neu registrieren */
 res = mein_hash_insert(&slave_list, (uchar*) si);
 pthread_mutex_unlock(&LOCK_slave_list);
 Rückgabewert;
...
}

Die beiden Slaves werden ständig registriert und nicht registriert, wodurch viele Relay-Protokolldateien generiert werden. Wenn Sie den Slave-Status überprüfen, werden Sie feststellen, dass sich der Name der Relay-Protokolldatei ständig ändert und der Replikationsstatus des Slaves manchmal „Ja“ und manchmal „Verbinden“ lautet.

Abbildung 2: In einer verketteten oder Dual-Master-Struktur sind die Server-IDs von Master und Slave identisch

Slave 1 ist auch eine Relay-Datenbank. Er kann korrekt synchronisieren und anschließend den Inhalt des Relay-Logs in sein eigenes Binlog umschreiben. Wenn der Slave-2-E/A-Thread mit der Server-ID 100 das Binärprotokoll abruft, stellt er fest, dass der gesamte Inhalt von ihm selbst stammt, und verwirft diese Ereignisse. Daher kann Slave 2 die Daten des Masters nicht korrekt synchronisieren. Nur direkt auf den Relay-Server geschriebene Ereignisse können korrekt mit Slave 2 synchronisiert werden.

Aus den beiden oben genannten Fällen können wir ersehen, dass es sehr wichtig ist, die Eindeutigkeit der Server-ID im selben Replikationssatz beizubehalten.

Dynamische Änderung der Server-ID

Ich habe zufällig entdeckt, dass die Server-ID dynamisch geändert werden kann, aber freuen Sie sich nicht zu früh. Der Vorteil besteht darin, dass im Fall der oben dargestellten Abbildung 1 der Server-ID-Konflikt durch einfaches Ändern der Server-ID eines der Slaves gelöst werden kann. Die Nachteile liegen allerdings sehr versteckt, wie folgender Aufbau zeigt:

Nehmen wir nun an, dass der aktive Master aus irgendeinem Grund die Synchronisierung mit dem passiven Master verliert und am passiven Master einige DDL-Änderungen vorgenommen werden. Dann hatte ein DBA plötzlich die Idee, die Server-ID des Passive-Masters auf 400 zu ändern. Wenn die Dual-Master-Replikation gestartet wird, geraten die zuvor auf dem passiven Master ausgeführten DDL-Änderungen mit der Server-ID 200 in eine Endlosschleife. Wenn es „alter table t engine=innodb“ ist, wird es nie aufhören, vielleicht finden Sie es. Es ist jedoch schwierig für Sie, SQL wie update a=a+1; zu finden. Dieses Szenario ist natürlich nur meine Herstellung.

Ich gebe diese beiden Beispiele nur an, um zu verdeutlichen, dass das Ändern der Server-ID ein wenig gefährlich ist und es besser ist, sie nicht zu ändern. Ist es also möglich, sie in einem Schritt zu generieren?

Generieren Sie eine eindeutige Server-ID

Die am häufigsten verwendeten Methoden sind die folgenden:

1. Verwenden Sie Zufallszahlen

Die Server-ID von MySQL ist eine 4-Byte-Ganzzahl im Bereich von 0 bis 4294967295. Daher ist die Konfliktmöglichkeit bei der Verwendung einer Zufallszahl in diesem Bereich als Server-ID sehr gering.

2. Zeitstempel verwenden

Verwenden Sie Datum +%s direkt, um die Server-ID zu generieren. Wenn wir berechnen, dass ein Tag 86.400 Sekunden hat, und wir für die nächsten 50 Jahre rechnen, beträgt die größte verwendete Server-ID 86.400*365*50, was vollständig innerhalb des Server-ID-Bereichs liegt.

3. IP-Adresse + Port verwenden

Dies ist der Ansatz, den wir häufig verfolgen. Wenn die IP-Adresse beispielsweise 192.168.122.23 und die Portnummer 3309 lautet, kann die Server-ID als 122233309 geschrieben werden. Die Konfliktmöglichkeit ist relativ gering: Sie tritt nur auf, wenn *.*.122.23 oder *.*.12.223 gefunden wird und 3309 mit demselben Replikationssatz erstellt wird.

4. Verwenden Sie einen zentralen Nummerngenerator

Auf dem Verwaltungsserver wird eine selbstinkrementierende ID verwendet, um Server-IDs gleichmäßig zuzuweisen. Dadurch wird sichergestellt, dass es zu keinen Konflikten kommt, allerdings ist die Wartung eines zentralen Knotens erforderlich.

5. Verwalten Sie jeden Replikationssatz separat

Fügen Sie der MySQL-Datenbank in jedem Replikationssatz eine Verwaltungstabelle hinzu, um sicherzustellen, dass es zu keinen Konflikten mit der Server-ID der einzelnen Slave-Datenbanken kommt.

Die oben genannten Methoden sind alle gut, aber:

• Methode 4 erhöht den Wartungsaufwand und es ist etwas mühsam, einen Satz von Nummerngeneratoren für die Entwicklungsumgebung, die Testumgebung und die Onlineumgebung zu verwalten. Das Mischen dieser beiden Methoden kann zu einer Isolation des Netzwerksegments führen und die Ausgabe der Datenbankberechtigungen für Nummerngeneratoren ist schwer zu kontrollieren. Es ist also nicht zu empfehlen.
• Mit Methode 5 wird Autonomie erreicht, die Verwaltungskosten sind jedoch etwas hoch. Die Slave-Datenbank muss in die Server-ID-Tabelle der Master-Datenbank schreiben können, was kompliziert ist.
• Das Problem bei allen fünf Methoden besteht darin, dass bei der Verwendung von Cold-Standby-Daten zur Kapazitätserweiterung die Server-ID manuell geändert werden muss, da es sonst zu Konflikten mit der Server-ID der Cold-Standby-Quelle kommt. Zudem ist beim Start von MySQL nicht erkennbar, ob es gerade per Backup erweitert wurde oder vorher schon normal lief. Sie wissen also nicht, ob Sie die Server-ID ändern müssen. Ich hoffe, dass die Server-ID für den DBA völlig transparent ist und es zu keinen Konflikten kommt, sodass dieses lästige Ding vollständig blockiert wird.

Vorgeschlagener Ansatz

Eigentlich ist es ganz einfach. IPv4 ist eine 4-Byte-Ganzzahl, die den gleichen Bereich wie die Server-ID hat. Wir sind davon überzeugt, dass nur die IP-Adresse + der Port eine MySQL-Instanz eindeutig identifizieren können. Daher versuchen wir stets, sowohl IP-Informationen als auch Port-Informationen in die Server-ID zu integrieren. Vergessen Sie jedoch nicht, dass zwei identische Ports nicht gleichzeitig auf derselben IP gestartet werden können. Daher muss die Server-ID nur in der Ganzzahlform der IP-Adresse vorliegen: select INET_ATON('192.168.12.45'), 3232238637! Bei allen neu gestarteten Instanzen erzwingt das MySQL-Startskript eine Überprüfung der Server-ID. Wird eine falsche Server-ID gefunden, wird diese korrigiert und anschließend gestartet. Diese Methode hat eine Voraussetzung: Mehrere Instanzen auf derselben Maschine sollten keine Master-Slave-Beziehung haben, da sonst dieselbe Server-ID Probleme verursacht. Diese Situation tritt normalerweise nur in einer Testumgebung auf und ist online grundsätzlich nicht zu sehen. Wenn diese Prämisse erfüllt ist, können alle Probleme leicht gelöst werden.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.