Condividi tramite

Come configurare la replica dei dati in ingresso di Database di Azure per MySQL - Server flessibile

  • Articolo

Questo articolo descrive come configurare Replicare i dati in Database di Azure per MySQL - Server flessibile in Database di Azure per MySQL server flessibile configurando i server di origine e di replica. Per eseguire le procedure descritte in questo articolo è necessario avere già esperienza 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, replicare i dati in Database di Azure per MySQL - Server flessibile sincronizza i dati da un server MySQL di origine in 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 ulteriori informazioni sulla replica binlog, vedere Replica di MySQL.

Prima di eseguire i passaggi descritti in questo articolo, rivedere le limitazioni e i requisiti della replica dei dati in ingresso.

Creare un'istanza di Database di Azure per server flessibile 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. Per la creazione del server vedere Avvio rapido: Creare un'istanza di Database di Azure per MySQL usando il portale di Azure. 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 a quello 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, rivedere 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, che il DNS sia accessibile pubblicamente o che abbia un nome di dominio completo (FQDN).

    • Se è in uso l'accesso privato (integrazione rete virtuale), 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 si utilizza l'accesso privato (integrazione rete virtuale) nel server di replica e l'origine è una macchina virtuale di Azure, assicurarsi che venga stabilita la connettività da rete virtuale a rete virtuale. È supportato il peering VNet-VNet. È anche possibile utilizzare altri metodi di connettività per comunicare tra reti virtuali in diverse aree, come la connessione VNet a VNet. 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 del log binario o la replica dei dati in ingresso basata su GTID.

    Verificare se la registrazione binaria è stata abilitata sul server di origine eseguendo questo comando:

    SHOW VARIABLES LIKE 'log_bin';

    Se la variabile log_bin viene restituita con il valore "ON", la registrazione binaria è abilitata sul 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. A tal fine eseguire la stessa query:

      SHOW VARIABLES LIKE 'log_bin';

  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 le autorizzazioni.

    Sul server di origine creare un account utente configurato con i privilegi di replica. Questa operazione può essere eseguita tramite i comandi SQL o uno strumento come MySQL Workbench. Valutare se si prevede di eseguire la replica con SSL, poiché è necessario specificare questa impostazione quando si crea l'utente. Per istruzioni su come aggiungere account utente sul 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 da quello 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.

    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' REQUIRE SSL;
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';

    Replica senza SSL

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

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';

  6. Impostare il server di origine sulla modalità in sola lettura.

    Prima di avviare il dump del database, il server deve essere impostato in modalità di sola lettura. In questa modalità di sola lettura, il server di 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;

  7. Ottenere l'offset e il nome 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.

    Screenshot dei Risultati dello stato master.

Eseguire il dump e ripristinare il 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.

    Per eseguire il dump dei database dal server primario è possibile usare mysqldump. 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à in lettura/scrittura.

    Dopo avere eseguito il dump del database, ripristinare la modalità di lettura/scrittura sul server MySQL di origine.

    SET GLOBAL read_only = OFF;
UNLOCK TABLES;

    Nota

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

  3. Ripristinare il file di dump nel nuovo server.

    Ripristinare il file di 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 di Database di Azure per MySQL - Server flessibile 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 utilizza la replica basata sulla posizione del log binario

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

  3. Utilizzare queste informazioni GTID dalla fonte per eseguire il reset dei GTID sul server di replica utilizzando il seguente comando CLI:

    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

  1. Impostare il server di origine.

    Tutte le funzioni di replica dei dati in ingresso vengono eseguite dalle 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 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 tramite la stored procedure mysql.az_replication_change_master o mysql.az_replication_change_master_with_gtid nel server di 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 sotto forma di 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 per Database di Azure per MySQL - Server flessibile tramite il portale di Azure.
    • 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, '');

  2. Avviare la replica.

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

    CALL mysql.az_replication_start;

  3. Verificare lo stato della replicazione.

    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

Interrompere la replica

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

CALL mysql.az_replication_stop;

Rimuovere la relazione di replica

Per rimuovere la relazione tra il server sorgente e il server replica, usare la procedura memorizzata seguente.

CALL mysql.az_replication_remove_master;

Ignora errore di replica

Per ignorare un errore di replica e permettere alla replica di continuare, usare la seguente procedura memorizzata:

CALL mysql.az_replication_skip_counter;

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

Screenshot di Mostra risultati del log binario.

Passaggio successivo

Replicare i dati in Database di Azure per MySQL - Server flessibile