Share via

Konfigurera datareplikering i Azure Database for MariaDB

  • Artikel

Viktigt!

Azure Database for MariaDB är på väg att dras tillbaka. Vi rekommenderar starkt att du migrerar till Azure Database for MySQL. Mer information om hur du migrerar till Azure Database for MySQL finns i Vad händer med Azure Database for MariaDB?.

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

För att skapa en replik i Azure Database for MariaDB-tjänsten synkroniserar Data-in Replication data från en mariaDB-källserver lokalt, på virtuella datorer eller i molndatabastjänster. Datareplikering baseras på positionsbaserad replikering med en binär loggfil (binlog) som är inbyggd i MariaDB. Mer information om binlogreplikering finns i översikten över binlogreplikering.

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

Kommentar

Om källservern är version 10.2 eller senare rekommenderar vi att du konfigurerar datareplikering med hjälp av globalt transaktions-ID.

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.

Skapa en MariaDB-server som ska användas som replik

  1. Skapa en ny Azure Database for MariaDB-server (till exempel replica.mariadb.database.azure.com). Servern är replikservern i Data-in Replication.

    Mer information om hur du skapar en server finns i Skapa en Azure Database for MariaDB-server med hjälp av Azure-portalen.

    Viktigt!

    Du måste skapa Azure Database for MariaDB-servern på prisnivåerna Generell användning eller Minnesoptimerad.

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

    Användarkonton replikeras inte från källservern till replikservern. För att ge användaren åtkomst till replikservern måste du manuellt skapa alla konton och motsvarande behörigheter på den nyligen skapade Azure Database for MariaDB-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.

Konfigurera källservern

Följande steg förbereder och konfigurerar MariaDB-servern lokalt, på en virtuell dator eller i en molndatabastjänst för datareplikering. MariaDB-servern är källan i Data-in Replication.

  1. Granska de primära serverkraven innan du fortsätter.

  2. Kontrollera att källservern tillåter både inkommande och utgående trafik på port 3306 och att källservern har en offentlig IP-adress, att DNS är offentligt tillgänglig eller 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 Azure Database for MariaDB-server.

    1. Logga in på Azure Database for MariaDB med ett verktyg som MySQL-kommandoraden.

    2. Kör frågan nedan.

      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. Kör nedanstående i ping-verktyget för att hämta IP-adressen.

      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.

    Om du vill se om binär loggning är aktiverat på den primära filen anger du följande kommando:

    SHOW VARIABLES LIKE 'log_bin';

    Om variabeln log_bin returnerar värdet ONaktiveras binär loggning på servern.

    Om log_bin returnerar värdet OFFredigerar du filen my.cnf så att log_bin=ON binär loggning aktiveras. Starta om servern för att ändringen ska börja gälla.

  4. Konfigurera källserverinställningar.

    Datareplikering kräver att parametern lower_case_table_names är konsekvent mellan käll- och replikservrarna. Parametern lower_case_table_names är inställd 1 på som standard i Azure Database for MariaDB.

    SET GLOBAL lower_case_table_names = 1;

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

    Skapa ett användarkonto på källservern som har konfigurerats med replikeringsprivilegier. Du kan skapa ett konto med hjälp av SQL-kommandon eller MySQL Workbench. Om du planerar att replikera med SSL måste du ange detta när du skapar användarkontot.

    Information om hur du lägger till användarkonton på källservern finns i MariaDB-dokumentationen.

    Genom att använda följande kommandon kan den nya replikeringsrollen komma åt källan från valfri dator, inte bara den dator som är värd för själva källan. För den här åtkomsten anger du syncuser@'%' i kommandot för att skapa en användare.

    Mer information om MariaDB-dokumentation finns i ange kontonamn.

    SQL-kommando

    • Replikering med SSL

      Om du vill kräva SSL för alla användaranslutningar anger 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 anger 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 går du till fönstret Hantering och väljer Användare och privilegier. Välj sedan Lägg till konto.

    Users and Privileges

    Ange ett användarnamn i fältet Inloggningsnamn .

    Sync user

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

    Replication Slave

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

    Innan du dumpar en databas måste servern placeras i skrivskyddat läge. I skrivskyddat läge kan källan inte bearbeta några skrivtransaktioner. För att undvika påverkan på verksamheten schemalägger du det skrivskyddade fönstret under en låg belastning.

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

  7. Hämta det aktuella binära loggfilens namn och förskjutning.

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

    show master status;

    Resultatet bör likna följande tabell:

    Master Status Results

    Observera namnet på den binära filen eftersom det kommer att användas i senare steg.

  8. Hämta GTID-positionen (valfritt, som behövs för replikering med GTID).

    Kör funktionen BINLOG_GTID_POS för att hämta GTID-positionen för motsvarande binlogfilnamn och förskjutning.

    select BINLOG_GTID_POS('<binlog file name>', <binlog offset>);

Dumpa och återställa källservern

  1. Dumpa alla databaser från källservern.

    Använd mysqldump för att dumpa alla databaser från källservern. Det är inte nödvändigt att dumpa MySQL-biblioteket och testbiblioteket.

    Mer information finns i Dumpa och återställa.

  2. Ställ in källservern i läs-/skrivläge.

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

    SET GLOBAL read_only = OFF;
UNLOCK TABLES;

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

    Återställ dumpfilen till servern som skapades i Azure Database for MariaDB-tjänsten. Se Dumpa och återställa för att återställa en dumpfil till en MariaDB-server.

    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 MariaDB-servern från den virtuella datorn.

  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 DB for MariaDB-tjänsten. Ange sedan den externa instansen som källserver med hjälp av den mysql.az_replication_change_master eller mysql.az_replication_change_master_with_gtid den lagrade proceduren på Azure DB for MariaDB-servern.

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

    eller

    CALL mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', 3306, '<master_gtid_pos>', '<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_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_gtid_pos: GTID-position från körning select BINLOG_GTID_POS('<binlog file name>', <binlog offset>);
    • 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 parametern master_ssl_ca som en variabel. Mer information finns i följande exempel.

    Exempel

    • Replikering med SSL

      Skapa variabeln @cert genom att köra följande 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 MariaDB. Den här lagrade proceduren körs på repliken.

      CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mariadb-bin.000016', 475, @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 MariaDB. Den här lagrade proceduren körs på repliken.

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

  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;

    Om Slave_IO_Running och Slave_SQL_Running är i tillståndet yes, och värdet Seconds_Behind_Master för är 0, fungerar replikeringen. Seconds_Behind_Master anger hur sent repliken är. Om värdet inte 0är bearbetar repliken uppdateringar.

  4. Uppdatera motsvarande servervariabler för att göra datareplikeringen säkrare (krävs endast för replikering utan GTID).

    På grund av en intern replikeringsbegränsning i MariaDB måste du ange sync_master_info och sync_relay_log_info variabler för replikering utan GTID-scenariot.

    Kontrollera replikserverns sync_master_info och sync_relay_log_info variablerna för att kontrollera att datareplikeringen är stabil och ange variablerna till 1.

Andra lagrade procedurer

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 replikeringsrelationen

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 replikeringsfelet

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

CALL mysql.az_replication_skip_counter;

Nästa steg

Läs mer om datareplikering för Azure Database for MariaDB.