This is a read-only copy of the MariaDB Knowledgebase generated on 2024-11-21. For the latest, interactive version please visit https://mariadb.com/kb/.

La replica multi-source

Replica multi-source significa che un server esegue la replica da molti master. Questa funzionalità è stata introdotta in MariaDB 10.0.

Nuova sintassi

E' possibile specificare con quale connessione master si lavora sia passando il nome della connessione al comando, sia impostando @@default_master_connection con il nome della connessione su cui si desidera lavorare.

Il nome della connessione può contenere qualsiasi carattere e deve avere una lunghezza inferiore a 64. I nomi delle connessioni sono case insensitive, cioé le lettere minuscole sono considerate uguali alle maiuscole. E' preferibile usare nomi brevi, perché verranno usati come suffisso nei relay log e nell'indice di master info.

Ecco la nuova sintassi, introdotta per gestire connessioni multiple:

La connessione originale vecchio stile è una stringa vuota ''. Non occorre usare questa connessione, se non si desidera farlo.

Per creare nuove connessioni master si usa CHANGE MASTER.
E' possibile cancellare permanentemente una connessione con RESET SLAVE "nome_connessione" ALL.

Variabili per la replica multi-source

La variabile @@default_master_connection specifica quale connessione deve essere utilizzata per default per i comandi e le variabili. Quella predefinita è '' (il nome di default delle connessioni).

Le seguenti variabili sono locali all'interno della connessione. In altre parole, mostrano il valore della connessione @@default_master_connection). Stiamo lavorando per rendere le variabili più importanti locali alla connessione.

TipoNomeSpiegazione
Variable Max_relay_log_sizeDimensioni massime del relay log. Se è 0, all'avvio viene impostato a max_binlog_size
StatusSlave_heartbeat_periodQuanto spesso deve essere richiesto al master un pacchetto heartbeat (in secondi).
StatusSlave_received_heartbeatsQuanti heartbeat sono stati ricevuti dal master.
StatusSlave_runningMostra se lo slave è in funzione. YES significa che il thread sql e il thread IO sono attivi. No significa che uno dei due non è in esecuzione. "" significa che @@default_master_connection non esiste.
Variable Sql_slave_skip_counterQuanti elementi del log della replica dovrebbero essere ignorati (si usa principalmente in caso di errori nel log).

E' possibile accedere a tutte le variabili elencate sia con SESSION, sia con GLOBAL.

Si noti che, diversamente da quanto accade in MySQL, tutte le variabili mostrano sempre il valore corrente corretto!

Esempio:

set @@default_master_connection='';
show status like 'Slave_running';
set @@default_master_connection='altra_connessione';
show status like 'Slave_running';

Se @@default_master_connection contiene un nome inesistente, si ottiene un warning.

Tutte le altre variabili relative al master sono globali e hanno effetto o solo su "" o su tutte le connessioni. Per esempio, Slave_retried_transactions ora mostra il numero totale delle transazioni che sono state ritentate su tutti gli slave

Nuove variabili di stato:

NomeSpiegazione
Com_start_all_slavesNumero di comandi START ALL SLAVES eseguiti.
Com_start_slaveNumero di comandi START SLAVE eseguiti. Sostituisce Com_slave_start.
Com_stop_slaveNumero di comandi STOP SLAVE eseguiti. Sostituisce Com_slave_stop.
Com_stop_all_slavesNumero di comandi STOP ALL SLAVES eseguiti.

SHOW ALL SLAVES STATUS ha le seguenti nuove colonne:

NomeSpiegazione
Connection_nameNome della connessione master. E' la prima variabile.
Slave_SQL_StateStato del thread SQL.
Retried_transactionsNumero di connessioni ritentate in questa connessione.
Max_relay_log_sizeDimensioni massime del relay log size in questa connessione.
Executed_log_entriesQuanti elementi del log sono stati eseguiti dallo slave.
Slave_received_heartbeatsQuanti heartbeat sono stati ricevuti dal master.
Slave_heartbeat_periodQuando spesso deve richiedere un pacchetto heartbeat al master (in secondi).

Nuovi file

Il principio di base dei nuovi file usati per la replica multi source è che hanno lo stesso nome dei file del relay log originale, con il suffisso connection_name prima dell'estensione. L'eccezione più importante è il file contenente tutte le connessioni, che si chiama come il normale master-info-file con un prefisso multi-.

Se si usa la replica multi source, vengono creati i seguenti file:

NomeSpiegazione
multi-master-info-fileIl file master-info-file (normalmente master.info) con un prefisso multi-. Contiene tutte le connessioni ai master in uso.
master-info-file-connection_name.estensioneContiene la posizione corrente del master applicata allo slave. Estensione di solito è .info
relay-log-nome_connessione.xxxxxIl nome del relay-log con un suffisso nome_connessione. xxxxx è il numero progressivo del relay log. Questo contiene i dati della replica letti dal master.
relay-log-index-nome_connessione.estensione  Contiene il nome dei file relay-log-nome_connessione.xxxxx attivi. Estensione di solito è .index
relay-log-info-file-nome_connessione.estensioneContiene la posizione corrente del master nel relay log. Estensione di solito è .info

Quando si crea un file, il nome della connessione viene convertito in lettere minuscole e tutti i caratteri speciali vengono convertiti, nello stesso modo in cui vengono convertiti i nomi delle tabelle di MySQL. Questo serve a rendere il nome del file portabile su diversi sistemi operativi.

Suggerimento:

Invece di specificare i nomi per mysqld con --relay-log, --relay-log-index, --relay-log-index, --general-log, --slow-log, --log-bin, --log-bin-index si può specificare soltanto --log-base-name, così tutte le altre variabili verranno impostate con questo prefisso.

Altre cose

  • Tutti i messaggi di errori provenienti da uno slave con un certo nome connessione, che sono scritti nel log degli errori, hanno ilprefisso Master 'connection_name':. In questo modo è più facile capire da dove proviene un errore.
  • Gli errori ER_MASTER_INFO e WARN_NO_MASTER_INFO ora includono nome_connessione.
  • Non esiste una risoluzione dei conflitti. Il presupposto è che non ci siano conflitti tra i dati fra differenti master.
  • Tutti i comandi eseguiti sono scritti nel log binario normale (niente di nuovo qui).
  • Se la variabile server log_warnings > vale 1 si ottengono nel log alcune informazioni su quando il file multi-master-info è aggiornato (principalmente per il debug).
  • SHOW [FULL] SLAVE STATUS restituisce una riga per connessione e alcune colonne aggiuntive rispetto a prima. Si noti che la prima colonna è connection_name!
  • RESET SLAVE ora elimina tutti i file del relay-log.

Casi d'uso comuni

  • Si stanno partizionando i dati su diversi master e si desidera riunirli tutti in una sola macchina per poter eseguire query analitiche.
  • Si hanno diversi database sparsi su diversi server MariaDB/MySQL e si desidera riunirli tutti in un'unica macchina come backup aggiuntivo.

Limitazioni

  • Per ora è possibile avere solo 64 master (se necessario, incrementare questo numero è triviale).
  • Ogni connessione attiva crea 2 thread (come avviene normalmente nella replica di MariaDB).
  • Occorre assicurarsi che tutti i master abbiano un valore differente per server-id. In caso contrario, si avranno problemi se si tenta di replicare da uno slave multi-source ai master.
  • E' possibile modificare max_relay_log_size per la connessione attiva, ma le nuove connessioni continueranno a usare il valore impostato all'avvio del server, che non può essere modificato a runtime.
  • L'opzione innodb-recovery-update-relay-log (funzionalità di xtradb per registrare e recuperare la posizione degli slave nel relay log) funziona solo sulla connessione predefinita ''. Poiché questa opzione non è realmente sicura e potrebbe facilmente causare una perdita di dati se si utilizzano Storage Engine diversi da InnoDB, si raccomanda di non usarla.
  • Slave_net_timeout ha effetto su tutte le connessioni. E' stato eliminato il controllo che verificava se è minore di Slave_heartbeat_period, perché in una configurazione multi-source non ha senso.

TODO

  • La replica semisincrona ('semisync_slave.so') non funziona con la multi-source. Verrà corretto per la prossima release.
  • Tutti i task aperti e i bug conosciuti della replica multi-source si trovano qui.
  • Possibilità di replicare da un master a uno slave con diversi thread.

Incompatibilità con MariaDB/MySQL 5.5

  • max_relay_log_size ora è (quasi) quasi una variabile normale e non viene modificata quando cambia il valore di max_binlog_size. Perché tutto sia compatibile con i vecchi file di configurazione, viene impostata a max_binlog_size all'avvio, se il suo valore è 0.
  • E' possibile accedere alle variabili della replica che dipendono dalla connessione attiva sia con GLOBAL, sia con SESSION.
  • Le informazioni per il recupero delle posizioni nel relay log, vengono registrate solo se innodb-recovery-update-relay-log è impostata.
  • Slave_retried_transaction ora mostra il numero totale delle transazioni che sono state ritentate, fra tutti gli slave.
  • La variabile di stato Com_slave_start è stata sostituita con Com_start_slave.
  • La variabile di stato Com_slave_stop è stata sostituita con Com_stop_slave.
  • Il comando FLUSH RELAY LOGS non è più replicato. Non sarebbe sicuro, perché i nomi delle connessioni potrebbero essere differenti sugli slave.

<</product>>

Vedi anche

  • Il lavoro su MariaDB si basa sulla descrizione del progetto di MDEV-253.
  • La base di codice originale viene da Taobao, developed by Peng Lixun. Un grande ringraziamento a loro per questa importante funzionalità!
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.