Saltare selettivamente la replica degli eventi del binlog
Contents
Normalmente, tutte le modifiche sono registrate come eventi nel binlog e sono anche replicate in tutti gli slave (anche se possono ancora essere filtrate con le opzioni --replicate-do-xxx, --replicate-ignore-xxx
e simili). Tuttavia, a volte può essere desiderabile che alcuni eventi siano registrati nel binlog, ma non replicati dagli slave, dove la distinzione tra gli eventi non dovrebbe essere replicata o non è sotto il controllo dell'applicazione che esegue le modifiche.
Questo può essere utile se un'applicazione effettua una replica esterna al server, non attraverso la replica built-in, o se ha dei dati che non devono essere replicati per una qualsiasi ragione.
Questo è possibile grazie a due nuove variabili di sistema introdotte in MariaDB 5.5:
Variabile di sessione del master: @@skip_replication
Quando questa variabile è impostata a true, le seguenti modifiche vengono registrate nel binlog con il flag @@skip_replication impostato. Tali eventi non saranno replicati dagli eventi che sono stati avviati con l'opzione --replicate-events-marked-for-skip impostata a un valore diverso da REPLICATE (che è il default).
| Nome variabile | skip_replication |
|---|---|
| Contesto | Sessione |
| Tipo di accesso | Dinamico |
| Tipo di dato | bool |
| Valore predefinito | OFF |
L'opzione @@skip_replication ha effetto solo se il log binario è abilitato e @@sql_log_bin è impostato a true.
Non è possibile modificare @@skip_replication nel mezzo di una transazione; questo per evitare che solo una parte della transazione sia registrata nel log, mentre un'altra non sia registrata. Prima di modificare la variabile, è necessario terminare la transazione corrente con COMMIT/ROLLBACK.
Opzione dello slave: --replicate-events-marked-for-skip
Questa opzione dice allo slave se replicare o meno gli eventi marcati con il flag @@skip_replication. Il default è REPLICATE, e questo assicura che tutti gli eventi vengano replicati. Se impostato a FILTER_ON_SLAVE, gli eventi così marcati verranno ignorati dallo slave e non replicati. Se impostato a FILTER_ON_MASTER, il filtraggio verrà effettuato dal master, risparmiando così traffico di rete perché gli eventi non vengono inviati allo slave.
| Nome variabile | replicate_events_marked_for_skip |
|---|---|
| Contesto | Globale |
| Tipo di accesso | Dinamico |
| Tipo di dato | enum: REPLICATE | FILTER_ON_SLAVE | FILTER_ON_MASTER |
| Valore predefinito | REPLICATE |
Nota: replicate_events_marked_for_skip è una variabile dinamica (può essere modificata senza riavviare il server), tuttavia i thread slave devono essere terminati prima della modifica, altrimenti si otterrà un errore.
Quando gli eventi vengono filtrati a causa di @@skip_replication, il filtraggio avviene sul master; in altre parole, l'evento non viene affatto inviato allo slave. Se molti eventi vengono filtrati in questo modo, lo slave potrebbe restare inattivo a lungo in attesa di comunicazioni dal master. Questo di per sé non è un problema, ma occorre tenerlo a mente quando si interroga lo slave sugli eventi che vengono filtrati. Per esempio START SLAVE UNTIL <posizione> si ferma quando incontra il primo evento non filtrato alla data posizione o più avanti. Se l'evento che si trova in quella posizione è stato filtrato, il thread slave si ferma solo quando incontra il successivo evento non filtrato. In effetti, se un evento è filtrato, per lo slave è come se non fosse stato scritto nel binlog del maste.
Si noti che quando gli eventi vengono filtrati da uno slave, i dati nel suo database saranno differenti da quelli che si trovano nel master. E' responsabilità dell'applicazione replicarli senza utilizzare la replica built-in oppure assicurarsi della coerenza dell'operazione. In caso contrario è possibile che la replica produca errori come, per esempio, violazioni di vincoli UNIQUE o altri problemi che la costringeranno ad arrestarsi; per riavviarla sarà necessario un intervento manuale.
La variabile di sessione @@skip_replication può essere modificata anche se non si dispone di privilegi particolari. In questo modo le applicazioni potranno cambiarne il valore senza avere il permesso SUPER. Occorre però ricordarsi che quando si utilizzano slave che hanno --replicate-events-marked-for-skip con un valore diverso da REPLICATE, sarà possibile effettuare modifiche che non verranno replicate.
skip_replication e sql_log_bin
@@sql_log_bin e @@skip_replication sono in qualche modo simili, perché entrambi possono essere usati per impedire che una modifica nel master venga replicata nello slave. La differenza è che con @@skip_replication
tali modifiche vengono comunque scritte nel binlog e la replica degli eventi viene saltata solo dagli slave che sono configurati per farlo, cioè quelli con --replicate-events-marked-for-skip diverso da REPLICATE. Invece con @@sql_log_bin, gli eventi non vengono registrati nel binlog, perciò non saranno nemmeno replicati nello slave.
skip_replication e il binlog
Quando gli eventi nel binlog sono marcati con @@skip_replication flag, questo valore verrà conservato se il dump viene effettuato con il programma mysqlbinlog e riapplicati su un server con il programma mysql client. Similarmente, l'istruzione BINLOG impedisce che il flag venga modificato. Anche uno slave avviato con --log-slave-updates che non filtri gli eventi (--replicate-events-marked-for-skip=REPLICATE) preserverà il flag se gli eventi registrati nel binlog dello slave.
