In het tweede en laatste deel van onze best practices voor mysqldump zullen we het hebben over hoe de migratie en import van opgeslagen programma-objecten en weergaven uit uw MySQL-database moet worden afgehandeld. Lees het eerste deel van deze tweedelige blogserie om meer te lezen over de vereisten voor een succesvolle dump- en herstelbewerking voor grote MySQL-databases.
Uw opgeslagen procedures, functies en triggers importeren
Standaard importeert mysqldump weergaven en triggers. Het importeert echter geen procedures, functies en gebeurtenissen. Om procedures en functies te importeren, de --routines optie moet worden gespecificeerd, en om gebeurtenissen te importeren, de --events optie moet worden gespecificeerd.
1. Triggers importeren
Mysqldump zal standaard proberen alle triggers in uw database te dumpen. Om de triggers van een tafel te kunnen dumpen , moet u de TRIGGER . hebben voorrecht aan tafel. Als de dumpgebruiker dit privilege niet heeft, worden triggers overgeslagen en zal mysqldump geen foutmelding geven. Wees dus niet verbaasd als u geen triggers ziet geïmporteerd naar uw bestemmingsdatabase.
2. Gebeurtenissen importeren
Als u gebeurtenissen wilt importeren, moet u --events opgeven optie tijdens het aanroepen van het hulpprogramma mysqldump. Deze optie vereist de EVENT privileges voor die databases. Nogmaals, mysqldump zal stil gebeurtenissen overslaan als de dumpgebruiker deze privileges niet heeft, zelfs als je de –event optie hebt gespecificeerd bij het aanroepen van mysqldump.
3. Functies en opgeslagen procedure importeren
Als u routines wilt importeren, moet u --routines opgeven optie tijdens het aanroepen van het hulpprogramma mysqldump. Deze optie vereist de global select voorrechten. Zelfs in dit geval zal mysqldump stil functies en procedures overslaan als de dumpgebruiker deze privileges niet heeft, zelfs als je --routines hebt gespecificeerd optie bij het aanroepen van mysqldump.
3.1 Niet-deterministische functies importeren
Een opgeslagen programma dat gegevens wijzigt, wordt niet-deterministisch genoemd als het geen herhaalbare resultaten oplevert. Voorbeeld rand() functie. Het is vooral een uitdaging om dergelijke functies in gerepliceerde opstellingen te gebruiken, omdat ze kunnen resulteren in verschillende gegevens over bron en replica. Om dergelijke mogelijkheden te beheersen, legt MySQL bepaalde beperkingen op aan het maken van functies als binaire logbestanden zijn ingeschakeld.
Standaard, voor een CREATE FUNCTION verklaring om te worden geaccepteerd, ten minste één van DETERMINISTIC , NO SQL , of READS SQL DATA moet expliciet worden vermeld. Anders treedt er een fout op:
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)
Dus als je functie niet als deterministisch is gedeclareerd op de bron, en binaire logging is ingeschakeld op je bestemming, zul je de bovenstaande fout zien tijdens het herstellen van de dump. Daarom is het belangrijk om vooraf de deterministische aard van uw functies te begrijpen. Als u zeker weet dat uw functies deterministisch zijn, moet u de log_bin_trust_function_creators inschakelen configuratie op uw bestemming vóór de herstelbewerking. Indien ingeschakeld, staat MySQL het creëren van dergelijke functies toe, zelfs wanneer binaire logging is ingeschakeld.
4. SQL SECURITY kenmerk van de opgeslagen routines en views.
MySQL staat een SQL SECURITY toe context die moet worden opgegeven tijdens het maken van de winkelprogramma's of weergaven. De SQL SECURITY kenmerk kan worden gespecificeerd als DEFINER of INVOKER . Als de SQL_SECURITY context is DEFINER , de routine wordt uitgevoerd met behulp van de privileges van het account genoemd in de routine DEFINER clausule. Als de context INVOKER . is , routine wordt uitgevoerd met behulp van de privileges van de gebruiker die het aanroept. De standaardwaarde is DEFINER .
Als u opgeslagen routines of views herstelt, moet u ervoor zorgen dat het gebruikersaccount van de definitie met de juiste toestemmingen aanwezig is in uw doeldatabase. Anders zult u fouten tegenkomen tijdens het herstellen.
Laten we dit demonstreren met een voorbeeld gerelateerd aan views.
Stel dat je Views V1 en V2 hebt zoals hieronder gedefinieerd:
CREATE definer=admin@'%' VIEW mydb.V1 AS SELECT * FROM solution_table; CREATE definer=admin@'%' VIEW mydb.V2 AS SELECT * FROM V1 where num1=10;
Merk op dat weergaven standaard door mysqldump worden gedumpt en als u de gebruiker 'admin' niet op uw bestemming heeft, zult u de onderstaande fout tegenkomen tijdens de herstelbewerking:
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. Merk op dat het niet alleen voldoende is om ervoor te zorgen dat de gebruiker bestaat, maar dat de gebruiker de juiste rechten moet hebben om de weergaven uit te voeren. Bijvoorbeeld als de gebruiker admin@'%' bestaat op de bestemming, maar heeft geen SELECT privileges op de mydb-database, ziet u een foutmelding:
'/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.
|
Samenvatting
In deze tweedelige blogserie hebben we belangrijke voorwaarden behandeld waaraan u moet voldoen om een succesvolle migratie van uw gegevens en opgeslagen programma's te garanderen. ScaleGrid MySQL-hosting hanteert deze richtlijnen om een soepele ervaring te bieden tijdens het importeren van uw gegevens naar het ScaleGrid-platform. Deel met ons uw ervaring en best practices die u toepast voor MySQL-gegevensmigraties!