Configurare la replica dei dati in Database di Azure per MariaDB

Articolo
10/26/2023

Importante

Database di Azure per MariaDB è sul percorso di ritiro. È consigliabile eseguire la migrazione a Database di Azure per MySQL. Per altre informazioni sulla migrazione a Database di Azure per MySQL, vedere What's happening to Database di Azure per MariaDB?.

Questo articolo descrive come configurare la replica dei dati in Database di Azure per MariaDB configurando i server di origine e di replica. Questo articolo presuppone che si disponga di un'esperienza precedente con i server e i database MariaDB.

Per creare una replica nel servizio Database di Azure per MariaDB, Replica dati in ingresso sincronizza i dati da un server MariaDB di origine locale, in macchine virtuali o nei servizi di database cloud. La replica dei dati in ingresso si basa sulla replica nativa di MariaDB in base alla posizione di file di log binari (binlog). Per altre informazioni su questo tipo di replica, vedere binlog replication overview (Panoramica della replica basata su binlog).

Esaminare le limitazioni e i requisiti della replica dei dati prima di eseguire i passaggi descritti in questo articolo.

Nota

Se il server di origine è versione 10.2 o successiva, è consigliabile configurare la replica dei dati in ingresso usando l'ID transazione globale.

Nota

Questo articolo contiene riferimenti al termine slave, che Microsoft non usa più. Quando il termine verrà rimosso dal software, verrà rimosso anche dall'articolo.

Creare un server MariaDB da usare come replica

Creare un nuovo server Database di Azure per MariaDB , ad esempio replica.mariadb.database.azure.com. Il server è il server di replica nella replica dati in ingresso.

Per informazioni sulla creazione del server, vedere Creare un server Database di Azure per MariaDB usando il portale di Azure.

Importante

È necessario creare il server Database di Azure per MariaDB nei piani tariffari Per utilizzo generico o Ottimizzato per la memoria.
Creare account utente identici e privilegi corrispondenti.

Gli account utente non vengono replicati dal server di origine al server di replica. Per fornire all'utente l'accesso al server di replica, è necessario creare manualmente tutti gli account e i privilegi corrispondenti nel server Database di Azure per MariaDB appena creato.
Aggiungere l'indirizzo IP del server di origine alle regole del firewall della replica.

Aggiornare le regole firewall usando il portale di Azure o l'interfaccia della riga di comando di Azure.

Configurare il server di origine

I passaggi seguenti preparano e configurano il server MariaDB ospitato in locale, in una macchina virtuale o in un servizio di database cloud per la replica dei dati in ingresso. Il server MariaDB è l'origine nella replica dei dati in ingresso.

Prima di procedere, esaminare i requisiti del server primario.
Verificare che il server di origine consenta il traffico sia in ingresso che in uscita sulla porta 3306 e che il server di origine abbia un indirizzo IP pubblico, il DNS sia accessibile pubblicamente o abbia un nome di dominio completo (FQDN).

Testare la connettività al server di origine tentando di connettersi da uno strumento, ad esempio la riga di comando MySQL ospitata in un altro computer o da Azure Cloud Shell disponibile nella portale di Azure.

Se l'organizzazione ha criteri di sicurezza rigorosi e non consente a tutti gli indirizzi IP nel server di origine di abilitare la comunicazione da Azure al server di origine, è possibile usare il comando seguente per determinare l'indirizzo IP del server di Database di Azure per MariaDB.
1. Accedere al Database di Azure per MariaDB usando uno strumento come la riga di comando di MySQL.
2. Eseguire la query seguente.
```
SELECT @@global.redirect_server_host;
```
  Di seguito è riportato un output di esempio:
```
+-----------------------------------------------------------+
| @@global.redirect_server_host                             |
+-----------------------------------------------------------+
| e299ae56f000.tr1830.westus1-a.worker.database.windows.net |
 +-----------------------------------------------------------+
```
3. Uscire dalla riga di comando di MySQL.
4. Eseguire quanto segue nell'utilità ping per ottenere l'indirizzo IP.
```
ping <output of step 2b>
```
  Ad esempio:
```
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. Configurare le regole del firewall del server di origine per includere l'indirizzo IP restituito del passaggio precedente sulla porta 3306.
Nota

Questo indirizzo IP può cambiare a causa di operazioni di manutenzione/distribuzione. Questo metodo di connettività è destinato solo ai clienti che non possono permettersi di consentire tutti gli indirizzi IP sulla porta 3306.
Attivare la registrazione binaria.

Per verificare se la registrazione binaria è abilitata nel database primario, immettere il comando seguente:
```
SHOW VARIABLES LIKE 'log_bin';
```
Se la variabile restituisce log_bin il valore ON, la registrazione binaria è abilitata nel server.

Se log_bin restituisce il valore OFF, modificare il file my.cnf in modo da log_bin=ON attivare la registrazione binaria. Riavviare il server per rendere effettiva la modifica.
Configurare le impostazioni del server di origine.

La replica dei dati in ingresso richiede che il parametro lower_case_table_names sia coerente tra i server di origine e di replica. Il lower_case_table_names parametro è impostato su 1 per impostazione predefinita in Database di Azure per MariaDB.
```
SET GLOBAL lower_case_table_names = 1;
```
Creare un nuovo ruolo di replica e configurare le autorizzazioni.

Creare un account utente nel server di origine configurato con privilegi di replica. È possibile creare un account usando i comandi SQL o MySQL Workbench. Se si prevede di eseguire la replica con SSL, è necessario specificarlo quando si crea l'account utente.

Per informazioni su come aggiungere account utente nel server di origine, vedere la documentazione di MariaDB.

Usando i comandi seguenti, il nuovo ruolo di replica può accedere all'origine da qualsiasi computer, non solo dal computer che ospita l'origine stessa. Per questo accesso, specificare syncuser@'%' nel comando per creare un utente.

Per altre informazioni sulla documentazione di MariaDB, vedere Specifica dei nomi degli account.

Comando SQL
- Replica con SSL
  
  Per richiedere SSL per tutte le connessioni utente, immettere il comando seguente per creare un utente:
```
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;
```
- Replica senza SSL
  
  Se SSL non è necessario per tutte le connessioni, immettere il comando seguente per creare un utente:
```
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';
```
MySQL Workbench

Per creare il ruolo di replica in MySQL Workbench, nel riquadro Gestione selezionare Utenti e privilegi. Selezionare quindi Aggiungi account.

Immettere un nome utente nel campo Nome account di accesso.

Selezionare il pannello Ruoli Amministrazione istrative e quindi nell'elenco Privilegi globali selezionare Slave di replica. Selezionare Applica per creare il ruolo di replica.
Impostare il server di origine sulla modalità di sola lettura.

Prima di eseguire il dump di un database, il server deve essere posizionato in modalità di sola lettura. In modalità di sola lettura, l'origine non può elaborare transazioni di scrittura. Per evitare l'impatto aziendale, pianificare la finestra di sola lettura durante un periodo di minore attività.
```
FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;
```
Ottiene il nome e l'offset del file di log binario corrente.

Per determinare il nome e l'offset del file di log binario corrente, eseguire il comando show master status.
```
show master status;
```
I risultati dovrebbero essere simili alla tabella seguente:

Si noti il nome del file binario, perché verrà usato nei passaggi successivi.
Ottenere la posizione GTID (facoltativa, necessaria per la replica con GTID).

Eseguire la funzione BINLOG_GTID_POS per ottenere la posizione GTID per il nome e l'offset del file binlog corrispondenti.
```
select BINLOG_GTID_POS('<binlog file name>', <binlog offset>);
```

Eseguire il dump e il ripristino del server di origine

Eseguire il dump di tutti i database dal server di origine.

Usare mysqldump per eseguire il dump di tutti i database dal server di origine. Non è necessario eseguire il dump della libreria MySQL e della libreria di test.

Per altre informazioni, vedere Dump e ripristino.
Impostare il server di origine sulla modalità di lettura/scrittura.

Dopo il dump del database, modificare di nuovo il server MariaDB di origine in modalità di lettura/scrittura.
```
SET GLOBAL read_only = OFF;
UNLOCK TABLES;
```
Ripristinare il file dump nel nuovo server.

Ripristinare il file di dump nel server creato nel servizio Database di Azure per MariaDB. Vedere Dump e ripristino per informazioni su come ripristinare un file dump in un server MariaDB.

Se il file di dump è di grandi dimensioni, caricarlo in una macchina virtuale in Azure all'interno della stessa area del server di replica. Ripristinarlo nel server Database di Azure per MariaDB dalla macchina virtuale.

Collegare i server di origine e di replica per avviare la replica dei dati in ingresso

Impostare il server di origine.

Tutte le funzioni di replica dei dati in ingresso vengono eseguite tramite stored procedure. Per informazioni su tali procedure, vedere Stored procedure per la replica dei dati in ingresso. Le stored procedure possono essere eseguite nella shell MySQL o in MySQL Workbench.

Per collegare due server e avviare la replica, accedere al server di replica di destinazione nel servizio Database di Azure per MariaDB. Impostare quindi l'istanza esterna come server di origine usando la mysql.az_replication_change_master stored procedure o mysql.az_replication_change_master_with_gtid nel server database di Azure per MariaDB.
```
CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', 3306, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');
```
oppure
```
CALL mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', 3306, '<master_gtid_pos>', '<master_ssl_ca>');
```
- master_host: nome host del server di origine
- master_user: nome utente per il server di origine
- master_password: password per il server di origine
- master_log_file: nome del file di log binario da show master status in esecuzione
- master_log_pos: posizione del file di log binario da show master status in esecuzione
- master_gtid_pos: posizione GTID dall'esecuzione select BINLOG_GTID_POS('<binlog file name>', <binlog offset>);
- master_ssl_ca: contesto del certificato della CA. Se non si usa SSL, passare una stringa vuota.*
*È consigliabile passare il parametro master_ssl_ca come variabile. Per altre informazioni, vedere gli esempi seguenti.

Esempi
- Replica con SSL
  
  Creare la variabile @cert eseguendo i comandi seguenti:
```
SET @cert = '-----BEGIN CERTIFICATE-----
PLACE YOUR PUBLIC KEY CERTIFICATE\'S CONTEXT HERE
-----END CERTIFICATE-----'
```
  La replica con SSL viene configurata tra un server di origine ospitato nel companya.com di dominio e un server di replica ospitato in Database di Azure per MariaDB. Sulla replica viene eseguita questa stored procedure.
```
CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mariadb-bin.000016', 475, @cert);
```
- Replica senza SSL
  
  La replica senza SSL viene configurata tra un server di origine ospitato nel companya.com di dominio e un server di replica ospitato in Database di Azure per MariaDB. Sulla replica viene eseguita questa stored procedure.
```
CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mariadb-bin.000016', 475, '');
```
Avviare la replica.

Chiamare la stored procedure per avviare la mysql.az_replication_start replica.
```
CALL mysql.az_replication_start;
```
Controllare lo stato della replica.

Chiamare il comando show slave status sul server di replica per visualizzare lo stato della replica.
```
show slave status;
```
Se Slave_IO_Running e Slave_SQL_Running sono nello stato yese il valore di Seconds_Behind_Master è 0, la replica funziona. Seconds_Behind_Master indica il ritardo della replica. Se il valore non 0è , la replica sta elaborando gli aggiornamenti.
Aggiornare le variabili server corrispondenti per rendere più sicura la replica dei dati in ingresso (necessaria solo per la replica senza GTID).

A causa di una limitazione di replica nativa in MariaDB, è necessario impostare sync_master_info e sync_relay_log_info variabili nella replica senza lo scenario GTID.

Controllare le variabili e sync_relay_log_info del server di sync_master_info replica per assicurarsi che la replica dei dati in ingresso sia stabile e impostare le variabili su 1.

Altre stored procedure

Arrestare la replica

Per arrestare la replica tra il server di origine e di replica, usare la stored procedure seguente:

CALL mysql.az_replication_stop;

Rimuovere la relazione di replica

Per rimuovere la relazione tra il server di origine e di replica, utilizzare la stored procedure seguente:

CALL mysql.az_replication_remove_master;

Ignorare l'errore di replica

Per ignorare un errore di replica e consentire la replica, usare la stored procedure seguente:

CALL mysql.az_replication_skip_counter;

Passaggi successivi

Leggere altre informazioni sulla replica dei dati in ingresso per Database di Azure per MariaDB.