Mysql Binlog Limitazioni

Question

Ho un'istanza MySQL che funziona su AWS, con circa 5000 inserti al secondo.Qualche idea di ciò che l'impatto sulle prestazioni sarà se utilizzo Binlog (Row) e un tailer Binlog?

Controlla questo link

Dalla mia comprensione, un tailer di Bin Log inserisce periodicamente il binlog MySQL per rendere possibile una connessione dati "in tempo reale".Il sarto del binlog viene eseguito in nodejs.

Il punto è, devo usare MySQL e voglio usare Meteor per ottenere i dati in tempo reale ai miei clienti.Da qui la mia idea di usare questo tailer Binlog.

Poiché il DB mySQL sarà riempito abbastanza intensamente (5000 inserti al secondo), voglio sapere a quale punto il tailer BinLog / Binlog ottiene gravi problemi di prestazioni.

GRSS, TOM

Answer 1

Ho sviluppato software con funzionalità simili, la possibilità di utilizzare il flusso di replica MySQL (Binary Log, Binlog) per acquisire eventi in tempo reale in tempo reale in risposta agli inserti / aggiornamenti / cancella nel database.

Ecco alcune osservazioni che ho fatto per quanto riguarda le prestazioni. Fortunatamente, i potenziali punti caldi sono in gran parte indipendenti l'uno dall'altro.

Assumerò, dal momento che non avevo familiarità con il pacchetto del nodo che hai citato e ho appena dato il loro codice una revisione cursale, che non sono effettivamente "taching" il binlog attraverso il polling, ma stanno effettivamente emulando uno schiavo / replica server e connessione al master e richiedendo il flusso di replica.

Il primo potenziale bottiglia di bottiglia è la capacità del master di scrivere la quantità di dati Binlog richiesti (Thishingput I / O è il Cobstraint primario). Se il master sta già accedendo al formato ROW, questo problema è già risolto. In caso contrario, quindi passare il formato Binlog e vedere. I Preferisco Formato ROW, in ogni caso, perché è molto utile per il recupero dei dati quando le query vanno male o l'applicazione fa qualcosa per i dati che non dovrebbe avere. È possibile (utilizzando strumenti di terze parti) per acquisire ciò che è successo e invertirlo - nella configurazione predefinita, quando si verifica un eliminazione (ad esempio) i dati cancellati vengono effettivamente scritti nel registro binario.

Il punto successivo del consumo di risorse è la connessione slave effettuata da tale strumento per il master, in cui il master spinge i dati. Un malinteso comune è che uno schiavo "sondaggi" del Maestro. In effetti, lo slave avvia la connessione, ma il master spinge i dati. Questo è in realtà un carico sul master che ha pochissimo impatto sulle prestazioni quando il numero di slave collegato è piccolo (dire, 5 o meno). Questo carico può essere eliminato dal master interamente collegando il "Binlog Tailor" non al master, ma a uno slave esistente del master, con log_slave_updates configurato.

Il trasporto dei dati dal master allo pseudo-slave può mangiare una larghezza di banda di rete significativa, quindi la tua utilità esterna dovrebbe supportare il protocollo di compressione client / server MySQL per ridurre questa larghezza di banda. Abilitazione di questa funzionalità può ottenere rapporti di compressione di 10: 1 a seconda del carico utile.

Il punto di dolore finale è l'utilità esterna stessa. Il formato MySQL Binlog è un formato binario molto strettamente imballato (da qui "Binary Log") che deve essere analizzato e decodificato. L'efficienza con cui l'utilità esterna può disimballare e manipolare questo flusso di dati determinerà quanto è vicino a tempo reale gli eventi rilevati possono essere emessi, poiché il codice inefficiente causerà il ritardo del flusso di eventi decisi più avanti e ulteriormente dietro il master, anche se questo fattore non avrà alcun impatto sulle prestazioni sul server principale stesso.

In breve, se il tuo master può gestire il carico di lavoro di generare binlog in formato riga per il volume del traffico che ti aspetti, il resto dei potenziali problemi è ancora potenziali problemi, ma non dovrebbero non avere implicazioni prestabilili sul server master , se stesso.