Come configurare Database di Azure per MySQL - Replica dati server flessibili

SI APPLICA A: Database di Azure per MySQL - Server flessibile

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

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.

Per creare una replica nell'istanza del server flessibile Database di Azure per MySQL, la replica dei dati in ingresso sincronizza i dati da un server MySQL di origine locale, in macchine virtuali (VM) o nei servizi di database cloud. La replica dei dati in ingresso può essere configurata usando la replica basata sulla posizione del file binario (binlog) o la replica basata su GTID. Per altre informazioni sulla replica binlog, vedere Replica mySQL.

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

Creare un'istanza del server flessibile Database di Azure per MySQL da usare come replica

1. Creare una nuova istanza di Database di Azure per MySQL server flessibile , ad esempio replica.mysql.database.azure.com. Fare riferimento a Creare un'istanza del server flessibile Database di Azure per MySQL usando il portale di Azure per la creazione del server. Questo server è il server di "replica" per la replica dei dati in ingresso.

2. Creare gli stessi account utente e i privilegi corrispondenti.

   Gli account utente non vengono replicati dal server di origine al server di replica. Se si prevede di fornire agli utenti l'accesso al server di replica, è necessario creare manualmente tutti gli account e i privilegi corrispondenti in questa nuova istanza del server flessibile Database di Azure per MySQL creata.

Configurare il server MySQL di origine

I passaggi seguenti preparano e configurano il server MySQL ospitato in locale, in una macchina virtuale o in un servizio di database ospitato da altri provider di servizi cloud per la replica dei dati in ingresso. Questo server è l'"origine" per la replica dei dati in ingresso.

1. Prima di procedere, esaminare i requisiti del server di origine.

2. Requisiti di rete

   • Assicurarsi che il server di origine consenta il traffico in ingresso e in uscita sulla porta 3306 e che abbia un indirizzo IP pubblico, il DNS sia accessibile pubblicamente o che abbia un nome di dominio completo (FQDN).

   • Se l'accesso privato è in uso, assicurarsi di avere connettività tra il server di origine e la rete virtuale in cui è ospitato il server di replica.

   • Assicurarsi di fornire connettività da sito a sito ai server di origine locali usando ExpressRoute o VPN. Per altre informazioni sulla creazione di una rete virtuale, vedere la documentazione sulla rete virtuale e in particolare gli articoli di avvio rapido con istruzioni dettagliate.

   • Se l'accesso privato viene usato nel server di replica e l'origine è una macchina virtuale di Azure, assicurarsi che venga stabilita la connettività da rete virtuale a rete virtuale. Il peering reti virtuali è supportato. È anche possibile usare altri metodi di connettività per comunicare tra reti virtuali tra aree diverse, ad esempio la rete virtuale e la rete virtuale Connessione ion. Per altre informazioni, vedere Gateway VPN da rete virtuale a rete virtuale

   • Assicurarsi che le regole del gruppo di sicurezza di rete della rete virtuale non blocchino la porta in uscita 3306 (anche in ingresso se MySQL è in esecuzione nella macchina virtuale di Azure). Per informazioni dettagliate sul filtro del traffico dei gruppi di sicurezza di rete della rete virtuale di Azure, vedere l'articolo Filtrare il traffico di rete con gruppi di sicurezza di rete.

   • Configurare le regole del firewall del server di origine per consentire l'indirizzo IP del server di replica.

3. Seguire i passaggi appropriati in base a se si vuole usare la posizione bin-log o la replica dei dati basata su GTID.

   Replica basata sulla posizione del log bin

   Verificare se la registrazione binaria è stata abilitata nell'origine eseguendo il comando seguente:

   SHOW VARIABLES LIKE 'log_bin';
   

   Se la variabile log_bin viene restituita con il valore "ON", la registrazione binaria è abilitata nel server.

   Se log_bin viene restituito con il valore "OFF" e il server di origine è in esecuzione in locale o in macchine virtuali in cui è possibile accedere al file di configurazione (my.cnf), è possibile seguire questa procedura:

   1. Individuare il file di configurazione mySQL (my.cnf) nel server di origine. Ad esempio: /etc/my.cnf

   2. Aprire il file di configurazione per modificarlo e individuare la sezione mysqld nel file.

   3. Nella sezione mysqld aggiungere la riga seguente:

      log-bin=mysql-bin.log
      

   4. Riavviare il servizio MySQL nel server di origine (o riavviare) per rendere effettive le modifiche.

   5. Dopo il riavvio del server, verificare che la registrazione binaria sia abilitata eseguendo la stessa query di prima:

   SHOW VARIABLES LIKE 'log_bin';
   

   Replica basata su GTID

   Il server master deve essere avviato con la modalità GTID abilitata impostando la variabile gtid_mode su ON. È anche essenziale che la variabile enforce_gtid_consistency sia abilitata per assicurarsi che vengano registrate solo le istruzioni, che sono sicure per la replica GTID di MySQL.

   edizione Standard T @@GLOBAL. ENFORCE_GTID_CONSISTENCY = ON;

   edizione Standard T @@GLOBAL. GTID_MODE = ON;

   Se il server master è un'altra istanza del server flessibile Database di Azure per MySQL, questi parametri del server possono essere aggiornati anche dal portale passando alla pagina dei parametri del server.

4. 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. Questo parametro è 1 per impostazione predefinita in Database di Azure per MySQL server flessibile.

   SET GLOBAL lower_case_table_names = 1;
   

5. Creare un nuovo ruolo di replica e configurare l'autorizzazione.

   Creare un account utente nel server di origine configurato con privilegi di replica. Questa operazione può essere eseguita tramite comandi SQL o uno strumento come MySQL Workbench. Valutare se si prevede di eseguire la replica con SSL, perché sarà necessario specificarlo durante la creazione dell'utente. Per informazioni su come aggiungere account utente nel server di origine, vedere la documentazione di MySQL.

   Nei comandi seguenti il nuovo ruolo di replica creato può accedere all'origine da qualsiasi computer, non solo dal computer che ospita l'origine stessa. Questa operazione viene eseguita specificando "syncuser@'%'" nel comando per la creazione dell'utente. Per altre informazioni su come specificare i nomi degli account, vedere la documentazione di MySQL.

Comando SQL

Replica con SSL

Se SSL deve essere obbligatorio per tutte le connessioni utente, quando si crea un utente usare il comando seguente:

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, usare 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, aprire il pannello Utenti e privilegi nel pannello Gestione e quindi selezionare Aggiungi account.

Digitare il nome utente nel campo Login Name (ID di accesso).

Selezionare il pannello Ruoli Amministrazione istrative e quindi selezionare Replication Slave nell'elenco dei privilegi globali. Selezionare quindi Applica per creare il ruolo di replica.

1. Impostare il server di origine sulla modalità di sola lettura.

Prima di avviare il dump del database, il server deve essere impostato in modalità di sola lettura. In modalità di sola lettura, l'origine non sarà in grado di elaborare alcuna transazione di scrittura. Valutare l'impatto che questa impostazione può avere sulle attività aziendali e pianificare l'intervallo di impostazione in sola lettura in un orario di minore attività, se necessario.

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

1. Ottiene il nome e l'offset del file di log binario.

   Eseguire il comando show master status per determinare l'offset e il nome del file di log binario corrente.

      show master status;
   

I risultati dovrebbero essere simili ai seguenti. Assicurarsi di annotare il nome del file binario da usare nei passaggi successivi.

Eseguire il dump e il ripristino del server di origine

1. Determinare i database e le tabelle da replicare in Database di Azure per MySQL server flessibile ed eseguire il dump dal server di origine.

   È possibile usare mysqldump per eseguire il dump dei database dal server primario. Per informazioni dettagliate, vedere Dump e ripristino. Non è necessario eseguire il dump della libreria MySQL e della libreria di test.

2. Impostare il server di origine sulla modalità di lettura/scrittura.

   Dopo il dump del database, modificare di nuovo il server MySQL di origine in modalità di lettura/scrittura.

   SET GLOBAL read_only = OFF;
   UNLOCK TABLES;
   

[!NOTE]

Prima che il server venga impostato nuovamente sulla modalità di lettura/scrittura, è possibile recuperare le informazioni GTID usando la variabile globale GTID_EXECUTED. Lo stesso verrà usato nella fase successiva per impostare GTID nel server di replica

3. Ripristinare il file dump nel nuovo server.

   Ripristinare il file dump nel server creato in Database di Azure per MySQL server flessibile. Per informazioni su come ripristinare un file di dump in un server MySQL, vedere Dump e ripristino. Se il file di dump ha grandi dimensioni, caricarlo in una macchina virtuale in Azure nella stessa area del server di replica. Ripristinarlo nell'istanza del server flessibile Database di Azure per MySQL dalla macchina virtuale.

Nota

Se si vuole evitare di impostare il database in lettura solo quando si esegue il dump e il ripristino, è possibile usare mydumper/myloader.

Impostare GTID nel server di replica

1. Ignorare il passaggio se si usa la replica basata sulla posizione del log bin

2. Per reimpostare la cronologia GTID del server di destinazione (replica) è necessario specificare le informazioni GTID del file di dump ottenuto dall'origine.

3. Usare queste informazioni GTID dall'origine per eseguire la reimpostazione GTID nel server di replica usando il comando dell'interfaccia della riga di comando seguente:

   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>
   

Per altri dettagli, vedere GTID Reset.For more details refer GTID Reset.

Nota

La reimpostazione GTID non può essere eseguita in un server abilitato per il backup con ridondanza geografica. Disabilitare la ridondanza geografica per eseguire la reimpostazione GTID nel server. È possibile abilitare nuovamente l'opzione di ridondanza geografica dopo la reimpostazione gtid. L'azione di reimpostazione GTID invalida tutti i backup disponibili e pertanto, una volta abilitata di nuovo la ridondanza geografica, potrebbe essere necessario un giorno prima che il ripristino geografico possa essere eseguito nel server

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

1. Impostare il server di origine.

   Tutte le funzioni di replica dei dati in ingresso vengono eseguite dalle stored procedure. È possibile trovare tutte le procedure in Stored procedure di replica dei dati in . Le stored procedure possono essere eseguite nella shell di 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 MySQL e impostare l'istanza esterna come server di origine. Questa operazione viene eseguita usando la mysql.az_replication_change_master stored procedure o mysql.az_replication_change_master_with_gtid nel server Database di Azure per MySQL.

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: nome host del server di origine
• master_user: nome utente per il server di origine
• master_password: password per il server di origine
• master_port: numero di porta in cui il server di origine è in ascolto delle connessioni. (3306 è la porta predefinita in cui MySQL è in ascolto)
• 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_ssl_ca: contesto del certificato della CA. Se non si usa SSL, passare una stringa vuota.

È consigliabile passare questo parametro in come variabile. Per altre informazioni, vedere gli esempi seguenti.

Nota

• Se il server di origine è ospitato in una macchina virtuale di Azure, impostare "Consenti l'accesso ai servizi di Azure" su "ON" per consentire ai server di origine e di replica di comunicare tra loro. Questa impostazione può essere modificata dalle opzioni di sicurezza delle connessioni. Per altre informazioni, vedere Gestire le regole del firewall tramite il portale.
• Se è stato usato mydumper/myloader per eseguire il dump del database, è possibile ottenere il master_log_file e master_log_pos dal file /backup/metadata .

Esempi

Replica con SSL

La variabile @cert viene creata eseguendo i comandi MySQL 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 dominio "companya.com" e un server di replica ospitato in Database di Azure per MySQL server flessibile. Sulla replica viene eseguita questa stored procedure.

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);

Replica senza SSL

La replica senza SSL viene configurata tra un server di origine ospitato nel dominio "companya.com" e un server di replica ospitato in Database di Azure per MySQL server flessibile. Sulla replica viene eseguita questa stored procedure.

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, '');

1. Avviare la replica.

   Chiamare la stored procedure per avviare la mysql.az_replication_start replica.

   CALL mysql.az_replication_start;
   

2. Controllare lo stato della replica.

   Chiamare il comando show slave status sul server di replica per visualizzare lo stato della replica.

   show slave status;
   

Per conoscere lo stato corretto della replica, fare riferimento alle metriche di replica - Stato I/O della replica e Stato SQL della replica nella pagina di monitoraggio.

Se è Seconds_Behind_Master "0", la replica funziona correttamente. Seconds_Behind_Master indica il ritardo della replica. Se il valore non è "0", significa che la replica sta elaborando gli aggiornamenti.

Altre stored procedure utili per le operazioni di replica dei dati in ingresso

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 un errore di replica

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

CALL mysql.az_replication_skip_counter;

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

Passaggi successivi

• Altre informazioni sulla replica dei dati in ingresso per Database di Azure per MySQL server flessibile.