MySQL Online-DDL-Tool Gh-Ost-Prinzipanalyse

1. Einleitung

gh-ost basiert auf der Sprache Golang und ist ein Open-Source-DDL-Tool von GitHub. Es ist die Abkürzung für GitHubs Online Schema Transmogrifier/Transfigurator/Transformer/Thingy, was GitHubs Online-Tabellendefinitionskonverter bedeutet.

1.1 Grundsatz

Das Hauptimplementierungsprinzip besteht darin, zuerst zwei Tabellen zu erstellen, eine ist die Schattentabelle _gho. gh-ost wendet die ursprünglichen Tabellendaten und inkrementellen Daten auf diese Tabelle an und wechselt schließlich den Tabellennamen zwischen dieser Tabelle und der ursprünglichen Tabelle. Die andere ist die _ghc-Tabelle, in der die Änderungsprotokolldaten gespeichert sind, einschließlich Signalmarkierungen, Heartbeats usw. Zweitens startet gh-ost zwei Goroutinen, eine zum Kopieren der ursprünglichen Tabellendaten und die andere zum Anwenden des inkrementellen Binärprotokolls auf die _gho-Tabelle. Die beiden Goroutinen laufen parallel, was bedeutet, dass Sie sich keine Gedanken darüber machen müssen, ob zuerst die Daten kopiert oder zuerst das Binärprotokoll angewendet wird. Da die Insert-Anweisung hier angepasst wird, wird zuerst das von uns kopierte Insert in „Insert ignore into“ und das Insert in „Insert ignore into“ und dann das Insert in „Insert replace into“ umgeschrieben, was die Parallelisierung der beiden Goroutinen gut unterstützen kann. Aber können solche Anpassungen auf alle DDLs angewendet werden? Die Antwort ist nein. Sobald alle ursprünglichen Tabellendaten kopiert wurden, tritt gh-ost schließlich in die Tabellenaustauschphase ein und verwendet dabei einen sichereren atomaren Austausch.

1.2 Prozess

1. Suchen Sie nach Fremdschlüsseln und Auslösern.
2. Überprüfen Sie die Primärschlüsselinformationen der Tabelle.
3. Überprüfen Sie, ob es sich um eine Master- oder Slave-Datenbank handelt, ob log_slave_updates aktiviert ist und ob Binlog-Informationen vorhanden sind
4. Überprüfen Sie, ob die temporäre Tabelle mit der Endung gho und del vorhanden ist
5. Erstellen Sie eine Tabelle mit der Endung „ghc“, um Datenmigrationsinformationen, Binlog-Informationen usw. zu speichern.
--- Die obige Überprüfungsphase
6. Initialisieren Sie die Stream-Verbindung und fügen Sie die Binlog-Überwachung hinzu
--- Die folgenden Migrationsphasen
7. Erstellen Sie eine temporäre Tabelle mit der Endung gho und führen Sie DDL auf der temporären Tabelle mit der Endung gho aus.
8. Starten Sie eine Transaktion, schreiben Sie die Daten der Quelltabelle entsprechend der Primärschlüssel-ID in die Tabelle mit der Endung „gho“, übermitteln Sie sie und wenden Sie Binlog an.
---Die folgende Umstellungsphase
9. Sperren Sie die Quelltabelle und benennen Sie die Tabelle um: Benennen Sie die Quelltabelle in die Tabelle „source_del“ und die Tabelle „gho“ in die Quelltabelle um.
10. Bereinigen Sie die GHC-Tabellen.

1.3 Funktionen

1. Kein Auslöser: Überwachen Sie Datenänderungen in der Tabelle, indem Sie Binlog-Protokolle analysieren.

2. Leichtgewichtig: Da keine Trigger verwendet werden, ist die Auswirkung auf die Hauptdatenbank während des Vorgangs minimal und Sie müssen sich keine Gedanken über Parallelität und Sperren machen.

3. Pausierbar: Alle Schreibvorgänge werden von gh-ost gesteuert. Bei Ratenbegrenzung kann gh-ost das Schreiben von Daten auf den Master pausieren, eine interne Tracking-Tabelle erstellen und Heartbeat-Ereignisse mit minimalem Systemaufwand in diese Tabelle schreiben.

4. Dynamische Steuerung: gh-ost kann über eine Unix-Socket-Datei oder einen TCP-Port (konfigurierbar) auf Anfragen warten und der Operator kann die entsprechenden Parameter ändern, nachdem der Befehl ausgeführt wurde.

5. Überprüfbar: Über die Programmschnittstelle können Sie den Status von gh-ost abrufen, den aktuellen Fortschritt, die Konfiguration der wichtigsten Parameter, die aktuelle Serveridentifikation usw. melden.

6. Testbar: gh-ost verfügt über integrierte Unterstützung für Tests, die mit dem Flag --test-on-replica angegeben werden können: Es werden Mutationen an der Replik durchgeführt, an deren Ende gh-ost die Replikation stoppt, die Tabelle austauscht, den Austausch rückgängig macht, beide Tabellen synchron hält und die Replikation stoppt. Sie können die Daten der beiden Tabellen in Ruhe testen und vergleichen.

1.4 GitHub-Adresse

https://github.com/github/gh-ost/

2. Testumgebung:

2.1 Testserver

Hauptdatenbank: 110.119.120.231

Aus der Bibliothek: 110.119.120.230

2.2 Installation

cd /usr/local/src/

wget https://github.com/github/gh-ost/releases/download/v1.0.48/gh-ost-binary-linux20190214020851.tar.gz

tar xzvf gh-ost-binary-linux-20190214020851.tar.gz -C /usr/local/
ln -s /usr/local/gh-ost /usr/bin/gh-ost

2.3 Einen Benutzer anlegen

Erstellen Sie den Benutzer ghost@'110.%', identifiziert durch 'ghost';

gewähre ghost@'110.%' ALLE PRIVILEGIEN für *.*;

Berechtigungen leeren;

2.4 Befehlsparameter

Verwendung von gh-ost:
 --aliyun-rds: Gibt an, ob die Ausführung in der Alibaba Cloud-Datenbank erfolgen soll. WAHR
 --allow-master-master: Gibt an, ob gh-ost in einer Dual-Master-Replikationsarchitektur ausgeführt werden darf. Wird im Allgemeinen zusammen mit dem Parameter -assume-master-host verwendet. --allow-nullable-unique-key: Erlaubt gh-ost, den eindeutigen Schlüssel, von dem die Datenmigration abhängt, als NULL zuzulassen. Standardmäßig sind eindeutige NULL-Schlüssel nicht zulässig. Wenn der eindeutige Schlüssel, auf den sich die Datenmigration stützt, NULL-Werte zulässt, können falsche Daten entstehen. Gehen Sie daher mit Vorsicht damit um.
 --allow-on-master: Erlaubt, dass gh-ost direkt auf dem Master ausgeführt wird. Der Standard-Slave, mit dem sich gh-ost verbindet. Darüber hinaus ist für DDL auf einer einzelnen Instanz eine einzelne Instanz gleichbedeutend mit einer Masterdatenbank und der Parameter --allow-on-master und der ROW-Modus müssen aktiviert sein.
 --alter string:DDL-Anweisung --approve-renamed-columns ALTER: Wenn Sie den Namen einer Spalte ändern, erkennt gh-ost dies und fragt nach einem Grund für die Spaltenumbenennung. Standardmäßig fährt gh-ost nicht fort, es sei denn, Sie geben --approve-renamed-columns ALTER an.
 --ask-pass:MySQL-Passwort --assume-master-host string:Geben Sie eine Masterdatenbank für gh-ost im Format „IP:Port“ oder „Hostname:Port“ an. Dies ist in einer Master-Master-Architektur nützlich oder wenn gh-ost den Master nicht finden kann.
 --assume-rbr: Wenn binlog_format=ROW für die Datenbankinstanz festgelegt ist, mit der gh-ost verbunden ist, können Sie -assume-rbr angeben. Dadurch wird verhindert, dass „Stop Slave“ und „Start Slave“ auf dem Slave ausgeführt werden, und der gh-ost-Benutzer benötigt zum Ausführen nicht das SUPER-Privileg.
 --check-flag
 --chunk-size int: Anzahl der in jeder Iteration zu verarbeitenden Zeilen (zulässiger Bereich: 100–100000), Standardwert ist 1000.
 --concurrent-rowcount: Wenn dieser Parameter True (Standard) ist, schätzt gh-ost nach dem Kopieren der Zeilen die Anzahl der Zeilen (mit „explain select count(*)“) und passt die ETA an. Andernfalls schätzt gh-ost zuerst die Anzahl der Zeilen und beginnt dann mit dem Kopieren der Zeilen.
 --conf string: Pfad der gh-ost-Konfigurationsdatei.
 --critical-load string: Eine durch Kommas getrennte Liste von Statusnamen=Werten. Wenn der MySQL-Status die entsprechenden Werte überschreitet, wird gh-ost beendet. -critical-load Threads_connected=20,Connections=1500 bedeutet, dass gh-ost aufgrund der kritischen Belastung der Datenbank angehalten und beendet wird, wenn die Statuswerte in MySQL Threads_connected>20,Connections>1500 sind.
 Durch Komma getrennter Statusname=Schwellenwert, gleiches Format wie --max-load. Wenn der Status den Schwellenwert überschreitet, gerät die App in Panik und wird beendet.
 --critical-load-hibernate-seconds int: Wenn die kritische Last erreicht ist, wechselt gh-ost für die angegebene Zeit in den Ruhezustand. Es wird von keinem Server etwas gelesen/geschrieben.
 --critical-load-interval-millis int: Wenn der Wert 0 ist, wird gh-ost sofort beendet, wenn die kritische Last erreicht ist. Wenn der Wert nicht 0 ist, prüft gh-ost nach -critical-load-interval-millis Sekunden erneut, ob die kritische Last erreicht ist. Wenn die kritische Last nach der zweiten Prüfung immer noch erreicht ist, wird gh-ost beendet.
 --cut-over string: Wählen Sie den Cutover-Typ: atomar/zweistufig. Der atomare (Standard-) Cutover-Typ verwendet den GitHub-Algorithmus und der zweistufige Typ den Facebook-OSC-Algorithmus.
 --cut-over-exponential-backoff
 --cut-over-lock-timeout-seconds int: Die maximale Wartezeit für die Sperre während der Cutover-Phase von gh-ost. Wenn die Sperre abläuft, versucht gh-ost den Cutover erneut. (Standard: 3)
 --database string: Datenbankname.
 --debug: Debug-Modus.
 --default-retries int: Die Anzahl der Wiederholungsversuche verschiedener Vorgänge, bevor eine Panik ausgelöst wird. (Standard ist 60)
 --discard-foreign-keys: Dieser Parameter ist für eine Tabelle mit Fremdschlüsseln. Wenn gh-ost eine Ghost-Tabelle erstellt, werden keine Fremdschlüssel für die Ghost-Tabelle erstellt. Dieser Parameter ist zum Löschen von Fremdschlüsseln nützlich, sollte ansonsten aber mit Vorsicht verwendet werden.
 --dml-batch-size int: Batchgröße zum Anwenden von DML-Ereignissen in einer einzelnen Transaktion (Bereich 1–100) (Standard 10)
 --exact-rowcount: Zählen Sie die Anzahl der Tabellenzeilen genau (mithilfe von select count(*)), um eine genauere Schätzung der Zeit zu erhalten.
 --execute: führt „alter & migrate table“ tatsächlich aus. Der Standardwert ist „noop“, was bedeutet, dass keine Ausführung erfolgt. Einfach testen und beenden. Wenn Sie möchten, dass die ALTER TABLE-Anweisung tatsächlich in der Datenbank implementiert wird, müssen Sie explizit „-execute“ angeben.
 --exponential-backoff-max-interval int
 --force-named-cut-over: Wenn wahr, muss der interaktive Befehl „unpostpone | cut-over“ die migrierte Tabelle benennen. --force-table-names string: Tabellennamenpräfix, das für temporäre Tabellen verwendet werden soll. --heartbeat-interval-millis int: gh-ost-Heartbeat-Frequenzwert, Standard ist 500.
 --helfen
 --hooks-hint string: beliebige Nachrichten, die über GH_OST_HOOKS_HINT in Hooks eingefügt werden --hooks-path string: Verzeichnis, in dem Hook-Dateien gespeichert werden (Standard ist leer, d. h. Hooks sind deaktiviert). Der Hook sucht in diesem Verzeichnis nach einer Hook-Datei mit derselben Namenskonvention zur Ausführung.
 --host Zeichenfolge: MySQL IP/Hostname
 --initially-drop-ghost-table: Überprüfen und löschen Sie vorhandene Ghost-Tabellen vor dem Ghost-Ost-Vorgang. Dieser Parameter wird nicht empfohlen. Bitte verarbeiten Sie die vorhandene Ghost-Tabelle manuell. Standardmäßig ist dieser Parameter nicht aktiviert und gh-ost beendet den Vorgang.
 --initially-drop-old-table: Vor dem Gh-Ost-Vorgang die vorhandene alte Tabelle prüfen und löschen. Dieser Parameter wird nicht empfohlen. Bitte verarbeiten Sie die vorhandene Ghost-Tabelle manuell. Standardmäßig ist dieser Parameter nicht aktiviert und gh-ost beendet den Vorgang.
 --initially-drop-socket-file:gh-ost löscht zwangsweise eine vorhandene Socket-Datei. Dieser Parameter wird nicht empfohlen und kann ein laufendes Ghost-Ost-Programm löschen, was zu DDL-Fehlern führt.
 --master-password string:MySQL-Masterkennwort --master-user string:MySQL-Masterkonto --max-lag-millis int:Maximale Verzögerungszeit der Master-Slave-Replikation. Wenn die Verzögerungszeit der Master-Slave-Replikation diesen Wert überschreitet, ergreift gh-ost Drosselungsmaßnahmen. Standardwert: 1500 s.
 --max-load Zeichenfolge: durch Komma getrennter Statusname = Schwellenwert, z. B.: „Threads_running=100,Threads_connected=500“. Wenn der Status den Schwellenwert überschreitet, drosselt die App die Schreibvorgänge.
 --migrate-on-replica: gh-ost führt die Migration auf der Replik aus, nicht auf dem Master. 
 --nice-ratio float: Die Ruhezeit für jeden Chunk-Zeitraum im Bereich [0,0…100,0]. 0: Keine Ruhezeit in den einzelnen Blockperioden, das heißt, ein Block wird nach dem anderen ausgeführt; 1: Für jede Zeilenkopie zusätzlich 1 Millisekunde ruhen; 0,7: Für jede Zeilenkopie von 10 Millisekunden zusätzlich 7 Millisekunden ruhen.
 --ok-to-drop-table: Nachdem der Gh-Ost-Vorgang abgeschlossen ist, wird die alte Tabelle gelöscht. Standardmäßig wird die alte Tabelle nicht gelöscht und die Tabelle _tablename_del bleibt bestehen.
 --panic-flag-file string: Wenn diese Datei erstellt wird, wird gh-ost sofort beendet.
 --password string: MySQL-Passwort --port int: MySQL-Port, vorzugsweise vom Slave --postpone-cut-over-flag-file string: Wenn diese Datei vorhanden ist, wird die Cut-Over-Phase von gh-ost verschoben und die Daten werden weiterhin repliziert, bis die Datei gelöscht wird.
 --quiet: Leiser Modus.
 --replica-server-id uint : Server-ID von gh-ost
 --replication-lag-query string: Veraltet --serve-socket-file string: Absoluter Pfad zur Socket-Datei von gh-ost.
 --serve-tcp-port int: Für GH-OST zu verwendender Port. Standardmäßig wird ein geschlossener Port verwendet.
 --skip-foreign-key-checks: Auf „true“ setzen, wenn Sie sicher sind, dass Ihre Tabelle keine Fremdschlüssel enthält, und die Ghost-Key-Validierung überspringen möchten.
 --skip-renamed-columns ALTER: Wenn Sie den Namen einer Spalte ändern (z. B. „Spalte ändern“), erkennt gh-ost dies und fragt nach einem Grund für die Spaltenumbenennung. Standardmäßig führt gh-ost den Befehl nicht aus. Dieser Parameter weist gh-ost an, die Migration der Spalte zu überspringen und die umbenannte Spalte als „Don’t Care“-Spalte zu behandeln. Dieser Vorgang ist gefährlich, Sie verlieren alle Werte in der Spalte.
 --stack: Fehler-Stacktrace hinzufügen.
 --switch-to-rbr: Weisen Sie gh-ost an, das Binlog-Format des Slave-Repositorys automatisch auf das ROW-Format umzustellen.
 --table string: Tabellenname --test-on-replica: Testen Sie Gh-Ost auf dem Slave, einschließlich der Datenmigration auf dem Slave. Nachdem die Datenmigration abgeschlossen ist, stoppen Sie den Slave und tauschen Sie die Originaltabelle sofort mit der Ghost-Tabelle aus und tauschen Sie sie dann sofort wieder zurück. Stoppen Sie den Slave weiterhin, damit Sie die beiden Tabellen vergleichen können.
 --test-on-replica-skip-replica-stop: Wenn -test-on-replica ausgeführt wird, bedeutet dieser Parameter, dass der Slave während des Vorgangs nicht gestoppt werden muss.
 --throttle-additional-flag-file string: Wenn diese Datei erstellt wird, wird der Gh-Ost-Vorgang sofort beendet. Dieser Parameter kann verwendet werden, wenn mehrere Gh-Ost-Operationen gleichzeitig ausgeführt werden, um eine Datei zu erstellen und alle Gh-Ost-Operationen zu stoppen oder die Datei zu löschen und alle Gh-Ost-Operationen fortzusetzen.
 --throttle-control-replicas string: Listet alle Slave-Bibliotheken auf, die auf Verzögerungen bei der Master-Slave-Replikation überprüft werden müssen.
 --throttle-flag-file string: Wenn diese Datei erstellt wird, wird der Gh-Ost-Vorgang sofort beendet. Dieser Parameter eignet sich zur Steuerung eines einzelnen Ghost-Vorgangs. Die Zeichenfolge -throttle-additional-flag-file eignet sich zum Steuern mehrerer Gh-Ost-Operationen.
 --throttle-http-Zeichenfolge
 --throttle-query-Zeichenfolge: Abfrage drosseln. Wird einmal pro Sekunde ausgeführt. Wenn der Rückgabewert = 0 ist, ist keine Drosselung erforderlich. Wenn der Rückgabewert > 0 ist, muss eine Drosselung durchgeführt werden. Diese Abfrage wird auf dem migrierten Server ausgeführt. Stellen Sie daher sicher, dass sie leicht ist.
 --timestamp-old-table: Zeitstempel in alten Tabellennamen verwenden. Dadurch wird die Cross-Migration alter Tabellennamen eindeutig und konfliktfrei. --tungsten: Informiert gh-ost, dass Sie eine Tungsten-Replikationstopologie ausführen.
 --user string:MYSQL-Benutzer --verbose
 --Version

3. Betriebsmodus

Modus 1: Verbindung zur Slave-Datenbank herstellen und Änderungen in der Master-Datenbank vornehmen

Dies ist der Standardmodus, in dem gh-ost nach Slaves sucht, den Master des Clusters findet und eine Verbindung zu ihm herstellt. Die spezifischen Schritte für den Änderungsvorgang sind:

1. Lesen und Schreiben von Zeilendaten in der Masterdatenbank;

2. Lesen Sie Binärprotokollereignisse in der Slave-Datenbank und wenden Sie die Änderungen auf die Master-Datenbank an.

3. Überprüfen Sie das Tabellenformat, die Felder, den Primärschlüssel, die Gesamtzahl der Zeilen usw. in der Slave-Datenbank.

4. Lesen Sie die internen Ereignisprotokolle von gh-ost (z. B. Heartbeats) auf dem Slave.

5. Schließen Sie den Tabellenwechsel in der Hauptdatenbank ab.

Wenn Ihr Hauptdatenbankprotokollformat SBR ist, kann das Tool auch normal funktionieren. Der Slave muss jedoch mit aktivierter binärer Protokollierung (log_bin, log_slave_updates) und binlog_format=ROW konfiguriert sein (gh-ost ist eine Binärdatei, die vom Slave liest).

Anwendungsbeispiel:

# gh-ost --initially-drop-old-table --initially-drop-ghost-table --user="ghost" --password="ghost" --host=110.119.120.230 --port=3306 --database="test" --table="t1" --verbose --alter="ADD COLUMN y1 varchar(10),add column y2 int not null default 0 comment 'test' " --assume-rbr --execute

Bedeutung der Parameter:

--initially-drop-old-table: Überprüft und löscht vorhandene alte Tabellen vor dem Ghettoblaster-Vorgang.

--initially-drop-ghost-table: Überprüfen und löschen Sie vorhandene Ghost-Tabellen vor dem Ghost-Ost-Vorgang.

--verbose: Ausgabeprotokoll des Ausführungsprozesses

--assume-rbr: Wenn binlog_format=ROW für die Datenbankinstanz festgelegt ist, mit der gh-ost verbunden ist, können Sie -assume-rbr angeben. Dadurch wird vermieden, dass auf dem Slave „stop slave“ und „start slave“ ausgeführt werden. Der Benutzer, der gh-ost ausführt, benötigt das SUPER-Privileg nicht.

Modus 2: Direkte Änderungen in der Hauptdatenbank

Wenn keine Slave-Bibliothek vorhanden ist oder Sie die Slave-Bibliothek nicht bearbeiten möchten, können Sie die Master-Bibliothek direkt verwenden. gh-ost führt alle Vorgänge direkt auf dem Master aus. Sie können oben immer noch die Verzögerung der Master-Slave-Replikation sehen.

1) Die Masterdatenbank muss Binärprotokolle im Zeilenformat generieren

2) Sie müssen beim Starten von gh-ost die Option --allow-on-master verwenden, um diesen Modus zu aktivieren.

# gh-ost --initially-drop-old-table --initially-drop-ghost-table --user="ghost" --password="ghost" --host="110.119.120.231" --port=3306 --database="test" --table="t2" --verbose --alter="Spalte Testfeld varchar(256) Standardwert hinzufügen '';" --exact-rowcount --serve-socket-file=/tmp/gh-ost.t2.sock --panic-flag-file=/tmp/ghost.panic.t2.flag --postpone-cut-over-flag-file=/tmp/ghost.postpone.t2.flag --allow-on-master --execute

Bedeutung der Parameter:

--exact-rowcount: Zählen Sie die Anzahl der Tabellenzeilen genau (mithilfe von select count(*)), um eine genauere Schätzung der Zeit zu erhalten.

--serve-socket-file: Der absolute Pfad zur gh-ost-Socket-Datei. Beispiel: --serve-socket-file=/tmp/gh-ost.t1.sock erstellt eine Socket-Datei zum Abhören und passt Parameter über die Schnittstelle an. Wenn die Last und die Latenz während des Vorgangs zunehmen, muss der Vorgang beendet und Parameter wie die Chunk-Größe neu konfiguriert werden. Anschließend kann der Vorgangsbefehl erneut ausgeführt werden. Dynamische Anpassungen können über die Socket-Schnittstelle vorgenommen werden.

#Pause

Echo-Drosselung | socat – /tmp/gh-ost.t1.sock

#genesen

socat - /tmp/gh-ost.t1.sock

Ändern Sie die Geschwindigkeitsbegrenzungsparameter:

echo chunk-size=1500 | socat - /tmp/gh-ost.t1.sock
echo max-lag-millis=2000 | socat - /tmp/gh-ost.t1.sock

echo max-load=Thread_running=30 | socat - /tmp/gh-ost.t1.sock

--panic-flag-file: Diese Datei wird erstellt, um den laufenden Gh-Ost sofort zu beenden. Die temporäre Dateibereinigung muss manuell durchgeführt werden.

--postpone-cut-over-flag-file: Wenn diese Datei existiert, wird die Cutover-Phase von gh-ost verschoben. Daten werden zwar noch kopiert, aber die Tabelle wird erst umgeschaltet, wenn diese Datei gelöscht wird.

--allow-on-master: Erlaubt, dass gh-ost direkt auf dem Master ausgeführt wird.

Modus 3: Ändern und Testen auf dem Slave

In diesem Modus werden Änderungen an der Slave-Datenbank vorgenommen. Alle Vorgänge werden an der Slave-Datenbank ausgeführt und haben keine Auswirkungen auf die Master-Datenbank. Während des Vorgangs wird gh-ost auch von Zeit zu Zeit pausieren, damit die Replikatdaten aktuell gehalten werden können.

--test-on-replica gibt an, dass der Vorgang nur zu Testzwecken dient. Die Replikation wird vor dem endgültigen Umschaltvorgang gestoppt. Zwischen der Originaltabelle und der temporären Tabelle wird hin- und hergewechselt, und letztendlich bleibt die Originaltabelle unverändert. Wenn die Master-Slave-Replikation angehalten ist, können Sie die Daten in den beiden Tabellen überprüfen und vergleichen (wenn Sie den Slave nicht stoppen möchten, können Sie den Parameter --test-on-replica-skip-replica-stop hinzufügen).

# gh-ost --initially-drop-old-table --initially-drop-ghost-table --user="ghost" --password="ghost" --host=110.119.120.230 --port=3306 --database="test" --table="t3" --verbose --alter="ADD COLUMN abc1 varchar(10),add column abc2 int not null default 0 comment 'test' " --test-on-replica --assume-rbr --execute

RDS-Einschränkungen:

1. Der Benutzer verfügt nicht über das Super-Privileg, daher muss während der Verwendung der Befehl --assume-rbr hinzugefügt werden. gh-ost geht davon aus, dass sich das Binärprotokoll selbst im Zeilenmodus befindet, und ändert es nicht. Das Binärprotokoll auf Alibaba Cloud RDS ist standardmäßig auch im Zeilenmodus, daher gibt es kein Problem.

2. Andere Berechtigungen, hauptsächlich REPLICATION SLAVE, REPLICATION CLIENT kann Binlog abrufen und auch abrufen.

3. Es kann keine Verbindung zur Standby-Datenbank hergestellt werden, um das Binärprotokoll abzurufen. Da die Standby-Datenbank für den Benutzer normalerweise transparent ist, muss sich gh-ost direkt mit der primären Datenbank verbinden, was die Belastung der primären Datenbank erhöhen kann. Wenn Sie es verwenden, müssen Sie --allow-on-master und --assume-master-host hinzufügen. Die offiziell empfohlene Methode besteht darin, eine Verbindung mit einer der Sicherungsdatenbanken herzustellen, da einige SELECT-Vorgänge mit hohem Druck stattfinden und es am besten ist, diese in der Sicherungsdatenbank abzulegen.

4. Zur Ausführung auf der Alibaba Cloud-Datenbank müssen Sie einen Parameter --aliyun-rds hinzufügen. Wenn Sie es jetzt verwenden, denken Sie daran, die folgenden Parameter hinzuzufügen: --allow-on-master --assume-rbr --assume-master-host --aliyun-rds

4. Vergleich zwischen gh-ost und pt-osc

4.1 Eine kurze Einführung in pt-osc

pt-osc-Arbeitsablauf
1. Überprüfen Sie, ob die Änderungstabelle einen Primärschlüssel oder einen eindeutigen Index hat und ob ein Trigger vorhanden ist
2. Überprüfen und ändern Sie die Tabellenstruktur, erstellen Sie eine temporäre Tabelle und führen Sie die Anweisung ALTER TABLE für die neue Tabelle aus
3. Erstellen Sie in der Quelltabelle drei Trigger für die Vorgänge INSERT, UPDATE und DELETE.
4. Kopieren Sie die Daten aus der Quelltabelle in die temporäre Tabelle. Während des Kopiervorgangs werden Aktualisierungen der Quelltabelle in die neu erstellte Tabelle geschrieben.
5. Benennen Sie die temporäre Tabelle und die Quelltabelle um (eine Metadatenänderungssperre ist erforderlich und die Tabelle muss für kurze Zeit gesperrt werden).
6. Löschen Sie die Quelltabelle und lösen Sie den Vorgang aus, um die Änderung der Tabellenstruktur abzuschließen.

Einschränkungen des pt-osc-Tools
1. Die Quelltabelle muss einen Primärschlüssel oder einen eindeutigen Index haben. Andernfalls funktioniert das Tool nicht mehr.
2. Wenn der Filtervorgang der Online-Replikationsumgebung zu komplex ist, funktioniert das Tool nicht
3. Wenn die Replikationsverzögerungsprüfung eingeschaltet ist, aber die Master-Slave-Verzögerung auftritt, unterbricht das Tool die Datenkopierarbeit
4. Wenn die Hauptserverlastprüfung eingeschaltet ist, die Hauptserverlast jedoch hoch ist, wird das Tool den Betrieb unterbrechen
5. Wenn die Tabelle Fremdschlüssel verwendet, wird das Tool nicht ausgeführt, wenn der Parameter --alter-foreign-keys-method nicht verwendet wird.
6. Es werden nur Tabellen der Innodb-Speicher-Engine unterstützt und auf dem Server wird mehr als das Einfache des freien Speicherplatzes der Tabelle benötigt.

Was sind also die konkreten Vorteile von gh-ost gegenüber pt-osc? Nachfolgend finden Sie eine kurze Einführung in die beiden wichtigsten Funktionen.

4.2 Ohne Auslöser

Vor dem Aufkommen von gh-ost wurden alle MySQL-DDL-Tools von Drittanbietern mithilfe von Triggern implementiert, darunter pt-osc von Percona, OSC von Facebook usw. Der von gh-ost verwendete Mechanismus unterscheidet sich völlig von ihnen: Er synchronisiert Daten über MySQL-Binlog. gh-ost selbst ist als Fake-Slave registriert, der Binlog vom Master oder Slave im Cluster abrufen, in Echtzeit analysieren und alle DML-Operationen der Änderungstabelle erneut auf die Schattentabelle anwenden kann. Daher kann bei DML-Operationen, die während der Freigabe in der Änderungstabelle auftreten, der durch Trigger und Sperrkonflikte verursachte Leistungseinbußen vollständig vermieden werden.

Darüber hinaus wählen wir normalerweise den Slave-Knoten im Cluster als Ziel-Publishing-Maschine aus, und der Slave führt im Allgemeinen kein Geschäft aus. Auf diese Weise fällt der Binlog-Parsing-Overhead nicht auf den Master, der das Geschäft bereitstellt, sondern ist nur eine asynchrone DML-Anweisungswiedergabe.

4.3 Dynamisch steuerbar

Eine weitere wichtige Funktion ist die dynamische Steuerung, die bisher in anderen Open-Source-Tools von Drittanbietern nicht verfügbar war.

Wenn zuvor über pt-osc veröffentlicht wurde, können die Parameter nach der Ausführung des Befehls nicht mehr geändert werden, es sei denn, er wird gestoppt und neu gestartet. Angenommen, die Veröffentlichung ist zu 90 % abgeschlossen und plötzlich steigt die Serverlast aus verschiedenen anderen Gründen an. Um das Geschäft nicht zu beeinträchtigen, können Sie die Veröffentlichung nur stoppen und warten, bis sich die Leistung erholt hat, bevor Sie sie neu starten.

Die über pt-osc veröffentlichten Tabellen sind alle groß und benötigen viel Zeit. Daher ist es sehr peinlich, auf solche Szenarien zu stoßen. Daher ist es sehr wichtig, dass die Parameter im Release dynamisch angepasst werden können. gh-ost implementiert auch einen Socket-Server. Über den Socket können wir in Echtzeit mit dem Veröffentlichungsprozess interagieren. Er unterstützt das Anhalten, Fortsetzen und dynamische Anpassen vieler Parameter in Echtzeit, um sich an externe Änderungen anzupassen.

5. Referenzen

1. Gh-ost-Prinzip

https://www.cnblogs.com/mysql-dba/p/9901589.html

2. Technologieaustausch | gh-ost Online-DDL-Änderungstool

https://zhuanlan.zhihu.com/p/83770402

3. Praktische Fähigkeiten | Die Entwicklung des Datenbank-Publishing-Systems von Ctrip

https://blog.csdn.net/ctrip_tech/article/details/108395676

4.MySQL Online DDL gh-ost-Nutzungsanweisungen

https://www.cnblogs.com/zhoujinyi/p/9187421.html

5.MySQL - pt-osc-Tool-Lernen

https://www.cnblogs.com/TeyGao/p/7160421.html

Dies ist das Ende dieses Artikels über das MySQL Online-DDL-Tool gh-ost. Weitere Informationen zu MySQL Online-DDL gh-ost finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!