Binlog MySQL Replication è una "borsa del male". Ci sono buone alternative?

Question

Ho onestamente provato this left e right e trovo ancora che il mio server mirror, impostato come slave di replica, sia ancora indietro. La base di utenti della mia app continua a crescere e ora ho raggiunto il punto in cui non riesco a continuare a "chiudere". per "risincronizzare" database (nemmeno nei fine settimana).

Comunque, la mia domanda: esistono alternative plausibili, convenienti , alla replica binlog? Ho due server, quindi non prenderei in considerazione l'acquisto di un terzo per il bilanciamento del carico, a meno che non sia l'unica opzione.

Saluti,

/ mp

Answer 1

Il tuo master viene eseguito in parallelo e il tuo slave viene eseguito in serie. Se il tuo master è in grado di elaborare 1,5 ore di inserimenti / aggiornamenti / esecuzioni in 1 ora reale, lo slave resterà indietro.

Se non riesci a trovare modi per migliorare le prestazioni di scrittura sullo slave (più memoria, dischi più veloci, rimuovere indici non necessari), hai riscontrato una limitazione nell'architettura delle tue applicazioni. Alla fine colpirai un punto in cui non puoi eseguire le modifiche in tempo reale con la stessa velocità con cui il tuo master può eseguirle in parallelo.

Molti grandi siti frammentano i loro database: considera di dividere il tuo master + slave in più cluster master + slave. Quindi suddividere la base clienti tra questi cluster. Quando uno schiavo inizia a rimanere indietro, è il momento di aggiungere un altro cluster.

Non è economico, ma a meno che tu non riesca a trovare un modo per fare in modo che la replica binlog esegua le istruzioni in parallelo, probabilmente non troverai un modo migliore per farlo.

Aggiornamento (2017) : MySQL ora supporta thread di lavoro slave parallelo . Ci sono ancora molte variabili che causeranno uno slave indietro, ma gli slave non devono più scrivere in ordine seriale. La scelta di preservare l'ordine di commit dei thread slave paralleli è un'opzione importante per verificare se lo stato esatto dello slave in qualsiasi momento è critico.

Answer 2

Hai provato: 1) SET innodb_flush_log_at_trx_commit = 0 2) SET sync_binlog = 0

Entrambi aiuteranno ad accelerare lo Slave con un piccolo livello di rischio aggiuntivo in caso di guasto del server.

Answer 3

Probabilmente sarebbe utile aggiungere memoria allo slave. Siamo passati da 32 a 128 mega e il ritardo più o meno è andato via. Ma non è né economico né sarà sufficiente in tutte le situazioni.

L'acquisto di un terzo server probabilmente non sarà di grande aiuto, ma molto probabilmente otterrai un altro slave in ritardo.