Condividi tramite

Eseguire la replica dei dati nel server flessibile del Database di Azure per MySQL

  • Articolo

La replica dei dati in ingresso consente di sincronizzare i dati da un server MySQL esterno in un’istanza del server flessibile di Database di Azure per MySQL. Il server esterno può trovarsi in locale, in macchine virtuali, in un singolo server di Database di Azure per MySQL o può essere un servizio di database ospitato da altri provider di servizi cloud. La replica dei dati in ingresso si basa sulla posizione del file di log binario (binlog) o sulla replica basata su GTID. Per altre informazioni su questo tipo di replica, vedere Replica di MySQL.

Nota

La configurazione della replica dei dati in ingresso per i server abilitati per la disponibilità elevata è disponibile solo tramite la replica basata su GTID.

Quando usare la replica dei dati in ingresso

Gli scenari principali da considerare riguardo all’uso della replica dei dati in ingresso sono i seguenti:

  • Sincronizzazione ibrida dei dati: con la replica dei dati in ingresso è possibile mantenere i dati sincronizzati tra i server locali e il server flessibile di Database di Azure per MySQL. Questa sincronizzazione aiuta a creare applicazioni ibride. Il metodo è particolarmente interessante quando si ha già un server di database locale, ma si vogliono spostare i dati in un'area più vicina agli utenti finali.
  • Sincronizzazione multi-cloud: per soluzioni cloud complesse, usare la replica dei dati in ingresso per sincronizzare i dati tra il server flessibile di Database di Azure per MySQL e diversi provider cloud, inclusi servizi di database e macchine virtuali ospitati nei cloud.
  • Migrazione: i clienti possono eseguire la migrazione in tempo minimo usando strumenti open source come MyDumper/MyLoader con replica dei dati in ingresso. Un cutover selettivo del carico di produzione dal database di origine a quello di destinazione è possibile con la replica dei dati in ingresso.

Per gli scenari di migrazione, usare il servizio Migrazione del database di Azure.

Limitazioni e considerazioni

Dati non replicati

Il database di sistema mysql nel server di origine non viene replicato. Inoltre, le modifiche apportate agli account e alle autorizzazioni nel server di origine non vengono replicate. Se si crea un account sul server di origine e questo deve accedere al server di replica, creare manualmente lo stesso account sul server di replica. Per informazioni sulle tabelle database di sistema, vedere il Manuale di MySQL.

La replica dei dati in ingresso è supportata nei server abilitati per la disponibilità elevata

Il supporto per la replica dei dati in ingresso su server abilitato per la disponibilità elevata è disponibile solo tramite la replica basata su GTID.

La stored procedure per la replica tramite GTID è disponibile in tutti i server abilitati per la disponibilità elevata in base al nome mysql.az_replication_change_master_with_gtid.

Filtro

Il parametro replicate_wild_ignore_table crea un filtro di replica per le tabelle nel server di replica. Per modificare questo parametro dal portale di Azure, passare all'istanza del server flessibile di Database di Azure per MySQL usata come replica e selezionare "Parametri del server" per visualizzare/modificare il parametro replicate_wild_ignore_table.

Requisiti

  • Nel server di origine deve essere installata almeno la versione 5.7 di MySQL.

  • È consigliabile avere la stessa versione per le versioni del server di replica e di origine. Ad esempio, in entrambi deve essere installato MySQL versione 5.7 o MySQL versione 8.0.

  • È consigliabile avere una chiave primaria in ogni tabella. Se si dispone di una tabella senza una chiave primaria, la replica potrebbe subire rallentamenti.

  • Il server di origine deve usare il motore InnoDB di MySQL.

  • L'utente deve disporre delle autorizzazioni corrette per configurare la registrazione binaria e creare nuovi utenti sul server di origine.

  • I file di log binari nel server di origine non devono essere rimossi definitivamente prima che la replica applichi tali modifiche. Se l'origine è il server flessibile di Database di Azure per MySQL, vedere come configurare binlog_expire_logs_seconds per il server flessibile o per il server singolo

  • Se nel server di origine è abilitato SSL, verificare che il certificato della CA SSL fornito per il dominio sia stato incluso nella stored procedure mysql.az_replication_change_master. Fare riferimento agli esempi seguenti e al parametro master_ssl_ca.

  • Assicurarsi che il computer che ospita il server di origine consenta il traffico sia in ingresso che in uscita sulla porta 3306.

  • Con l’accesso pubblico, assicurarsi che il server di origine disponga di un indirizzo IP pubblico, che il DNS sia accessibile pubblicamente o che il server di origine disponga di un nome di dominio completo (FQDN). Se si dispone di un endpoint privato e si è disabilitato l'accesso pubblico, la replica dei dati in ingresso non è supportata

  • Con l'accesso privato (integrazione rete virtuale), assicurarsi che il nome del server di origine possa essere risolto e sia accessibile dalla rete virtuale in cui è in esecuzione l'istanza del server flessibile di Database di Azure per MySQL. Per maggiori dettagli, vedere Risoluzione dei nomi per le risorse in reti virtuali di Azure.

Chiave primaria invisibile generata

Per MySQL versione 8.0 e successive, le chiavi primarie invisibili generate (GIPK) sono abilitate per impostazione predefinita per tutte le istanze del server flessibile di Database di Azure per MySQL. I server MySQL 8.0+ aggiungono la colonna invisibile my_row_id alle tabelle e una chiave primaria in tale colonna, in cui la tabella InnoDB viene creata senza una chiave primaria esplicita. Questa funzionalità, se abilitata potrebbe influire su alcuni dei casi d'uso della replica dei dati, come descritto di seguito:

  • La replica dei dati in ingresso ha esito negativo e viene visualizzato un errore di replica: "ERRORE 1068 (42000): più chiavi primarie definite" se il server di origine crea una chiave primaria nella tabella senza chiave primaria. Per la mitigazione, eseguire il comando sql seguente, ignorare l'errore di replica e riavviare la replica dei dati in ingresso.

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • La replica dei dati in ingresso ha esito negativo e viene visualizzato un errore di replica: "ERRORE 1075 (42000): definizione di tabella non corretta; può essere presente una sola colonna automatica e deve essere definita come chiave" se il server di origine aggiunge una colonna auto_increment come chiave univoca. Per la mitigazione, eseguire il comando sql seguente, impostare "sql_generate_invisible_primary_key" su OFF, ignorare l'errore di replica e riavviare la replica dei dati in ingresso.

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • La replica dei dati in ingresso ha esito negativo se il server di origine esegue qualsiasi altro comando SQL non supportato quando "sql_generate_invisible_primary_key" è impostato su UN. Ad esempio, creare una tabella di partizione. In questo scenario la mitigazione consiste nell'impostare "sql_generate_invisible_primary_key" come OFF e riavviare la replica dei dati in ingresso.

Contenuto correlato