Funktionieren die gespeicherten Prozeduren von MySQL 5.1 mit Replikation?

Ja. Standardaktionen, die in gespeicherten Prozeduren und Funktionen ausgeführt werden, werden von einem MySQL-Master-Server auf einen Slave-Server repliziert. Es gibt einige wenige Beschränkungen, die in Abschnitt 19.4, „Binärloggen gespeicherter Routinen und Trigger“ genauer ausgeführt werden.

Werden gespeicherte Prozeduren und Funktionen, die auf einem Master-Server angelegt wurden, auf einen Slave repliziert?

Ja, gespeicherte Prozeduren und Funktionen, die mit normalen DDL-Anweisungen auf einem Master-Server angelegt wurden, werden auf einen Slave repliziert, sodass die Objekte auf beiden Servern vorhanden sind. ALTER- und DROP-Anweisungen für gespeicherte Prozeduren und Funktionen werden ebenfalls repliziert.

Wie werden Aktionen repliziert, die innerhalb von gespeicherten Prozeduren und Funktionen stattfinden?

MySQL zeichnet jedes DML-Ereignis auf, das in einer gespeicherten Prozedur auftritt, und repliziert diese Einzelaktionen auf einen Slave-Server. Die eigentlichen Aufrufe der gespeicherten Prozeduren werden nicht repliziert.

Gespeicherte Funktionen, die Daten ändern, werden als Funktionsaufrufe ins Log geschrieben, und nicht als die DML-Ereignisse, die innerhalb der Funktionen stattfinden.

Gibt es spezielle Sicherheitsanforderungen, um gespeicherte Prozeduren und Funktionen mit Replikation zu benutzen?

Ja. Da ein Slave-Server das Recht hat, jede Anweisung auszuführen, die er aus dem Binärlog seines Masters liest, gibt es besondere Sicherheitsvorkehrungen für die Verwendung von gespeicherten Prozeduren mit Replikation. Wenn Replikation oder Binärlogging im Allgemeinen (für die Point-of-Time-Recovery) aktiv ist, haben MySQL-DBAs zwei Sicherheitsoptionen:

Welche Beschränkungen gelten für die Replikation von Aktionen gespeicherter Prozeduren und Funktionen?

Nichtdeterministische (zufällige) oder zeitabhängige Aktionen, die in gespeicherten Prozeduren eingebettet sind, werden eventuell nicht richtig repliziert. Nach dem Zufallsprinzip entstandene Ergebnisse sind von Natur aus unvorhersehbar und lassen sich nicht genau reproduzieren. Somit spiegeln Zufallsaktionen, die auf einen Slave repliziert werden, nicht die Aktionen des Masters wider. Wenn Sie gespeicherte Funktionen als DETERMINISTIC deklarieren oder die Systemvariable log_bin_trust_function_creators auf 0 setzen, können keine Operationen mit Zufallswerten aufgerufen werden.

Auch zeitabhängige Aktionen lassen sich nicht auf einen Slave replizieren, da das Timing solcher Aktionen in einer gespeicherten Prozedur nicht durch das für die Replikation eingesetzte Binärlog reproduzierbar ist. Dieses zeichnet nur DML-Ereignisse auf und berücksichtigt keine Zeiteinschränkungen.

Auch in nichttransaktionssicheren Tabellen, mit denen bei größeren DML-Aktionen (wie beispielsweise Massen-Einfügeoperationen) Fehler auftreten, können Replikationsprobleme entstehen, wenn ein Master aufgrund der DML-Aktivität teilweise aktualisiert wurde, während der Slave wegen eines Fehlers diese Änderung nicht mitgemacht hat. Dies kann man umgehen, indem man die DML-Aktionen einer Funktion mit dem Schlüsselwort IGNORE ausführt, damit Änderungen auf dem Master, die Fehler auslösen, ignoriert und Änderungen, die keine Fehler auslösen, auf den Slave repliziert werden.

Beeinträchtigen die vorgenannten Beschränkungen die Fähigkeit von MySQL, eine Point-in-Time-Recovery durchzuführen?

Dieselben Beschränkungen, die sich auf die Replikation auswirken, wirken sich auch auf die Point-in-Time-Recovery aus.

Was unternimmt MySQL, um diese Beschränkungen auszuräumen?

Ab MySQL 5.1.5 können Sie zwischen anweisungs- und zeilenbasierter Replikation wählen. Die ursprüngliche Implementierung der Replikation beruht auf dem anweisungsbasierten Binärlogging. Zeilenbasiertes Binärlogging löst die oben beschriebenen Probleme. Mehr zum Thema finden Sie unter Abschnitt 6.3, „Zeilenbasierte Replikation“.

Funktionieren Trigger mit Replikation?

Trigger und Replikation funktionieren in MySQL 5.1 genau wie in den meisten anderen Datenbank-Engines: Aktionen, die auf einem Master mithilfe von Triggern ausgeführt werden, werden nicht auf einen Slave-Server repliziert. Dagegen müssen Trigger auf Tabellen, die auf einem MySQL-Master-Server liegen, auch auf den entsprechenden Tabellen des MySQL-Slave-Servers angelegt werden, um auf den Slaves ebenso wie auf dem Master aktiviert werden zu können.

Wie werden Trigger-Aktionen auf einem Master ausgeführt, der auf einen Slave repliziert wurde?

Erstens müssen die Trigger, die auf dem Master vorhanden sind, auf dem Slave-Server rekonstruiert werden. Wenn dies erledigt ist, läuft die Replikation so ab wie bei jeder anderen DML-Standardanweisung, die an einer Replikation beteiligt ist. Betrachten Sie als Beispiel die Tabelle EMP mit dem Insert-Trigger AFTER, die auf einem MySQL-Master-Server liegt. Dieselbe EMP-Tabelle mit demselben AFTER-Insert-Trigger liegt auch auf dem Slave-Server. Der Replikationsfluss verliefe folgendermaßen: