Share via

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

  • Articolo

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

La replica dei dati in ingresso consente di sincronizzare i dati da un server MySQL esterno in un'istanza del server flessibile Database di Azure per MySQL. Il server esterno può essere locale, in macchine virtuali, Database di Azure per MySQL server singolo o 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 sulla replica binlog, vedere Replica mySQL.

Nota

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

Quando usare la replica dei dati in ingresso

Gli scenari principali da considerare sull'uso della replica dei dati in sono:

  • Sincronizzazione dati incronizzazione ibrida: con la replica dei dati in ingresso è possibile mantenere sincronizzati i dati tra i server locali e Database di Azure per MySQL server flessibile. Questa sincronizzazione consente di 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 Database di Azure per MySQL server flessibile e diversi provider di servizi cloud, incluse le macchine virtuali e i servizi di database ospitati in tali 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(Servizio Migrazione del database).

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 nel server di origine e questo account deve accedere al server di replica, creare manualmente lo stesso account nel server di replica. Per comprendere le tabelle nel 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 per il 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 dalla portale di Azure, passare all'istanza del server flessibile Database di Azure per MySQL usata come replica e selezionare "Parametri server" per visualizzare/modificare il replicate_wild_ignore_table parametro.

Requisiti

  • La versione del server di origine deve essere almeno MySQL versione 5.7.
  • È consigliabile avere la stessa versione per le versioni del server di origine e di replica. Ad esempio, entrambi devono essere MySQL versione 5.7 o entrambi devono essere MySQL versione 8.0.
  • È consigliabile avere una chiave primaria in ogni tabella. Se si dispone di una tabella senza una chiave primaria, è possibile che si verifichi un rallentamento nella replica.
  • Il server di origine deve usare il motore InnoDB mySQL.
  • L'utente deve disporre delle autorizzazioni appropriate per configurare la registrazione binaria e creare nuovi utenti nel server di origine.
  • I file di log binari nel server di origine non devono essere eliminati prima che la replica applichi tali modifiche. Se l'origine è Database di Azure per MySQL server flessibile, vedere come configurare binlog_expire_logs_seconds per server flessibile o server singolo
  • Se il server di origine dispone di SSL abilitato, verificare che il certificato DELLA CA SSL fornito per il dominio sia stato incluso nella mysql.az_replication_change_master stored procedure. Fare riferimento agli esempi seguenti e al master_ssl_ca parametro .
  • Assicurarsi che il computer che ospita il server di origine consenta il traffico in ingresso e in uscita sulla porta 3306.
  • Con l'accesso pubblico, assicurarsi che il server di origine disponga di un indirizzo IP pubblico, che DNS sia accessibile pubblicamente o che il server di origine disponga di un nome di dominio completo (FQDN).
  • Con l'accesso privato, assicurarsi che il nome del server di origine possa essere risolto ed è accessibile dalla rete virtuale in cui è in esecuzione l'istanza del server flessibile Database di Azure per MySQL. (Per altri dettagli, visita Risoluzione dei nomi per le risorse nelle 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 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 può 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 SQL non supportato quando "sql_generate_invisible_primary_key" è ATTIVATO. 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.

Passaggi successivi