Dela via

Så här konfigurerar du Azure Database for MySQL-datareplikering

  • Artikel

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?

Den här artikeln beskriver hur du konfigurerar datareplikering i Azure Database for MySQL genom att konfigurera käll- och replikservrarna. Den här artikeln förutsätter att du har viss tidigare erfarenhet av MySQL-servrar och -databaser.

Kommentar

Den här artikeln innehåller referenser till termen slav, en term som Microsoft inte längre använder. När termen tas bort från programvaran tar vi bort den från den här artikeln.

För att skapa en replik i Azure Database for MySQL-tjänsten synkroniserar Data-in Replication data från en mySQL-källserver lokalt, på virtuella datorer eller i molndatabastjänster. 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.

Granska begränsningarna och kraven för datareplikering innan du utför stegen i den här artikeln.

Skapa en Azure Database for MySQL-instans med en enskild server som ska användas som replik

  1. Skapa en ny instans av Azure Database for MySQL – enskild server (till exempel replica.mysql.database.azure.com). Se Skapa en Azure Database for MySQL-server med hjälp av Azure-portalen för att skapa server. Den här servern är replikservern för datareplikering.

    Viktigt!

    Azure Database for MySQL-servern måste skapas på prisnivåerna Generell användning eller Minnesoptimerad eftersom datareplikering endast stöds på dessa nivåer. 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).

  2. Skapa samma användarkonton och motsvarande behörigheter.

    Användarkonton replikeras inte från källservern till replikservern. Om du planerar att ge användarna åtkomst till replikservern måste du skapa alla konton och motsvarande behörigheter manuellt på den nya Azure Database for MySQL-servern.

  3. Lägg till källserverns IP-adress i replikens brandväggsregler.

    Uppdatera brandväggsregler med hjälp av Azure-portalen eller Azure CLI.

  4. Valfritt – Om du vill använda GTID-baserad replikering från källservern till Azure Database for MySQL-replikservern måste du aktivera följande serverparametrar på Azure Database for MySQL-servern enligt portalbilden nedan:

    Aktivera GTID på Azure Database for MySQL-servern

Konfigurera MySQL-källservern

Följande steg förbereder och konfigurerar MySQL-servern som finns lokalt, på en virtuell dator eller en databastjänst som hanteras av andra molnleverantörer för datareplikering. Den här servern är "källan" för datareplikering.

  1. Granska källserverkraven innan du fortsätter.

  2. Kontrollera att källservern tillåter både inkommande och utgående trafik på port 3306 och att den har en offentlig IP-adress, att DNS är offentligt tillgänglig eller att den har ett fullständigt kvalificerat domännamn (FQDN).

    Testa anslutningen till källservern genom att försöka ansluta från ett verktyg, till exempel MySQL-kommandoraden som finns på en annan dator eller från Azure Cloud Shell som är tillgängligt i Azure-portalen.

    Om din organisation har strikta säkerhetsprinciper och inte tillåter att alla IP-adresser på källservern aktiverar kommunikation från Azure till källservern kan du använda kommandot nedan för att fastställa IP-adressen för din MySQL-server.

    1. Logga in på Azure Database for MySQL-servern med hjälp av ett verktyg som MySQL-kommandoraden.

    2. Kör följande fråga.

      mysql> SELECT @@global.redirect_server_host;

      Nedan visas några exempel på utdata:

      +-----------------------------------------------------------+
| @@global.redirect_server_host                             |
+-----------------------------------------------------------+
| e299ae56f000.tr1830.westus1-a.worker.database.windows.net |
 +-----------------------------------------------------------+

    3. Avsluta från MySQL-kommandoraden.

    4. Hämta IP-adressen genom att köra följande kommando i ping-verktyget:

      ping <output of step 2b>

      Till exempel:

      C:\Users\testuser> ping e299ae56f000.tr1830.westus1-a.worker.database.windows.net
Pinging tr1830.westus1-a.worker.database.windows.net (**11.11.111.111**) 56(84) bytes of data.

    5. Konfigurera källserverns brandväggsregler så att den innehåller det föregående stegets utdata-IP-adress på port 3306.

      Kommentar

      Den här IP-adressen kan ändras på grund av underhåll/distributionsåtgärder. Den här anslutningsmetoden är endast avsedd för kunder som inte har råd att tillåta alla IP-adresser på 3306-porten.

  3. Aktivera binär loggning.

    Kontrollera om binär loggning har aktiverats på källan genom att köra följande kommando:

    SHOW VARIABLES LIKE 'log_bin';

    Om variabeln log_bin returneras med värdet "ON" aktiveras binär loggning på servern.

    Om log_bin returneras med värdet "OFF" och källservern körs lokalt eller på virtuella datorer där du kan komma åt konfigurationsfilen (my.cnf) kan du följa stegen nedan:

    1. Leta upp mySQL-konfigurationsfilen (my.cnf) på källservern. Exempel: /etc/my.cnf

    2. Öppna konfigurationsfilen för att redigera den och leta upp avsnittet mysqld i filen.

    3. I avsnittet mysqld lägger du till följande rad:

      log-bin=mysql-bin.log

    4. Starta om MySQL-källservern för att ändringarna ska börja gälla.

    5. När servern har startats om kontrollerar du att binär loggning är aktiverad genom att köra samma fråga som tidigare:

      SHOW VARIABLES LIKE 'log_bin';

  4. Konfigurera källserverinställningarna.

    Datareplikering kräver att parametern lower_case_table_names är konsekvent mellan käll- och replikservrarna. Den här parametern är 1 som standard i Azure Database for MySQL.

    SET GLOBAL lower_case_table_names = 1;

    Valfritt – Om du vill använda GTID-baserad replikering måste du kontrollera om GTID är aktiverat på källservern. Du kan köra följande kommando mot mySQL-källservern för att se om gtid_mode är PÅ.

    show variables like 'gtid_mode';

    Viktigt!

    Alla servrar har gtid_mode inställt på standardvärdet OFF. Du behöver inte aktivera GTID på MySQL-källservern specifikt för att konfigurera datareplikering. Om GTID redan är aktiverat på källservern kan du också använda GTID-baserad replikering för att konfigurera datareplikering också med Azure Database for MySQL– enskild server. Du kan använda filbaserad replikering för att konfigurera datareplikering för alla servrar oavsett gitd_mode konfiguration på källservern.

  5. Skapa en ny replikeringsroll och konfigurera behörighet.

    Skapa ett användarkonto på källservern som har konfigurerats med replikeringsbehörighet. Detta kan göras via SQL-kommandon eller ett verktyg som MySQL Workbench. Överväg om du planerar att replikera med SSL, eftersom detta måste anges när du skapar användaren. Mer information om hur du lägger till användarkonton på källservern finns i MySQL-dokumentationen.

    I följande kommandon kan den nya replikeringsrollen som skapas komma åt källan från valfri dator, inte bara den dator som är värd för själva källan. Detta görs genom att ange "syncuser@'%'" i kommandot skapa användare. Mer information om hur du anger kontonamn finns i MySQL-dokumentationen.

    SQL-kommando

    Replikering med SSL

    Om du vill kräva SSL för alla användaranslutningar använder du följande kommando för att skapa en användare:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO 'syncuser'@'%' REQUIRE SSL;

    Replikering utan SSL

    Om SSL inte krävs för alla anslutningar använder du följande kommando för att skapa en användare:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO 'syncuser'@'%';

    MySQL Workbench

    Om du vill skapa replikeringsrollen i MySQL Workbench öppnar du panelen Användare och privilegier från panelen Hantering och väljer sedan Lägg till konto.

    Användare och privilegier

    Skriv in användarnamnet i fältet Inloggningsnamn .

    Synkronisera användare

    Välj panelen Administrativa roller och välj sedan Replikeringsslav i listan över globala privilegier. Välj sedan Använd för att skapa replikeringsrollen.

    Replikeringsslav

  6. Ställ in källservern i skrivskyddat läge.

    Innan du börjar dumpa databasen måste servern placeras i skrivskyddat läge. I skrivskyddat läge kan källan inte bearbeta några skrivtransaktioner. Utvärdera effekten på ditt företag och schemalägg det skrivskyddade fönstret under en låg belastning om det behövs.

    FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;

  7. Hämta namn och förskjutning av binär loggfil.

    show master status Kör kommandot för att fastställa det aktuella binära loggfilens namn och förskjutning.

     show master status;

    Resultatet bör se ut ungefär så här. Observera namnet på den binära filen för användning i senare steg.

    Huvudstatusresultat

Dumpa och återställa källservern

  1. Ta reda på vilka databaser och tabeller du vill replikera till Azure Database for MySQL och utför dumpen från källservern.

    Du kan använda mysqldump för att dumpa databaser från din primära server. Mer information finns i Dumpa och återställa. Det är onödigt att dumpa MySQL-biblioteket och testbiblioteket.

  2. Valfritt – Om du vill använda gtidbaserad replikering måste du identifiera GTID för den senaste transaktionen som kördes i den primära transaktionen. Du kan använda följande kommando för att notera GTID för den senaste transaktionen som kördes på huvudservern.

    show global variables like 'gtid_executed';

  3. Ange källservern till läs-/skrivläge.

    När databasen har dumpats ändrar du tillbaka MySQL-källservern till läs- och skrivläge.

    SET GLOBAL read_only = OFF;
UNLOCK TABLES;

  4. Återställ dumpfilen till den nya servern.

    Återställ dumpfilen till den server som skapades i Azure Database for MySQL-tjänsten. Mer information om hur du återställer en dumpfil till en MySQL-server finns i Dumpa och återställa. Om dumpfilen är stor laddar du upp den till en virtuell dator i Azure inom samma region som replikservern. Återställ den till Azure Database for MySQL-servern från den virtuella datorn.

  5. Valfritt – Observera GTID för den återställde servern i Azure Database for MySQL för att säkerställa att den är samma som den primära servern. Du kan använda följande kommando för att notera GTID för det GTID-rensade värdet på Azure Database for MySQL-replikservern. Värdet för gtid_purged ska vara samma som gtid_executed på huvudservern som anges i steg 2 för att GTID-baserad replikering ska fungera.

    show global variables like 'gtid_purged';

  1. Ange källservern.

    Alla datareplikeringsfunktioner utförs av lagrade procedurer. Du hittar alla procedurer i Lagrade procedurer för datareplikering. Lagrade procedurer kan köras i MySQL-gränssnittet eller MySQL Workbench.

    Om du vill länka två servrar och starta replikeringen loggar du in på målreplikservern i Azure Database for MySQL-tjänsten och anger den externa instansen som källserver. Detta görs med hjälp av den mysql.az_replication_change_master lagrade proceduren på Azure Database for MySQL-servern.

    CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', <master_port>, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');

    Valfritt – Om du vill använda gtidbaserad replikering måste du använda följande kommando för att länka de två servrarna

    call mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', <master_port>, '<master_ssl_ca>');

    • master_host: källserverns värdnamn

    • master_user: användarnamn för källservern

    • master_password: lösenord för källservern

    • master_port: portnummer som källservern lyssnar efter anslutningar på. (3306 är standardporten där MySQL lyssnar)

    • master_log_file: namn på binär loggfil från körning show master status

    • master_log_pos: binär loggposition från körning show master status

    • master_ssl_ca: CA-certifikatets kontext. Om du inte använder SSL skickar du in en tom sträng.

      Vi rekommenderar att du skickar in den här parametern som en variabel. Mer information finns i följande exempel.

    Kommentar

    Om källservern finns på en virtuell Azure-dator anger du "Tillåt åtkomst till Azure-tjänster" till "ON" så att käll- och replikservrarna kan kommunicera med varandra. Den här inställningen kan ändras från alternativen för anslutningssäkerhet . Mer information finns i Hantera brandväggsregler med hjälp av portalen .

    Exempel

    Replikering med SSL

    Variabeln @cert skapas genom att köra följande MySQL-kommandon:

    SET @cert = '-----BEGIN CERTIFICATE-----
PLACE YOUR PUBLIC KEY CERTIFICATE'`S CONTEXT HERE
-----END CERTIFICATE-----'

    Replikering med SSL konfigureras mellan en källserver som finns i domänen "companya.com" och en replikserver som finns i Azure Database for MySQL. Den här lagrade proceduren körs på repliken.

    CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, @cert);

    Replikering utan SSL

    Replikering utan SSL konfigureras mellan en källserver som finns i domänen "companya.com" och en replikserver som finns i Azure Database for MySQL. Den här lagrade proceduren körs på repliken.

    CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, '');

  2. Konfigurera filtrering.

    Om du vill hoppa över att replikera vissa tabeller från huvudservern uppdaterar replicate_wild_ignore_table du serverparametern på replikservern. Du kan ange fler än ett tabellmönster med hjälp av en kommaavgränsad lista.

    Läs dokumentationen för MySQL om du vill veta mer om den här parametern.

    Om du vill uppdatera parametern kan du använda Azure-portalen eller Azure CLI.

  3. Starta replikeringen.

    Anropa den mysql.az_replication_start lagrade proceduren för att starta replikeringen.

    CALL mysql.az_replication_start;

  4. Kontrollera replikeringsstatus.

    show slave status Anropa kommandot på replikservern för att visa replikeringsstatusen.

    show slave status;

    Om tillståndet Slave_IO_Running för och Slave_SQL_Running är "ja" och värdet Seconds_Behind_Master för är "0" fungerar replikeringen bra. Seconds_Behind_Master anger hur sent repliken är. Om värdet inte är "0" innebär det att repliken bearbetar uppdateringar.

Andra användbara lagrade procedurer för datareplikeringsåtgärder

Stoppa replikering

Om du vill stoppa replikeringen mellan käll- och replikservern använder du följande lagrade procedur:

CALL mysql.az_replication_stop;

Ta bort replikeringsrelation

Om du vill ta bort relationen mellan käll- och replikservern använder du följande lagrade procedur:

CALL mysql.az_replication_remove_master;

Hoppa över replikeringsfel

Om du vill hoppa över ett replikeringsfel och tillåta att replikeringen fortsätter använder du följande lagrade procedur:

CALL mysql.az_replication_skip_counter;

Valfritt – Om du vill använda gtidbaserad replikering använder du följande lagrade procedur för att hoppa över en transaktion

call mysql. az_replication_skip_gtid_transaction(‘<transaction_gtid>’)

Proceduren kan hoppa över transaktionen för angiven GTID. Om GTID-formatet inte är rätt eller om GTID-transaktionen redan har körts kommer proceduren inte att köras. GTID för en transaktion kan fastställas genom att parsa den binära loggen för att kontrollera transaktionshändelserna. MySQL tillhandahåller ett verktyg mysqlbinlog för att parsa binära loggar och visa deras innehåll i textformat, vilket kan användas för att identifiera GTID för transaktionen.

Viktigt!

Den här proceduren kan bara användas för att hoppa över en transaktion och kan inte användas för att hoppa över gtiduppsättning eller ange gtid_purged.

Om du vill hoppa över nästa transaktion efter den aktuella replikeringspositionen använder du följande kommando för att identifiera GTID för nästa transaktion enligt nedan.

SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos][LIMIT [offset,] row_count]

Visa binära loggresultat

Nästa steg