Replikera data till en flexibel Azure Database for MySQL-server

  • Artikel

GÄLLER FÖR: Azure Database for MySQL – flexibel server

Med datareplikering kan du synkronisera data från en extern MySQL-server till en flexibel Azure Database for MySQL-serverinstans. Den externa servern kan finnas lokalt, på virtuella datorer, Azure Database for MySQL– enskild server eller en databastjänst som hanteras av andra molnleverantörer. Datareplikering baseras på binär loggfilpositionen (binlog) eller GTID-baserad replikering. Mer information om binlogreplikering finns i MySQL Replication.

Kommentar

Konfiguration av datareplikering för servrar som är aktiverade med hög tillgänglighet stöds endast via GTID-baserad replikering.

När datareplikering ska användas

De viktigaste scenarierna att tänka på när du använder datareplikering är:

  • Hybriddatasynkronisering: Med datareplikering kan du hålla data synkroniserade mellan dina lokala servrar och Azure Database for MySQL – flexibel server. Den här synkroniseringen hjälper dig att skapa hybridprogram. Den här metoden är tilltalande när du har en befintlig lokal databasserver men vill flytta data till en region närmare slutanvändarna.
  • Synkronisering av flera moln: För komplexa molnlösningar använder du Datareplikering för att synkronisera data mellan azure database for MySQL– flexibel server och olika molnleverantörer, inklusive virtuella datorer och databastjänster som finns i dessa moln.
  • Migrering: Kunder kan migrera i minimal tid med hjälp av verktyg med öppen källkod, till exempel MyDumper/MyLoader med datareplikering. En selektiv snabb produktionsbelastning från källa till måldatabas är möjlig med datareplikering.

För migreringsscenarier använder du Azure Database Migration Service (DMS).

Begränsningar och överväganden

Data replikeras inte

Mysql-systemdatabasen på källservern replikeras inte. Dessutom replikeras inte ändringar av konton och behörigheter på källservern. Om du skapar ett konto på källservern och det här kontot behöver åtkomst till replikservern skapar du samma konto manuellt på replikservern. Information om tabellerna i systemdatabasen finns i MySQL-manualen.

Datareplikering stöds på servrar med hög tillgänglighet (HA)

Stöd för datareplikering för hög tillgänglighet (HA) aktiverad server är endast tillgängligt via GTID-baserad replikering.

Den lagrade proceduren för replikering med GTID är tillgänglig på alla HA-aktiverade servrar med namnet mysql.az_replication_change_master_with_gtid.

Filter

Parametern replicate_wild_ignore_table skapar ett replikeringsfilter för tabeller på replikservern. Om du vill ändra den här parametern från Azure-portalen går du till den flexibla serverinstansen Azure Database for MySQL som används som replik och väljer "Serverparametrar" för att visa/redigera parametern replicate_wild_ignore_table .

Behov

  • Källserverversionen måste vara minst MySQL version 5.7.
  • Vår rekommendation är att ha samma version för käll- och replikserverversioner. Båda måste till exempel vara MySQL version 5.7, eller båda måste vara MySQL version 8.0.
  • Vår rekommendation är att ha en primärnyckel i varje tabell. Om vi har en tabell utan primärnyckel kan replikeringen vara långsam.
  • Källservern bör använda MySQL InnoDB-motorn.
  • Användaren måste ha rätt behörighet att konfigurera binär loggning och skapa nya användare på källservern.
  • Binära loggfiler på källservern bör inte rensas innan repliken tillämpar dessa ändringar. Om källan är en flexibel Azure Database for MySQL-server kan du läsa om hur du konfigurerar binlog_expire_logs_seconds för flexibel server eller enskild server
  • Om källservern har SSL aktiverat kontrollerar du att SSL CA-certifikatet för domänen har inkluderats i den mysql.az_replication_change_master lagrade proceduren. Se följande exempel och parametern master_ssl_ca .
  • Se till att datorn som är värd för källservern tillåter både inkommande och utgående trafik på port 3306.
  • Med offentlig åtkomst kontrollerar du att källservern har en offentlig IP-adress, att DNS är offentligt tillgänglig eller att källservern har ett fullständigt kvalificerat domännamn (FQDN).
  • Med privat åtkomst kontrollerar du att källservernamnet kan matchas och är tillgängligt från det virtuella nätverk där Azure Database for MySQL– flexibel serverinstans körs. (Mer information finns i Namnmatchning för resurser i virtuella Azure-nätverk).

Genererad osynlig primärnyckel

För MySQL version 8.0 och senare är genererade osynliga primära nycklar (GIPK) aktiverade som standard för alla azure database for MySQL-flexibla serverinstanser. MySQL 8.0+-servrar lägger till den osynliga kolumnen my_row_id till tabellerna och en primärnyckel i kolumnen, där InnoDB-tabellen skapas utan en explicit primärnyckel. Den här funktionen, när den är aktiverad, kan påverka några av användningsfallen för datareplikering enligt beskrivningen nedan:

  • Datareplikering misslyckas med replikeringsfel: "FEL 1068 (42000): Flera primära nycklar har definierats" om källservern skapar en primärnyckel i tabellen utan primärnyckel. Du kan åtgärda problemet genom att köra följande SQL-kommando, hoppa över replikeringsfel och starta om datareplikering.

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • Datareplikering misslyckas med replikeringsfel: "FEL 1075 (42000): Felaktig tabelldefinition; Det kan bara finnas en automatisk kolumn och den måste definieras som en nyckel" om källservern lägger till en auto_increment kolumn som unik nyckel. Du kan åtgärda problemet genom att köra följande SQL-kommando, ange "sql_generate_invisible_primary_key" som AV, hoppa över replikeringsfel och starta om datareplikering.

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • Datareplikering misslyckas om källservern kör någon annan SQL som inte stöds när "sql_generate_invisible_primary_key" är PÅ. Skapa till exempel en partitionstabell. I ett sådant scenario är att ange "sql_generate_invisible_primary_key" som OFF och starta om datareplikering.

Nästa steg