mysqldump Bästa metoder:Del 2 – Migrationsguide

I den andra och sista delen av vår mysqldump bästa praxis kommer vi att prata om hur man hanterar migreringen och importen för lagrade programobjekt och vyer från din MySQL-databas. För att läsa mer om förutsättningarna för en framgångsrik dumpnings- och återställningsoperation för stora MySQL-databaser, kolla in den första delen av denna tvådelade bloggserie.

Importera dina lagrade procedurer, funktioner och utlösare

Som standard importerar mysqldump vyer och utlösare. Den importerar dock inte procedurer, funktioner och händelser. För att importera procedurer och funktioner, --routines alternativet bör anges, och för att importera händelser, --events alternativet bör anges.

1. Importera utlösare

Mysqldump försöker dumpa alla triggers i din databas som standard. För att kunna dumpa en tabells triggers , du måste ha TRIGGER privilegium för bordet. Om dumpanvändaren inte har denna behörighet kommer triggers att hoppas över och mysqldump kommer inte att ge något fel. Så bli inte förvånad om du inte ser några triggers importerade till din destinationsdatabas.

2. Importera händelser

För att importera händelser måste du ange --events alternativet när du anropar verktyget mysqldump. Det här alternativet kräver EVENT privilegier för dessa databaser. Återigen kommer mysqldump tyst att hoppa över händelser om dumpanvändaren inte har dessa privilegier, även om du har angett –händelsealternativ när du anropar mysqldump.

3. Importera funktioner och lagrad procedur

För att importera rutiner måste du ange --routines alternativet när du anropar verktyget mysqldump. Det här alternativet kräver global select privilegier. Även i detta fall kommer mysqldump tyst att hoppa över funktioner och procedurer om dumpanvändaren inte har dessa privilegier, även om du har specificerat --routines alternativet när du anropar mysqldump.

3.1 Importera icke-deterministiska funktioner

Ett lagrat program som modifierar data kallas icke-deterministiskt om det inte ger upprepningsbara resultat. Exempel rand() funktion. Det är särskilt utmanande att använda sådana funktioner i replikerade inställningar, eftersom de kan resultera i olika data om källa och repliker. För att kontrollera sådana möjligheter, inför MySQL vissa begränsningar för att skapa funktioner om binära loggar är aktiverade.

Som standard för en CREATE FUNCTION uttalande som ska accepteras, minst en av DETERMINISTIC , NO SQL , eller READS SQL DATA måste anges uttryckligen. Annars uppstår ett fel:

FEL 1418 (HY000) på rad 181:Den här funktionen har inget av DETERMINISTIC, NO SQL eller READS SQL DATA i sin deklaration och binär loggning är aktiverad (du *kanske* vill använda den mindre säkra log_bin_trust_funable)

Så om din funktion inte deklareras som deterministisk på källan och binär loggning är aktiverad på din destination, kommer du att se ovanstående fel under återställningen av dumpen. Därför är det viktigt att först förstå den deterministiska karaktären av dina funktioner. Om du är säker på att dina funktioner är deterministiska måste du aktivera log_bin_trust_function_creators konfiguration på din destination innan återställningsåtgärden. När den är aktiverad tillåter MySQL att skapa sådana funktioner även när binär loggning är aktiverad.

4. SQL SECURITY karakteristisk för de lagrade rutinerna och vyerna.

MySQL tillåter en SQL SECURITY kontext som ska specificeras när butiksprogrammen eller vyerna skapas. SQL SECURITY egenskap kan anges som DEFINER eller INVOKER . Om SQL_SECURITY kontext är DEFINER , körs rutinen med privilegierna för kontot som anges i rutinen DEFINER klausul. Om sammanhanget är INVOKER , körs rutinen med privilegierna för användaren som anropar den. Standardvärdet är DEFINER .

Om du återställer lagrade rutiner eller vyer måste du se till att användarkontot som definierar finns finns i din destinationsdatabas med lämpliga tillstånd. Annars kommer du att stöta på fel under återställningen.

Låt oss demonstrera detta med ett exempel relaterat till åsikter.

Låt oss anta att du har vyer V1 och V2 definierar enligt nedan:

SKAPA definer=admin@'%' VISA mydb.V1 AS SELECT * FROM solution_table;CREATE definer=admin@'%' VISA mydb.V2 AS SELECT * FROM V1 där num1=10;

Observera att vyer dumpas som standard av mysqldump och om du inte har användaren "admin" på din destination kommer du att stöta på nedanstående fel under återställningsåtgärden:

Kommandot misslyckades med fel - ERROR 1449 (HY000) på rad 206 i filen:'/mysql_data/mysqldump/sqldump_1582457155758.sql':Användaren som anges som definierare ('admin'@'%') finns inte.

Observera att det inte bara är tillräckligt för att säkerställa att användaren finns, utan användaren måste ha lämpliga privilegier för att köra vyerna. Till exempel om användaren admin@'%' finns på destinationen, men har inte SELECT privilegier på mydb-databasen kommer du att se ett felmeddelande:

'/mysql_data/mysqldump/sqldump_1582456858033.sql':View 'mydb.V2' refererar till ogiltiga tabell(er) eller kolumner eller funktion(er) eller definier/invoker of view saknar rättigheter att använda dem. 
 
 
 
Intresserad av en fullt hanterad MySQL-lösning?
 

 För att lära dig mer om hur en DBaaS-leverantör som ScaleGrid kan hjälpa dig att hantera dina MySQL-databaser, kolla in vår MySQL-sida. Se hur ScaleGrid kan låta dig fokusera mer på att utveckla din produkt och mindre på att hantera databaser.
 

 
 
 
 
 
 
 
 
 
Sammanfattning
 

 I denna tvådelade bloggserie täckte vi viktiga förutsättningar du måste hantera för att säkerställa framgångsrik migrering av dina data och lagrade program. ScaleGrid MySQL-hosting hanterar dessa riktlinjer för att ge en smidig upplevelse när du importerar din data till ScaleGrid-plattformen. Dela med dig av dina erfarenheter och bästa praxis som du använder för MySQL-datamigrering!