Quanto è veloce la replica di MySQL?

Sto pensando di impostare la replica del nostro db mysql per poter avere slave locali in ciascuna delle nostre filiali, mentre ho il master nell'ufficio principale per migliorare (significativamente) le prestazioni delle applicazioni nelle nostre filiali.

Il db stesso non è così grande (<1 gb) ma mi chiedo; considerando 200-300 aggiornamenti di record / top min: quanto è veloce la replica? (supponendo, in primo luogo, una connessione dsl generica da 5 MB, più veloce se necessario - cercando di mantenere i costi il ​​più bassi possibile ma i soldi sono lì per altro)

Le intere tabelle vengono replicate in batch? La replica viene eseguita, su richiesta, man mano che ogni record in una tabella viene aggiornato (dai documenti, penso di vedere che è configurabile)?

Appunti:

• Sto pensando a 1 master, 2 slave (2 succursali per ora) come nei documenti qui tranne per il fatto che si tratta di un'app, non di un client Web
• Qualsiasi aggiornamento eseguito sul master deve replicarsi sugli altri slave in <10 minuti.
• Tutto questo presuppone che posso rendere felice il nostro ORM (DevExpress XPO) con il concetto di leggere dallo schiavo e scrivere al master.

La replica di MySQL avviene il più vicino possibile al tempo reale, come limitato dall'I / O del disco e della rete. Gli schiavi aprono un socket al master, che viene tenuto aperto. Quando si verifica una transazione sul master, questa viene registrata nel binlog e viene semplicemente riprodotta sugli slave. Se il socket tra master e slave viene interrotto, il binlog viene riprodotto per lo slave alla successiva connessione riuscita.

La replica multi-master fa la stessa cosa, ma in entrambe le direzioni.

Alcuni calcoli di base ti aiuteranno a determinare meglio le tue esigenze di larghezza di banda.

Average transaction size * number of slaves * updates/minute = bandwidth needed

Spero che sia di aiuto.

La replica sul lato slave è gestita da due thread indipendenti.

• Il processo di lettura del registro, che si collega al master, riceve ogni istruzione di modifica dei dati, la scrive nel registro di inoltro.
• Il processo del writer sql, che prende nuovi elementi dal registro di inoltro, esegue il commit delle istruzioni nel database degli slave, quindi sposta il puntatore dello slave oltre tale istruzione per indicare la ricezione della query.

La latenza della replica è limitata da IO, in primo luogo l'IO sul database degli slave per applicare le transazioni dal registro di inoltro (che può comportare query SQL complesse) e in secondo luogo dall'IO sul master per leggere il suo binlog e trasmetterlo a ciascuno slave.

La replica di MySQL aumenta la capacità di query di lettura ma non aumenta le prestazioni di scrittura della query, che è controllata alla velocità di I / O che può essere scaricata nel binlog sia sul master che sullo slave

La replica in MySQL è abbastanza rapida per ottenere i dati sullo slave (più velocemente di quanto sarai in grado di eseguire UPDATEil master e passare a un'altra finestra per eseguire un SELECTslave, se(e solo se) le connessioni di rete sono tutte attive e tutto funziona correttamente. Qualsiasi connessione di classe DSL dovrebbe andare bene per il caso generale delle piccole query regolari, ma le query di inserimento / aggiornamento di grandi dimensioni possono richiedere un po 'di tempo per la copia e la risincronizzazione in caso di un errore di replica (e MySQL è incline a quelli, sfortunatamente) impiegheranno un po 'di tempo (copiando di nuovo l'intero database dal master). Ci sono dei trucchi per limitare l'impatto della risincronizzazione sul tuo master, come mettere MySQL su LVM in modo da poter fare un blocco / istantanea molto veloce e risincronizzare i contenuti dell'istantanea con lo slave, ma alla fine una risincronizzazione farà schifo.