Cosa possiamo fare nella replica di MySQL 5.0 per risolvere i problemi di larghezza di banda?

Sto sviluppando un'applicazione da eseguire sul PC client (Win) configurato con un'istanza del server MySQL 5.1 che fungerà da slave di sola lettura per il master remoto. Il master remoto ha dozzine di schemi, ma ne ho bisogno solo uno per client, quindi fornisco l' impostazione replication-do-db in my.ini per replicare solo lo schema di cui il client ha bisogno. La replica funziona, ma quando i nostri clienti entrano in regioni del mondo in cui l'accesso a Internet è disponibile solo tramite wireless 3G, che si carica in base all'utilizzo dei dati, superano rapidamente i limiti del loro piano dati e incontrano costosi problemi.

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

Per ridurre al minimo questa inefficienza, ho utilizzato l' impostazione slave_compressed_protocol = 1 , che sembra ridurre i dati trasmessi del 50%, ma fa sì che i nostri clienti superino rapidamente il limite di dati accumulando la bolletta 3G.

Non riesco a immaginare di essere l'unico ad affrontare questo, quindi sono sicuro che otterrò un sacco di risposte su come raggiungere questo obiettivo impostando x = y. Tuttavia, non riesco a trovare alcuna documentazione di tale impostazione, né un approccio raccomandato da adottare.

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

Configurare uno slave "proxy" per ogni schema (su una casella diversa o sulla stessa casella con un'istanza / porta MySQL diversa)
Configurare lo slave proxy per replicare-do-db solo l'unico database che i client desiderano replicare.
Configurare l'istanza MySQL del client come slave sullo slave proxy appropriato.

Ciò dovrebbe comportare il client che estrae solo i dati binlog per il loro schema. Il rovescio della medaglia (per quanto ne so) è che aumenta notevolmente la complessità del nostro setup, probabilmente rendendolo più fragile.

Pensieri? Questo approccio funzionerà anche?

Nota, stiamo eseguendo il server MySQL 5.0 su RedHat, ma potremmo aggiornare a 5.5 se produce una soluzione.

— Abram
fonte

I commenti non sono per una discussione estesa; questa conversazione è stata spostata in chat .

— Paul White Ripristina Monica

SUGGERIMENTO N. 1: utilizzare i master di distribuzione

Un master di distribuzione è uno slave mysql con log-bin abilitato, aggiornamenti log-slave abilitati e contiene solo tabelle con BLACKHOLE Storage Engine . È possibile applicare replicate-do-db al master di distribuzione e creare registri binari nel master di distribuzione che contenga solo gli schemi DB da binare. In questo modo riduci la dimensione dei binlog in uscita dal Master di distribuzione.

È possibile impostare un Master di distribuzione come segue:

mysqldump i tuoi database usando l'opzione --no-data per generare un dump solo dello schema.
Caricare il dump solo dello schema sul Master di distribuzione.
Converti ogni tabella nel Master di distribuzione nel motore di archiviazione BLACKHOLE.
Configura la replica sul Master di distribuzione da un master con dati reali.
Aggiungi l'opzione replicate-do-db a /etc/my.cnf del Master di distribuzione.

Per i passaggi 2 e 3 è inoltre possibile modificare il dump solo dello schema e sostituire ENGINE = MyISAM e ENGINE = InnoDB con ENGINE = BLACKHOLE e quindi caricare tale dump solo dello schema modificato nel Master di distribuzione.

Solo nel passaggio 3, se si desidera eseguire lo script della conversione di tutte le tabelle MyISAM e InnoDB in BLACKHOLE nel Master di distribuzione, eseguire la query seguente e inviarla a 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 vantaggio dello scripting della conversione della tabella nel motore di archiviazione BLACKHOLE è la conversione anche delle tabelle del motore di archiviazione MEMORY . Mentre la tabella del motore di archiviazione MEMORY non occupa spazio su disco per l'archiviazione dei dati, occuperà memoria. La conversione delle tabelle MEMORY in BLACKHOLE manterrà la memoria nel distributore principale ordinato.

Finché non si invia alcun DDL nel Master di distribuzione, è possibile trasmettere qualsiasi DML (INSERT, UPDATE, DELETE) desiderato prima di consentire ai client di replicare solo le informazioni DB che desiderano.

Ho già scritto un post in un altro sito StackExchange che discute sull'uso di un Master di distribuzione .

SUGGERIMENTO N. 2: utilizzare registri binari più piccoli e registri di inoltro

Se imposti max_binlog_size su qualcosa di ridicolmente piccolo, i binlog possono essere raccolti e spediti in blocchi più piccoli. C'è anche un'opzione separata per impostare la dimensione dei log di inoltro, max_relay_log_size . Se max_relay_log_size = 0, verrà impostato automaticamente su qualunque valore max_binlog_size è impostato.

SUGGERIMENTO # 3: utilizzare la replica semisincrona (solo MySQL 5.5)

Configura il tuo database principale e più Master di distribuzione come MySQL 5.5. Abilitare la replica semisincrona in modo che il database principale possa spedire rapidamente i binlog al distributore principale. Se TUTTI i tuoi schiavi sono Master di distribuzione, potresti non aver bisogno di Semisynchronous Replication o MySQL 5.5. Se uno qualsiasi degli slave, oltre ai Master di distribuzione, dispone di dati reali per la creazione di report, alta disponibilità, standby passivo o backup, utilizzare MySQL 5.5 in combinazione con la replica semisincrona.

SUGGERIMENTO N. 4: utilizzare la registrazione binaria basata su istruzioni NON basata su riga

Se un'istruzione SQL aggiorna più righe in una tabella, la registrazione binaria basata su istruzioni (SBBL) memorizza solo l'istruzione SQL. La stessa istruzione SQL che utilizza la registrazione binaria basata su riga (RBBL) registrerà effettivamente la modifica della riga per ogni riga. Ciò rende ovvio che la trasmissione di istruzioni SQL farà risparmiare spazio sui registri binari facendo SBBL su RBBL.

Un altro problema è l'utilizzo di RBBL insieme a replicate-do-db in cui il nome della tabella ha anteposto il database . Questo non può essere buono per uno schiavo, specialmente per un Maestro di distribuzione. Pertanto, assicurarsi che tutto il DML non abbia un database e un punto davanti ai nomi delle tabelle.

— RolandoMySQLDBA
fonte

Idee interessanti @RolandoMySQLDBA, Suggerimento 1 suona come quello che stavo cercando di descrivere con la mia configurazione slave "proxy". Tuttavia, DDL è qualcosa che dovrò riferire agli schiavi. Suppongo di poterlo gestire a livello di app, ma preferirei non evitarlo. Posso vedere come il suggerimento 2 sarebbe di aiuto se il traffico / velocità fosse un problema, ma non sono sicuro di come avrebbe aiutato l'utilizzo della larghezza di banda della rete. Per il suggerimento 3, potresti approfondire un po 'per me? Ho pensato che il semisincrono sarebbe più per una replica "sicura" per quando è necessario sapere che almeno 1 slave ha ricevuto l'aggiornamento. Ottimi suggerimenti A proposito!

— Abram,

@Abram Assicurati che i master di distribuzione non ricevano mai tabelle InnoDB o MyISAM per limitare l'I / O del disco alla gestione dei binlog !!!

— RolandoMySQLDBA

Attualmente sto configurando un ambiente di test in cui avrò diverse istanze di MySQL 5.5 in esecuzione sullo stesso box (porta diff) dei master di distribuzione. Ogni DM avrà una versione blackhole del rispettivo DB dal master. Quindi imposterò alcuni slave remoti che appenderò al DM. Tornerò con i miei risultati. Sembra l'opzione migliore, anche se per qualche motivo ho l'ansia di eseguire più istanze di MySQL. Forse un lavoro per un server micro cloud da Amazon.

— Abram,

@Abram dovresti aggiungere skip-innodb a /etc/my.cnf. Non è possibile disabilitare MyISAM poiché è un motore di archiviazione di riserva. Dovrai eseguire manualmente ALTER TABLE tblname ENGINE = BLACKHOLE se qualsiasi tabella su un master di distribuzione finisce per essere MyISAM. Forse creare uno script da questa query: SELECT CONCAT ('ALTER TABLE', table_schema, '.', Table_name, 'ENGINE = BLACKHOLE;') AlterCommand FROM information_schema.tables WHERE engine = 'MyISAM' e table_schema NOT IN ('information_schema' , 'mysql'); Se ne trovi, convertili dall'output di questa query.

— RolandoMySQLDBA

Per quanto riguarda il suggerimento n. 3, la replica semi-sincronizzata ha il riconoscimento di ricezione del master da parte dello slave che la voce di registro ha fatto allo slave. In mysql 5.0, il master attende che lo slave esegua l'elaborazione dell'SQL prima di inviare la stessa istruzione allo slave successivo. Pertanto, la semi-sincronizzazione è più veloce.

— RolandoMySQLDBA

Max_binlog_size dovrebbe essere irrilevante: i dati binlog vengono trasmessi in streaming continuamente.

Attenzione a un "Master di distribuzione" - è un "singolo punto di errore". Cioè, se muore, tutti gli slave al di là di esso non riceveranno dati e la ricostruzione del relè richiederà lavoro.

SBR vs RBR - dipende dalla query. O può essere migliore o peggiore dell'altro.

Metti i Master di distribuzione sulla stessa macchina del vero Maestro o su una macchina "vicino" al Maestro. Utilizzare porte separate per mantenere separate le istanze.

— Rick James
fonte