Replikera data till Azure Database for MySQL

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

Viktigt!

Azure Database for MySQL – enskild server är på väg att dras tillbaka. Vi rekommenderar starkt att du uppgraderar till en flexibel Azure Database for MySQL-server. Mer information om hur du migrerar till en flexibel Azure Database for MySQL-server finns i Vad händer med Azure Database for MySQL – enskild server?

Med datareplikering kan du synkronisera data från en extern MySQL-server till Azure Database for MySQL-tjänsten. Den externa servern kan finnas lokalt, på virtuella datorer eller en databastjänst som hanteras av andra molnleverantörer. Datareplikering baseras på binär loggfilpositionsbaserad eller GTID-baserad replikering som är inbyggd i MySQL. Mer information om binlogreplikering finns i översikten över Replikering av MySQL-binlog.

När du ska använda datareplikering

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. Den här synkroniseringen är användbar för 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 Data-in Replication för att synkronisera data mellan Azure Database for MySQL och olika molnleverantörer, inklusive virtuella datorer och databastjänster som finns i dessa moln.

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 vilka tabeller som finns i systemdatabasen finns i MySQL-handboken.

Filtrering

Parametern stöds för att hoppa över replikering av tabeller från källservern (lokalt, på virtuella datorer eller en databastjänst som hanteras av andra molnleverantörer replicate_wild_ignore_table ). Du kan också uppdatera den här parametern på replikservern som finns i Azure med hjälp av Azure-portalen eller Azure CLI.

Mer information om den här parametern finns i MySQL-dokumentationen.

Stöds endast på nivån Generell användning eller Minnesoptimerad

Datareplikering stöds endast på prisnivåerna Generell användning och Minnesoptimerad.

Den privata länken för Azure Database for MySQL stöder endast inkommande anslutningar. Eftersom datareplikering kräver utgående anslutning från tjänstens privata länk stöds inte för data-in-trafik.

Kommentar

GTID stöds på versionerna 5.7 och 8.0 och endast på servrar som stöder lagring upp till 16 TB (generell lagring v2).

Behov

  • Källserverversionen måste vara minst MySQL version 5.6.
  • Käll- och replikserverversionerna måste vara desamma. Båda måste till exempel vara MySQL version 5.6 eller båda måste vara MySQL version 5.7.
  • Varje tabell måste ha en primärnyckel.
  • Källservern bör använda MySQL InnoDB-motorn.
  • Användaren måste ha behörighet att konfigurera binär loggning och skapa nya användare på källservern.
  • Om källservern har SSL aktiverat kontrollerar du att SSL CA-certifikatet som angetts för domänen har inkluderats i den mysql.az_replication_change_master eller mysql.az_replication_change_master_with_gtid lagrade proceduren. Se följande exempel och parametern master_ssl_ca .
  • Kontrollera att källserverns IP-adress har lagts till i Azure Database for MySQL-replikserverns brandväggsregler. Uppdatera brandväggsregler med hjälp av Azure-portalen eller Azure CLI.
  • Se till att datorn som är värd för källservern tillåter både inkommande och utgående trafik på port 3306.
  • Kontrollera 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).

Nästa steg