Replicatie van inkomende gegevens configureren in Azure Database for MariaDB

Artikel
09/22/2023

Belangrijk

Azure Database for MariaDB bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan om te migreren naar Azure Database for MySQL. Zie Wat gebeurt er met Azure Database for MariaDB? voor meer informatie over migreren naar Azure Database for MySQL

In dit artikel wordt beschreven hoe u Replicatie van inkomende gegevens instelt in Azure Database for MariaDB door de bron- en replicaservers te configureren. In dit artikel wordt ervan uitgegaan dat u enige ervaring hebt met MariaDB-servers en -databases.

Als u een replica wilt maken in de Azure Database for MariaDB-service, synchroniseert Inkomende gegevens van een mariaDB-bronserver on-premises, in virtuele machines (VM's) of in clouddatabaseservices. Replicatie van binnenkomende gegevens is gebaseerd op het binaire logbestand (binlog) met replicatie op basis van positie eigen aan MariaDB. Zie het overzicht van binlog-replicatie voor meer informatie over binlog-replicatie.

Bekijk de beperkingen en vereisten van replicatie van inkomende gegevens voordat u de stappen in dit artikel uitvoert.

Notitie

Als uw bronserver versie 10.2 of hoger is, raden we u aan om Replicatie van inkomende gegevens in te stellen met behulp van globale transactie-id.

Notitie

Dit artikel bevat verwijzingen naar de term slave, een term die Microsoft niet meer gebruikt. Zodra de term uit de software wordt verwijderd, verwijderen we deze uit dit artikel.

Een MariaDB-server maken om als replica te gebruiken

Maak een nieuwe Azure Database for MariaDB-server (bijvoorbeeld replica.mariadb.database.azure.com). De server is de replicaserver in Replicatie van inkomende gegevens.

Zie Een Azure Database for MariaDB-server maken met behulp van de Azure Portal voor meer informatie over het maken van een server.

Belangrijk

U moet de Azure Database for MariaDB server maken in de prijscategorie Algemeen of Geoptimaliseerd voor geheugen.
Maak identieke gebruikersaccounts en bijbehorende bevoegdheden.

Gebruikersaccounts worden niet gerepliceerd van de bronserver naar de replicaserver. Als u gebruikers toegang wilt geven tot de replicaserver, moet u handmatig alle accounts en bijbehorende bevoegdheden maken op de zojuist gemaakte Azure Database for MariaDB-server.
Voeg het IP-adres van de bronserver toe aan de firewallregels van de replica.

Firewallregels bijwerken met de Azure-portal of Azure CLI.

De bronserver configureren

Met de volgende stappen kunt u de MariaDB-server voorbereiden en configureren die on-premises, in een VM of in een clouddatabaseservice wordt gehost voor replicatie van inkomende gegevens. De MariaDB-server is de bron in Replicatie van inkomende gegevens.

Controleer de vereisten voor de primaire server voordat u doorgaat.
Zorg ervoor dat de bronserver zowel inkomend als uitgaand verkeer toestaat op poort 3306 en dat de bronserver een openbaar IP-adres heeft, de DNS openbaar toegankelijk is of een FQDN (Fully Qualified Domain Name) heeft.

Test de verbinding met de bronserver door verbinding te maken vanuit een hulpprogramma zoals de MySQL-opdrachtregel die wordt gehost op een andere computer of vanuit de Azure-Cloud Shell die beschikbaar is in de Azure Portal.

Als uw organisatie een strikt beveiligingsbeleid heeft en niet alle IP-adressen op de bronserver toestaat om communicatie van Azure naar uw bronserver mogelijk te maken, kunt u mogelijk de onderstaande opdracht gebruiken om het IP-adres van uw Azure Database for MariaDB-server te bepalen.
1. Meld u aan bij uw Azure Database for MariaDB met behulp van een hulpprogramma zoals de MySQL-opdrachtregel.
2. Voer de onderstaande query uit.
```
SELECT @@global.redirect_server_host;
```
  Hieronder ziet u een voorbeeld van uitvoer:
```
+-----------------------------------------------------------+
| @@global.redirect_server_host                             |
+-----------------------------------------------------------+
| e299ae56f000.tr1830.westus1-a.worker.database.windows.net |
 +-----------------------------------------------------------+
```
3. Sluit de MySQL-opdrachtregel af.
4. Voer het onderstaande uit in het ping-hulpprogramma om het IP-adres op te halen.
```
ping <output of step 2b>
```
  Bijvoorbeeld:
```
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. Configureer de firewallregels van de bronserver om het uitgevoerde IP-adres van de vorige stap op poort 3306 op te nemen.
Notitie

Dit IP-adres kan worden gewijzigd vanwege onderhouds-/implementatiebewerkingen. Deze connectiviteitsmethode is alleen bedoeld voor klanten die het zich niet kunnen veroorloven om alle IP-adressen op poort 3306 toe te staan.
Schakel binaire logboekregistratie in.

Als u wilt zien of binaire logboekregistratie is ingeschakeld op de primaire, voert u de volgende opdracht in:
```
SHOW VARIABLES LIKE 'log_bin';
```
Als de variabele log_bin de waarde ONretourneert, is binaire logboekregistratie ingeschakeld op uw server.

Als log_bin de waarde OFFwordt geretourneerd, bewerkt u het bestand my.cnf zodat log_bin=ON binaire logboekregistratie wordt ingeschakeld. Start de server opnieuw op om de wijziging door te voeren.
Instellingen voor de bronserver configureren.

Replicatie van inkomende gegevens vereist dat de parameter lower_case_table_names consistent is tussen de bron- en replicaservers. De lower_case_table_names parameter is standaard ingesteld op 1 in Azure Database for MariaDB.
```
SET GLOBAL lower_case_table_names = 1;
```
Maak een nieuwe replicatierol en stel machtigingen in.

Maak een gebruikersaccount op de bronserver dat is geconfigureerd met replicatiebevoegdheden. U kunt een account maken met behulp van SQL-opdrachten of MySQL Workbench. Als u van plan bent om te repliceren met SSL, moet u dit opgeven wanneer u het gebruikersaccount maakt.

Zie de MariaDB-documentatie voor meer informatie over het toevoegen van gebruikersaccounts op uw bronserver.

Met behulp van de volgende opdrachten heeft de nieuwe replicatierol toegang tot de bron vanaf elke computer, niet alleen de computer die als host fungeert voor de bron zelf. Geef voor deze toegang syncuser@'%' op in de opdracht om een gebruiker te maken.

Zie Accountnamen opgeven voor meer informatie over mariaDB-documentatie.

SQL-opdracht
- Replicatie met SSL
  
  Als u SSL wilt vereisen voor alle gebruikersverbindingen, voert u de volgende opdracht in om een gebruiker te maken:
```
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;
```
- Replicatie zonder SSL
  
  Als SSL niet vereist is voor alle verbindingen, voert u de volgende opdracht uit om een gebruiker te maken:
```
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';
```
MySQL Workbench

Als u de replicatierol in MySQL Workbench wilt maken, selecteert u in het deelvenster Beheerde optie Gebruikers en bevoegdheden. Selecteer vervolgens Account toevoegen.

Voer een gebruikersnaam in het veld Aanmeldingsnaam in.

Selecteer het deelvenster Beheerdersrollen en selecteer in de lijst met globale bevoegdhedende optie Replication Slave. Selecteer Toepassen om de replicatierol te maken.
Stel de bronserver in op de modus Alleen-lezen.

Voordat u een database dumpt, moet de server in de modus Alleen-lezen worden geplaatst. In de modus Alleen-lezen kan de bron geen schrijftransacties verwerken. Plan het alleen-lezenvenster tijdens een daltijd om bedrijfsimpact te voorkomen.
```
FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;
```
Haal de naam en offset van het huidige binaire logboekbestand op.

Voer de opdracht show master statusuit om de huidige naam en offset van het huidige binaire logboekbestand te bepalen.
```
show master status;
```
De resultaten moeten er ongeveer uitzien als in de volgende tabel:

Noteer de binaire bestandsnaam, omdat deze in latere stappen wordt gebruikt.
Haal de GTID-positie op (optioneel, nodig voor replicatie met GTID).

Voer de functie BINLOG_GTID_POS uit om de GTID-positie op te halen voor de bijbehorende binlog-bestandsnaam en -offset.
```
select BINLOG_GTID_POS('<binlog file name>', <binlog offset>);
```

De bronserver dumpen en herstellen

Dump alle databases van de bronserver.

Gebruik mysqldump om alle databases van de bronserver te dumpen. Het is niet nodig om de MySQL-bibliotheek en testbibliotheek te dumpen.

Zie Dumpen en herstellen voor meer informatie.
Stel de bronserver in op de lees-/schrijfmodus.

Nadat de database is gedumpt, wijzigt u de MariaDB-bronserver weer in de lees-/schrijfmodus.
```
SET GLOBAL read_only = OFF;
UNLOCK TABLES;
```
Herstel het dumpbestand naar de nieuwe server.

Herstel het dumpbestand naar de server die is gemaakt in de Azure Database for MariaDB-service. Zie Dump restore (Dumpherstel & ) voor informatie over het herstellen van een dumpbestand naar een MariaDB-server.

Als het dumpbestand groot is, uploadt u het naar een VIRTUELE machine in Azure binnen dezelfde regio als de replicaserver. Herstel deze vanaf de virtuele machine naar de Azure Database for MariaDB-server.

De bron- en replicaservers koppelen om replicatie van inkomende gegevens te starten

Stel de bronserver in.

Alle replicatiefuncties voor inkomende gegevens worden uitgevoerd door opgeslagen procedures. U vindt alle procedures in Opgeslagen procedures voor replicatie van gegevens. Opgeslagen procedures kunnen worden uitgevoerd in de MySQL-shell of MySQL Workbench.

Als u twee servers wilt koppelen en de replicatie wilt starten, meldt u zich aan bij de doelreplicaserver in de Azure DB for MariaDB-service. Stel vervolgens het externe exemplaar in als de bronserver met behulp van de mysql.az_replication_change_master opgeslagen procedure of mysql.az_replication_change_master_with_gtid op de Azure DB for MariaDB-server.
```
CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', 3306, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');
```
of
```
CALL mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', 3306, '<master_gtid_pos>', '<master_ssl_ca>');
```
- master_host: hostnaam van de bronserver
- master_user: gebruikersnaam voor de bronserver
- master_password: wachtwoord voor de bronserver
- master_log_file: de naam van het binaire logboekbestand wordt niet uitgevoerd show master status
- master_log_pos: binaire logboekpositie wordt niet uitgevoerd show master status
- master_gtid_pos: GTID-positie van uitvoering select BINLOG_GTID_POS('<binlog file name>', <binlog offset>);
- master_ssl_ca: de context van het CA-certificaat. Als u geen SSL gebruikt, geeft u een lege tekenreeks door.*
*U wordt aangeraden de parameter master_ssl_ca door te geven als een variabele. Zie de volgende voorbeelden voor meer informatie.

Voorbeelden
- Replicatie met SSL
  
  Maak de variabele @cert door de volgende opdrachten uit te voeren:
```
SET @cert = '-----BEGIN CERTIFICATE-----
PLACE YOUR PUBLIC KEY CERTIFICATE\'S CONTEXT HERE
-----END CERTIFICATE-----'
```
  Replicatie met SSL wordt ingesteld tussen een bronserver die wordt gehost in het domein companya.com en een replicaserver die wordt gehost in Azure Database for MariaDB. Deze opgeslagen procedure wordt uitgevoerd op de replica.
```
CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mariadb-bin.000016', 475, @cert);
```
- Replicatie zonder SSL
  
  Replicatie zonder SSL wordt ingesteld tussen een bronserver die wordt gehost in het domein companya.com en een replicaserver die wordt gehost in Azure Database for MariaDB. Deze opgeslagen procedure wordt uitgevoerd op de replica.
```
CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mariadb-bin.000016', 475, '');
```
Replicatie starten.

Roep de mysql.az_replication_start opgeslagen procedure aan om de replicatie te starten.
```
CALL mysql.az_replication_start;
```
Controleer de replicatiestatus.

Roep de show slave status opdracht op de replicaserver aan om de replicatiestatus weer te geven.
```
show slave status;
```
Als Slave_IO_Running en Slave_SQL_Running de status hebben yesen de waarde van Seconds_Behind_Master is, 0werkt replicatie. Seconds_Behind_Master geeft aan hoe laat de replica is. Als de waarde niet 0is, worden updates verwerkt door de replica.
Werk de bijbehorende servervariabelen bij om replicatie van inkomende gegevens veiliger te maken (alleen vereist voor replicatie zonder GTID).

Vanwege een systeemeigen replicatiebeperking in MariaDB moet u en-variabelen instellen sync_master_infosync_relay_log_info voor replicatie zonder het GTID-scenario.

Controleer de variabelen en sync_relay_log_info variabelen van sync_master_info uw replicaserver om te controleren of de replicatie van binnenkomende gegevens stabiel is en stel de variabelen in op 1.

Andere opgeslagen procedures

Replicatie stoppen

Als u de replicatie tussen de bron- en replicaserver wilt stoppen, gebruikt u de volgende opgeslagen procedure:

CALL mysql.az_replication_stop;

De replicatierelatie verwijderen

Gebruik de volgende opgeslagen procedure om de relatie tussen de bron- en replicaserver te verwijderen:

CALL mysql.az_replication_remove_master;

De replicatiefout overslaan

Als u een replicatiefout wilt overslaan en replicatie wilt toestaan, gebruikt u de volgende opgeslagen procedure:

CALL mysql.az_replication_skip_counter;

Volgende stappen

Meer informatie over replicatie van inkomende gegevens voor Azure Database for MariaDB.