Gespeicherte MySQL-Prozeduren, Funktionen, Trigger und Replikation: FAQ

Funktionieren gespeicherte Prozeduren und Funktionen von MySQL 5.1 bei der Replikation?
Ja, das Standardverhalten ist in gespeicherten Prozeduren und Funktionen implementiert, die vom Master-MySQL-Server auf den Slave-Server repliziert werden. Es gibt einige Einschränkungen, die in Abschnitt 20.4, „Funktionen zum Speichern von Unterroutinen und zum Auslösen von Binärprotokollen“ ausführlich beschrieben werden.
Können gespeicherte Prozeduren und Funktionen, die auf dem Master-Server erstellt wurden, auf den Slave-Server kopiert werden?
Ja, bei gespeicherten Prozeduren und Funktionen, die über allgemeine DDL-Anweisungen ausgeführt werden, wird deren Erstellung auf dem Master-Server auf den Slave-Server kopiert, sodass das Ziel auf beiden Servern vorhanden ist. ALTER- und DROP-Anweisungen für gespeicherte Prozeduren und Funktionen werden ebenfalls repliziert.
Wie tritt das Verhalten innerhalb kopierter gespeicherter Prozeduren und Funktionen auf?
MySQL zeichnet jedes DML-Ereignis auf, das in gespeicherten Prozeduren und Funktionen auftritt, und repliziert diese einzelnen Aktionen auf dem Slave-Server. Tatsächliche Aufrufe gespeicherter Prozeduren und Funktionen werden nicht kopiert.
Gibt es besondere Sicherheitsanforderungen für die gemeinsame Verwendung gespeicherter Prozeduren, Funktionen und Replikation?
Ja, da ein Slave die Berechtigung hat, jede Anweisung auszuführen, die das Binärprotokoll des Masters liest, gelten die angegebenen Sicherheitseinschränkungen für gespeicherte Prozeduren und Funktionen, die bei der Replikation verwendet werden. Wenn die Replikation oder Binärprotokollierung generell aktiviert ist (zu Zwecken der Point-in-Time-Wiederherstellung), stehen dem MySQL-DBA zwei Sicherheitsoptionen zur Verfügung:
Jedem Benutzer, der gespeicherte Prozeduren erstellen möchte, müssen SUPER-Berechtigungen gewährt werden.
Alternativ kann ein DBA die Systemvariable log_bin_trust_routine_creators auf 1 setzen, wodurch jeder mit standardmäßigen CREATE ROUTINE-Berechtigungen gespeicherte Prozeduren und Funktionen erstellen kann.

Welche Einschränkungen gibt es beim Verhalten beim Kopieren gespeicherter Prozeduren und Funktionen?
Unbestimmte (zufällige) oder zeitbasierte Zeilen, die in gespeicherte Prozeduren eingebettet sind, werden nicht ordnungsgemäß kopiert. Zufällig generierte Ergebnisse sind naturgemäß vorhersehbar und können nicht zuverlässig geklont werden. Daher spiegelt das auf den Slave-Server replizierte zufällige Verhalten nicht das auf dem Master-Server auftretende Verhalten wider. Beachten Sie, dass die Deklaration einer gespeicherten Prozedur oder Funktion DETERMINISTIC oder das Setzen der Systemvariablen auf 0 in log_bin_trust_routine_creators den Aufruf von Zufallswertoperationen ermöglicht.
Darüber hinaus ist zeitbasiertes Verhalten auf dem Slave-Server nicht reproduzierbar, da ein solches zeitbasiertes Verhalten in der gespeicherten Prozedur über das für die Replikation verwendete Binärprotokoll nicht reproduzierbar ist, da das Binärprotokoll nur DML-Ereignisse protokolliert und keine Zeitvorgaben enthält Einschränkungen.
Wenn schließlich während einer großen DML-Aktion (z. B. einer Masseneinfügung) ein Fehler in einer nicht interaktiven Tabelle auftritt, wird die nicht interaktive Tabelle möglicherweise einer Replikation unterzogen und der Masterserver wird möglicherweise teilweise von der DML-Aktion aktualisiert die replizierte Version der nicht interaktiven Tabelle. Aufgrund des aufgetretenen Fehlers erfolgte jedoch kein Update auf dem Slave-Server. Für das DML-Verhalten der Funktion wird der Arbeitsbereich mit dem Schlüsselwort IGNORE ausgeführt, sodass Aktualisierungen, die Fehler auf dem Master-Server verursachen, ignoriert werden und Aktualisierungen, die keine Fehler verursachen, auf den Slave-Server kopiert werden.

Beeinträchtigen die oben genannten Einschränkungen die Fähigkeit von MySQL, eine Point-in-Time-Wiederherstellung durchzuführen?
Die gleichen Einschränkungen, die sich auf die Replikation auswirken, wirken sich auch auf die Wiederherstellung zu einem bestimmten Zeitpunkt aus.
Was sollte MySQL tun, um die oben genannten Einschränkungen zu beheben?
Zukünftige Versionen von MySQL werden voraussichtlich über eine Funktion verfügen, mit der Sie auswählen können, wie die Replikation gehandhabt werden soll:
Anweisungsbasierte Replikation (aktuelle Implementierung).
Replikation auf Zeilenebene (dadurch werden alle zuvor beschriebenen Einschränkungen behoben).
Funktionieren Trigger bei der Replikation?
Trigger und Replikation in MySQL 5.1 funktionieren wie in den meisten anderen Datenbank-Engines, bei denen auf dem Master über Trigger ausgeführte Aktionen nicht auf den Slaves repliziert werden. Stattdessen müssen Trigger, die sich in Tabellen auf dem Master-MySQL-Server befinden, innerhalb der Tabellen erstellt werden, die auf allen MySQL-Slaves vorhanden sind, damit die Trigger auch auf den Slaves aktiviert werden können.

Wie kann ein Verhalten durch einen vom Master-Server auf den Slave-Server kopierten Trigger ausgeführt werden?
Zuerst muss der Trigger auf dem Master-Server auf dem Slave-Server neu erstellt werden. Nach der Neuerstellung funktioniert der Replikationsprozess wie jede andere an der Replikation beteiligte Standard-DML-Anweisung. Beispiel: Stellen Sie sich eine EMP-Tabelle vor, in die ein Trigger AFTER eingefügt wurde, der sich auf dem Haupt-MySQL-Server befindet. Die gleichen EMP-Tabellen und AFTER-Insert-Trigger sind auch auf dem Slave-Server vorhanden. Der Kopiervorgang kann wie folgt aussehen:
1. Machen Sie eine INSERT-Anweisung für EMP.
2. NACH der Triggeraktivierung am EMP.
3. Die INSERT-Anweisung wird in das Binärprotokoll geschrieben.
4. Die Replikation auf dem Slave-Server übernimmt die INSERT-Anweisung in die EMP-Tabelle und führt sie auf dem Slave-Server aus.
5. Das AFTER-Triggerprogramm auf dem Slave-Server EMP wird aktiviert.