Im zweiten und letzten Teil unserer Best Practices für mysqldump sprechen wir darüber, wie Sie die Migration und den Import von gespeicherten Programmobjekten und Ansichten aus Ihrer MySQL-Datenbank handhaben. Um mehr über die Voraussetzungen für einen erfolgreichen Sicherungs- und Wiederherstellungsvorgang für große MySQL-Datenbanken zu erfahren, lesen Sie den ersten Teil dieser zweiteiligen Blog-Serie.
Importieren Ihrer gespeicherten Prozeduren, Funktionen und Trigger
Standardmäßig importiert mysqldump Ansichten und Trigger. Es importiert jedoch keine Prozeduren, Funktionen und Ereignisse. Um Prozeduren und Funktionen zu importieren, müssen die --routines Option angegeben werden sollte, und um Ereignisse zu importieren, die --events Option sollte angegeben werden.
1. Trigger importieren
Mysqldump versucht standardmäßig, alle Trigger in Ihrer Datenbank auszugeben. Um die triggers einer Tabelle ausgeben zu können , müssen Sie den TRIGGER haben Privileg für den Tisch. Wenn der Dump-Benutzer dieses Recht nicht hat, werden Trigger übersprungen und mysqldump gibt keinen Fehler aus. Seien Sie also nicht überrascht, wenn Sie keine Trigger sehen, die in Ihre Zieldatenbank importiert wurden.
2. Ereignisse importieren
Um Ereignisse zu importieren, müssen Sie --events angeben Option beim Aufrufen des Dienstprogramms mysqldump. Diese Option erfordert das EVENT Berechtigungen für diese Datenbanken. Auch hier wird mysqldump Ereignisse stillschweigend überspringen, wenn der Dump-Benutzer diese Rechte nicht hat, selbst wenn Sie beim Aufrufen von mysqldump die Option –event angegeben haben.
3. Funktionen und gespeicherte Prozeduren importieren
Um Routinen zu importieren, müssen Sie --routines angeben Option beim Aufrufen des Dienstprogramms mysqldump. Diese Option erfordert das global select Privilegien. Selbst in diesem Fall überspringt mysqldump stillschweigend Funktionen und Prozeduren, wenn der Dump-Benutzer diese Privilegien nicht hat, selbst wenn Sie --routines angegeben haben Option beim Aufruf von mysqldump.
3.1 Importieren nicht deterministischer Funktionen
Ein gespeichertes Programm, das Daten modifiziert, wird als nicht deterministisch bezeichnet, wenn es keine wiederholbaren Ergebnisse liefert. Beispielfunktion rand(). Es ist besonders schwierig, solche Funktionen in replizierten Setups zu verwenden, da sie zu unterschiedlichen Daten auf Quelle und Replikat führen können. Um solche Möglichkeiten zu kontrollieren, erlegt MySQL der Funktionserstellung bestimmte Einschränkungen auf, wenn Binärlogs aktiviert sind.
Standardmäßig für eine CREATE FUNCTION zu akzeptierende Anweisung, mindestens eine von DETERMINISTIC , NO SQL , oder READS SQL DATA muss explizit angegeben werden. Andernfalls tritt ein Fehler auf:
ERROR 1418 (HY000) at line 181: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_funable)
Wenn also Ihre Funktion auf der Quelle nicht als deterministisch deklariert ist und die binäre Protokollierung auf Ihrem Ziel aktiviert ist, sehen Sie den obigen Fehler während der Wiederherstellung des Dumps. Daher ist es wichtig, die deterministische Natur Ihrer Funktionen im Voraus zu verstehen. Wenn Sie sicher sind, dass Ihre Funktionen deterministisch sind, müssen Sie die log_bin_trust_function_creators aktivieren Konfiguration auf Ihrem Ziel vor dem Wiederherstellungsvorgang. Wenn diese Option aktiviert ist, erlaubt MySQL die Erstellung solcher Funktionen, selbst wenn die binäre Protokollierung aktiviert ist.
4. SQL SECURITY Eigenschaft der gespeicherten Routinen und Views.
MySQL erlaubt eine SQL SECURITY Kontext, der beim Erstellen der Speicherprogramme oder -ansichten angegeben werden muss. Die SQL SECURITY Merkmal kann als DEFINER angegeben werden oder INVOKER . Wenn die SQL_SECURITY Kontext ist DEFINER , wird die Routine unter Verwendung der Privilegien des Kontos ausgeführt, das in der Routine DEFINER genannt wird Klausel. Wenn der Kontext INVOKER ist , wird die Routine mit den Rechten des Benutzers ausgeführt, der sie aufruft. Der Standardwert ist DEFINER .
Wenn Sie gespeicherte Routinen oder Ansichten wiederherstellen, müssen Sie sicherstellen, dass das definierende Benutzerkonto in Ihrer Zieldatenbank mit entsprechenden Berechtigungen vorhanden ist. Andernfalls treten während der Wiederherstellung Fehler auf.
Lassen Sie uns dies anhand eines Beispiels in Bezug auf Ansichten demonstrieren.
Nehmen wir an, Sie haben Ansichten V1 und V2 wie folgt definiert:
CREATE definer=admin@'%' VIEW mydb.V1 AS SELECT * FROM solution_table; CREATE definer=admin@'%' VIEW mydb.V2 AS SELECT * FROM V1 where num1=10;
Beachten Sie, dass Ansichten standardmäßig von mysqldump ausgegeben werden und wenn Sie den Benutzer „admin“ nicht auf Ihrem Ziel haben, werden Sie während des Wiederherstellungsvorgangs auf den folgenden Fehler stoßen:
Command failed with error - ERROR 1449 (HY000) at line 206 in file: '/mysql_data/mysqldump/sqldump_1582457155758.sql': The user specified as a definer ('admin'@'%') does not exist. Beachten Sie, dass es nicht nur ausreicht sicherzustellen, dass der Benutzer vorhanden ist, sondern dass der Benutzer über die entsprechenden Berechtigungen zum Ausführen der Ansichten verfügen muss. Zum Beispiel, wenn der Benutzer admin@'%' existiert auf dem Ziel, hat aber kein SELECT Zugriffsrechte auf die mydb-Datenbank haben, sehen Sie eine Fehlermeldung:
'/mysql_data/mysqldump/sqldump_1582456858033.sql':View 'mydb.V2' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them.vor>
|
Zusammenfassung
In dieser zweiteiligen Blogserie haben wir wichtige Voraussetzungen behandelt, die Sie erfüllen müssen, um eine erfolgreiche Migration Ihrer Daten und gespeicherten Programme sicherzustellen. ScaleGrid MySQL-Hosting behandelt diese Richtlinien, um eine reibungslose Erfahrung beim Importieren Ihrer Daten auf die ScaleGrid-Plattform zu gewährleisten. Bitte teilen Sie uns Ihre Erfahrungen und Best Practices für MySQL-Datenmigrationen mit!
