Dela via

Så här konfigurerar du Azure Database for MySQL – flexibel server för datareplikering

  • Artikel

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

Den här artikeln beskriver hur du konfigurerar datareplikering i Azure Database for MySQL – flexibel server 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.

Om du vill skapa en replik i Azure Database for MySQL-instansen för flexibel server synkroniserar datareplikering data från en MySQL-källserver lokalt, på virtuella datorer eller i molndatabastjänster. Datareplikering kan konfigureras med antingen binär loggfilsbaserad replikering eller GTID-baserad replikering. Mer information om binlogreplikering finns i MySQL Replication.

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

Skapa en flexibel Azure Database for MySQL-serverinstans som ska användas som replik

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

  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 här nyligen skapade flexibla Azure Database for MySQL-serverinstansen.

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. Nätverkskrav

    • 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).

    • Om privat åtkomst (VNet-integrering) används kontrollerar du att du har anslutning mellan källservern och det virtuella nätverk där replikservern finns.

    • Se till att vi tillhandahåller plats-till-plats-anslutning till dina lokala källservrar med expressroute eller VPN. Mer information om hur du skapar ett virtuellt nätverk finns i dokumentationen för virtuellt nätverk, och särskilt snabbstartsartiklarna med stegvis information.

    • Om privat åtkomst (VNet-integrering) används i replikservern och källan är virtuell Azure-dator kontrollerar du att VNet-till VNet-anslutningen har upprättats. VNet-Vnet-peering stöds. Du kan också använda andra anslutningsmetoder för att kommunicera mellan virtuella nätverk i olika regioner, till exempel VNet till VNet-anslutning. Mer information finns i VNet-till-VNet VPN-gateway

    • Se till att reglerna för nätverkssäkerhetsgruppen för det virtuella nätverket inte blockerar utgående port 3306 (även inkommande om MySQL körs på en virtuell Azure-dator). Mer information om trafikfiltrering för virtuella nätverk NSG finns i artikeln Filtrera nätverkstrafik med nätverkssäkerhetsgrupper.

    • Konfigurera källserverns brandväggsregler så att replikserverns IP-adress tillåts.

  3. Följ lämpliga steg baserat på om du vill använda bin-log-position eller GTID-baserad datareplikering.

    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 följande steg:

    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-tjänsten på källservern (eller Starta om) 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 – flexibel server.

    SET GLOBAL lower_case_table_names = 1;

  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.

    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'@'%';

  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 en flexibel Azure Database for MySQL-server 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. 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;

    Kommentar

    Innan servern återgår till läs-/skrivläge kan du hämta GTID-informationen med hjälp av den globala variabeln GTID_EXECUTED. Detta används i det senare skedet för att ange GTID på replikservern.

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

    Återställ dumpfilen till den server som skapats i Azure Database for MySQL – flexibel server. 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– flexibel serverinstans från den virtuella datorn.

Kommentar

Om du vill undvika att ställa in databasen på skrivskyddad när du dumpar och återställer kan du använda mydumper/myloader.

Ange GTID i replikservern

  1. Hoppa över steget om du använder positionsbaserad replikering i bin-log

  2. GTID-information från dumpfilen som hämtas från källan krävs för att återställa GTID-historiken för målservern (repliken).

  3. Använd den här GTID-informationen från källan för att köra GTID-återställning på replikservern med följande CLI-kommando:

    az mysql flexible-server gtid reset --resource-group  <resource group> --server-name <replica server name> --gtid-set <gtid set from the source server> --subscription <subscription id>

Mer information finns i Återställ GTID.

Kommentar

GTID-återställning kan inte utföras på en geo-redundanssäkerhetskopia aktiverad server. Inaktivera Geo-redundans för att utföra GTID-återställning på servern. Du kan aktivera alternativet Geo-redundans igen efter GTID-återställning. GTID-återställningsåtgärden ogiltigförklarar alla tillgängliga säkerhetskopior och när geo-redundans har aktiverats igen kan det ta en dag innan geo-återställning kan utföras på servern

  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 eller mysql.az_replication_change_master_with_gtid 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>');

    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.
    • Om du använde mydumper/myloader för att dumpa databasen kan du hämta master_log_file och master_log_pos från filen /backup/metadata .

    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 i Azure Database for MySQL – flexibel server. 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);

    CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, @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 – flexibel server. 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, '');

    CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, '');

  2. Starta replikeringen.

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

    CALL mysql.az_replication_start;

  3. Kontrollera replikeringsstatus.

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

    show slave status;

    Information om rätt status för replikering finns i replikeringsmått – Replik-I/O-status och SQL-replikstatus under övervakningssidan.

    Seconds_Behind_Master Om ä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;

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

Visa binära loggresultat

Nästa steg

  • Läs mer om datareplikering för flexibel Azure Database for MySQL-server.