Che cosa possiamo fare in MySQL 5.0 replica alle preoccupazioni di larghezza di banda indirizzo?

Question

sto sviluppando un'applicazione da eseguire sul PC client (Windows) che è configurato con un server MySQL 5.1 esempio che agirà come slave di sola lettura al master a distanza. Il master a distanza ha decine di schemi, ma ho solo bisogno di uno per ogni cliente in modo fornisco il replica-do-db impostazione my.ini per replicare solo lo schema che le esigenze del cliente. Le opere di replica, ma quando i nostri clienti ottengono in regioni del mondo dove è disponibile solo tramite 3G wireless, che carica per l'uso di dati di accesso a Internet, superano rapidamente i loro limiti di piano dati e incorrere in problemi costosi.

A quanto ho capito, MySQL scrive tutte le transazioni per tutti gli schemi in un singolo file binlog che significa che ogni cliente deve scaricare tutte le transazioni che vengono eseguite su ogni schema sul master, poi una volta scaricato, applicare il filtro di database per replica-do-db impostazioni nel file my.ini del cliente.

Per ridurre al minimo questa inefficienza ho impiegato il slave_compressed_protocol = 1 impostazione, che sembra ridurre i dati trasmessi dal 50%, ma ancora fa sì che il nostro cliente rapidamente superare il loro limite di dati accumulare il disegno di legge 3G .

Non riesco a immaginare io sono l'unico di fronte a questo, quindi sono sicuro che avrò un sacco di risposte su come raggiungere questo obiettivo impostazione x = y. Tuttavia, non riesco a trovare alcuna documentazione di tale impostazione una, né un approccio consigliato di prendere.

Finora, ecco il mio pensiero ad una possibile soluzione, si prega di fornire un feedback o percorsi alternativi:

---

1. Imposta uno slave "proxy" per ogni schema (sulla scatola differente, o stessa scatola con una diversa istanza MySQL / porta)
2. Configura lo schiavo proxy per replicare-do-db solo quella base di dati che i clienti desiderano riprodurre.
3. istanza di MySQL Configurazione del client come schiavi schiavo delega appropriata.

Questo dovrebbe risultato nel client solo tirando i dati binlog per il loro schema. Il rovescio della medaglia (per quanto posso dire) è che aumenta notevolmente la complessità della nostra messa a punto, probabilmente rendendolo più fragile.

Pensieri? Sarà questo approccio lavoro anche?

Nota, ci sono in esecuzione il server MySQL 5.0 su RedHat, ma abbiamo potuto effettuare l'aggiornamento a 5.5 se produce una soluzione.

Answer 1

SUGGERIMENTO # 1: Usa Masters di distribuzione

Un Maestro di distribuzione è uno schiavo mysql con log-bin abilitato, log-schiavi aggiornamenti abilitati e contiene solo le tabelle con il BLACKHOLE Storage Engine . È possibile applicare replicate-do-db al Maestro Distribuzione e creare registri binari al Master di distribuzione che contiene solo lo schema DB (s) che si desidera binlogged. In questo modo si riducono le dimensioni dei binlogs in uscita dal Master Distribution.

È possibile impostare un master di distribuzione nel seguente modo:

1. mysqldump database (s) utilizzando l'opzione --no-dati per generare un dump dello schema solo.
2. Caricare il dump dello schema solo al Master di distribuzione.
3. Converti ogni tavolo al Master Distribution per il motore di archiviazione BLACKHOLE.
4. replica Setup al Master Distribution da un maestro con i dati reali.
5. Aggiungi opzione Replica-do-db (s) per /etc/my.cnf del Master Distribution.

Per i passaggi 2 e 3 si potrebbe anche modificare lo schema di sola discarica e sostituire ENGINE = MyISAM e ENGINE = InnoDB con ENGINE = BLACKHOLE e quindi caricare che modificato lo schema di sola discarica nel Master Distribution.

Al punto 3 solo, se si desidera lo script la conversione di tutte le tabelle MyISAM e InnoDB per BLACKHOLE al Master di distribuzione, eseguire la seguente query e l'output in un file di testo:

mysql -h... -u... -p... -A --skip-column-names -e"SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name', ENGINE=BLACKHOLE;') BlackholeConversion FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql') AND engine <> 'BLACKHOLE'" > BlackholeMaker.sql

Un ulteriore bonus per script la conversione di tabella per il motore di archiviazione BLACKHOLE è che tavoli motore memorizzazione MEMORY sono convertiti pure. Mentre tavolo storage engine MEMORY non occupano spazio su disco per l'archiviazione dei dati, ci vorranno memoria. Conversione tabelle di memoria per BLACKHOLE manterrà la memoria nel Master Distribution ordinato.

Finché non inviare alcun DDL nel Master distribuzione, è possibile trasmettere qualsiasi DML (INSERT, UPDATE, DELETE) così volete prima che i client lasciando replicano solo le informazioni DB che vogliono.

ho già scritto un post in un altro sito StackExchange che discute con un Master Distribution .

SUGGERIMENTO # 2: Utilizzare Più piccolo log binari e registri Relay

Se si imposta max_binlog_size a qualcosa di ridicolmente piccolo, allora binlogs possono essere raccolti e spediti in blocchi più piccoli. C'è anche un'opzione separata per impostare le dimensioni dei tronchi relè, max_relay_log_size . Se max_relay_log_size = 0, questo verrà impostato a tutto ciò max_binlog_size è impostato.

SUGGERIMENTO # 3: Usa Semisynchronous replica (MySQL 5.5 solo)

Imposta il tuo principali maestri del database e distribuzione multipla come MySQL 5.5. Abilita Semisynchronous replica in modo che il database principale può spedire rapidamente binlogs al Master Distribution. Se tutti i servi sono maestri di distribuzione, potrebbe non essere necessario Semisynchronous di replica o di MySQL 5.5. Se uno qualsiasi degli schiavi, diversi maestri di distribuzione, sono dati reali per il reporting, l'alta disponibilità, standby passivo o scopi di backup, poi andare con MySQL 5.5 in combinazione con Semisynchronous di replica.

SUGGERIMENTO # 4: Registrazione Usa Statement-Based Binary NON Row-Based

Se un'istruzione SQL aggiorna più righe in una tabella, Statement-Based registrazione binaria (SBBL) memorizza solo l'SQLdichiarazione. La stessa istruzione SQL utilizzando registrazione basata su file binario (RBBL) registrerà effettivo il cambio di riga per ogni riga. Questo rende evidente che la trasmissione di istruzioni SQL farà risparmiare spazio sul log binari facendo SBBL sopra RBBL.

Un altro problema sta usando RBBL in collaborazione con replicate-do-db in cui il nome della tabella ha il database anteposto . Questo non può essere buono per uno slave, soprattutto per un Master Distribution. Pertanto, assicurarsi che tutti DML non hai un database e un periodo di fronte a eventuali nomi di tabella.

Answer 2

Il max_binlog_size dovrebbe essere irrilevante -. Dati binlog viene trasmesso fuori continuamente

Attenzione di un "Master Distribution" - si tratta di un "single point of failure". Cioè, se muore, tutto lo slave (s) oltre esso non riceverà dati, e ricostruire il relè avrà lavoro.

SBR vs RBR - dipende dalla query. O può essere migliore o peggiore rispetto agli altri.

Mettere i Maestri di distribuzione sulla stessa macchina come il vero Maestro, o su una macchina "vicino" il Maestro. Utilizzare porte separate per mantenere le istanze separate.