Share via


Kända problem med migreringar till Azure Database for MySQL

Kända problem som är kopplade till migreringar till Azure Database for MySQL beskrivs i följande avsnitt.

Schemamigreringsproblem för v8.0 MySQL – flexibel servermål

  • Fel: En migrering till en flexibel MySQL-server med motorversion 8.0.30 eller senare kan misslyckas när funktionen för att generera osynliga primära nycklar för InnoDB-tabeller är aktiverad (se MySQL :: MySQL 8.0 Referenshandbok:: 13.1.20.11 Genererade osynliga primära nycklar). Felet kan inträffa vid migrering av tabellschema från källan till målet, vid tillämpning av ändringar under replikeringsfasen för onlinemigreringar, vid återförsök av en migrering eller när du migrerar till ett mål där schemat har migrerats manuellt.

    Potentiellt felmeddelande:

    • "Okänt fel."
    • "Det gick inte att generera en osynlig primärnyckel. Det finns redan en automatisk inkrementell kolumn."
    • "Kolumnen 'my_row_id' i måltabellen 'tabellnamn' i databasen 'database' finns inte i källtabellen."

    Begränsning: Migrering till MySQL– flexibel serverinstans där sql_generate_invisible_primary_key är aktiverad stöds inte av DMS.

    Lösning: Ställ in serverparametern sql_generate_invisible_primary_key för mySQL-målets flexibla server till AV. Serverparametern finns på bladet Serverparametrar under fliken Alla för målet MySQL – flexibel server. Släpp dessutom måldatabasen och börja med DMS-migreringen för att inte ha några matchande scheman.

Inkompatibelt SQL-läge

Ett eller flera inkompatibla SQL-lägen kan orsaka många olika fel. Nedan visas ett exempelfel tillsammans med serverlägen som bör undersökas om det här felet inträffar.

  • Fel: Ett fel uppstod när tabellen {table} förbereddes i databasen {database} på servern {server} för migrering under aktiviteten {activity}. Därför migreras inte den här tabellen.

    Begränsning: Det här felet uppstår när något av nedanstående SQL-lägen anges på en server men inte på den andra servern.

    Lösning:

    NO_ZERO_DATE NO_AUTO_CREATE_USER
    När standardvärdet för ett datum i en tabell eller data är 0000-00-00 på källan, och målservern har NO_ZERO_DATE SQL-läge inställt, misslyckas schemat och/eller datamigreringen. Det finns två möjliga lösningar. Den första är att ändra standardvärdena för kolumnerna till NULL eller ett giltigt datum. Det andra alternativet är att ta bort NO_ZERO_DATE SQL-läge från den globala SQL-lägesvariabeln. När du kör migreringar från MySQL-källservern 5.7 till MySQL-målservern 8.0 som utför schemamigrering av rutiner, uppstår fel om no_auto_create_user SQL-läge har angetts på MySQL-källservern 5.7.

Problem med kvarhållning av binlog

  • Fel: Allvarligt fel vid läsning av binlog. Det här felet kan tyda på att binlog-filnamnet och/eller den ursprungliga positionen har angetts felaktigt.

    Begränsning: Det här felet uppstår om kvarhållningsperioden för binlog är för kort.

    Lösning: Det finns flera variabler som kan konfigureras i det här fallet: binlog_expire_logs_seconds avgör kvarhållningsperioden och borttagning av binlog kan förhindras helt och hållet genom att ställa in binlog_expire_logs_auto_purge av. MySQL 5.7 har inaktuell systemvariabel expire_logs_days.

Tidsgräns för att hämta tabelllås

  • Fel: Ett undantag uppstod när ett läslås skulle hämtas på servern {server} för att skapa en konsekvent vy.

    Begränsning: Det här felet uppstår när det finns en tidsgräns när lås hämtas på alla tabeller när transaktionskonsekvens är aktiverat.

    Lösning: Kontrollera att de valda tabellerna inte är låsta eller att inga långvariga transaktioner körs på dem.

Skriva mer än 4 MB data till Azure Storage

  • Fel: Begärandetexten är för stor och överskrider den högsta tillåtna gränsen.

    Begränsning: Det här felet uppstår troligen när det finns för många tabeller för att migrera (>10 000). Det finns en gräns på 4 MB för varje anrop till Azure Storage-tjänsten.

    Lösning: Kontakta supporten genom att skapa en supportbegäran och vi kan tillhandahålla anpassade skript för att komma åt våra REST-API:er direkt.

Problem med att duplicera nyckelinmatning

  • Fel: Felet är ofta ett symptom på tidsgränser, nätverksproblem eller målskalning.

    Potentiellt felmeddelande: Det gick inte att skriva en batch till tabellen {table} på grund av ett SQL-fel som uppstod av målservern. För kontext innehöll batchen en delmängd rader som returnerades av följande källfråga.

    Begränsning: Det här felet kan orsakas av timeout eller en bruten anslutning till målet, vilket resulterar i duplicerade primära nycklar. Det kan också vara relaterat till flera migreringar till målet som körs samtidigt, eller att användaren har testarbetsbelastningar som körs på målet medan migreringen körs. Dessutom kan målet kräva att primära nycklar är unika, även om de inte behöver vara det på källan.

    Lösning: Lös problemet genom att se till att det inte finns några duplicerade migreringar som körs och att de primära källnycklarna är unika. Om felet kvarstår kontaktar du supporten genom att skapa en supportbegäran och vi kan tillhandahålla anpassade skript för att komma åt våra REST-API:er direkt.

Replikeringsåtgärden hade felmatchade rader

  • Fel: Onlinemigrering kan inte replikera förväntat antal ändringar.

    Potentiellt felmeddelande: Ett fel uppstod när poster tillämpades på målservern som lästes från källserverns binära logg. Ändringarna startade i binärloggen {mysql-bin.log} och positionen {position} och avslutades vid den binära loggen {mysql-bin.log} och positionen {position}. Alla poster på källservern före positionen {position} i den binära loggen {mysql-bin.log} har checkats in på målet.

    Begränsning: På källan fanns det infognings- och borttagningsuttryck i en tabell, och borttagningarna var av ett uppenbart unikt index.

    Lösning: Vi rekommenderar att du migrerar tabellen manuellt.

Trunkerat tabelldatafel

  • Fel: Uppräkningskolumnen har ett null-värde på en eller flera rader och SQL-målläget är inställt på strikt.

    Potentiellt felmeddelande: Det gick inte att skriva en batch till tabellen {table} på grund av ett datatrunkeringsfel. Kontrollera att data inte är för stora för datatypen i mySQL-tabellkolumnen. Om kolumntypen är ett uppräkning kontrollerar du att SQL-läget inte har angetts som TRADITIONELLT, STRICT_TRANS_TABLES eller STRICT_ALL_TABLES och är detsamma för källa och mål.

    Begränsning: Felet uppstår när historiska data skrevs till källservern när de hade en viss inställning, men när de ändras kan data inte flyttas.

    Lösning: För att lösa problemet rekommenderar vi att du ändrar SQL-målläget till icke-strikt eller ändrar alla null-värden till giltiga värden.

Fel vid skapande av objekt

  • Fel: Ett fel uppstod när verifieringen av vyn misslyckades.

    Begränsning: Felet uppstår när du försöker migrera en vy och tabellen som vyn ska referera till inte kan hittas.

    Lösning: Vi rekommenderar att du migrerar vyer manuellt.

Det går inte att hitta tabellen

  • Fel: Det gick inte att hitta ett fel som refererar till tabellen.

    Potentiellt felmeddelande: Pipelinen kunde inte skapa schemat för objektet {object} för aktiviteten {activity} med hjälp av strategin MySqlSchemaMigrationViewUsingTableStrategy på grund av en frågekörning.

    Begränsning: Felet kan inträffa när vyn refererar till en tabell som har tagits bort eller bytt namn eller när vyn skapades med felaktig eller ofullständig information. Det här felet kan inträffa om en delmängd av tabellerna migreras, men de tabeller som de är beroende av inte är det.

    Lösning: Vi rekommenderar att du migrerar vyer manuellt. Kontrollera om alla tabeller som refereras i sekundärnycklar och CREATE VIEW-instruktioner har valts för migrering.

Alla poolanslutningar har brutits

  • Fel: Alla anslutningar på källservern bröts.

    Begränsning: Felet uppstår när alla anslutningar som hämtas i början av den första belastningen går förlorade på grund av serveromstart, nätverksproblem, tung trafik på källservern eller andra tillfälliga problem. Det här felet kan inte återställas. Dessutom uppstår det här felet om ett försök att migrera en server görs under underhållsfönstret.

    Lösning: Migreringen måste startas om och vi rekommenderar att du ökar källserverns prestanda. Ett annat problem är skript som stoppar långvariga anslutningar, vilket förhindrar att skripten fungerar.

Konsekvent ögonblicksbild bruten

Begränsning: Felet uppstår när kunden utför DDL under den första inläsningen av migreringsinstansen.

Lösning: För att lösa det här problemet rekommenderar vi att du avstår från att göra DDL-ändringar under den inledande inläsningen.

Villkor för sekundärnyckel

  • Fel: Felet uppstår när den refererade sekundärnyckeltypen från tabellen ändras.

    Potentiellt felmeddelande: Referenskolumnen {pk kolumn 1} och den refererade kolumnen {fk kolumn 1} i sekundärnyckelvillkoret {key} är inkompatibla.

    Begränsning: Felet kan orsaka att schemamigreringen av en tabell misslyckas eftersom PK-kolumnen i tabell 1 kanske inte är kompatibel med FK-kolumnen i tabell 2.

    Lösning: För att lösa det här problemet rekommenderar vi att du tar bort sekundärnyckeln och återskapar den när migreringsprocessen har slutförts.

Nästa steg