Modi per ridimensionare automaticamente i server MySQL?

Gestisco un sito che presenta forti picchi di traffico e per questo le soluzioni di ridimensionamento automatico sono molto redditizie in questo caso. Attualmente il web server è in grado di ridimensionarsi automaticamente in orizzontale ma il collo di bottiglia si trova sul server MySQL.

• Ho provato con Amazon RDS Multi-AZ ma ci vogliono circa 15 minuti per l'aggiornamento del database da 12 GB con alcuni minuti di inattività. Mi ha aiutato molto quando sapevo già che un certo aumento del traffico si sarebbe verificato in un momento specifico.
• Ho anche considerato Xeround. Questa è probabilmente la soluzione migliore anche se è piuttosto costosa per database di queste dimensioni. Comunque non è un'opzione perché legalmente ho bisogno che il database sia nell'Unione Europea.
• Ho letto di Scalr ma non sono sicuro che ciò possa essere utile e come.
• Ho visto che molti provider di cloud hosting offrono soluzioni di ridimensionamento verticale che penso abbia 0 tempi di inattività (non sono sicuro che sia davvero possibile, per quanto ne sappia che usano l'hypervisor Xen). Potrebbe essere una soluzione, ma mi chiedo se non abbia tempi di inattività e come la configurazione di MySQL (e molte altre cose sul sistema operativo) siano in grado di aggiornare anche senza tempi di inattività.
• Ho provato con i server slave MySQL ma non è stato affatto utile.
• Sto usando memcache che aiuta molto ma non è abbastanza. Ho bisogno di aggiornare a causa delle scritture, non solo a causa delle letture.

Eventuali suggerimenti? Grazie in anticipo

In realtà, una soluzione più semplice sarebbe provare ad aggiungere Memcached allo stack per risparmiare sul caricamento del DB. Ciò può ridurre drasticamente il carico ed è molto più semplice che cercare di risolvere il problema di alzare rapidamente i server (bassa difficoltà) e quindi immaginare una rapida sincronizzazione di MySQL (difficoltà molto più elevata).

http://toblender.com/?s=memcached

Per risolvere il problema di troppe scritture, la correzione più comune è l'aggiunta di memoria al server (un set di lavoro più grande può essere conservato nella RAM), mettendo il tuo DB su dischi più veloci (gli SSD sono una buona soluzione, ma costosa), o lo sharding (che è costoso in server aggiuntivi e complessità).

Un altro modo per ridurre il carico di scrittura del DB sarebbe incorporare un archivio di dati in memoria (come Redis) per gestire i dati che cambiano frequentemente e, se necessario, riscrivere periodicamente le modifiche nel DB principale.

Dovresti considerare di usare a topologia a stella

Ecco cosa sto proponendo

• One Write Master (alias WM)
• Un master di distribuzione (alias DM)
• Cinque (5) Leggi Slave Server (aka RSS)

Preparare la topologia in questo modo

Passaggio 01: imposta 5 RSS con queste opzioni comuni

[mysqld]
skip-innodb
key_buffer_size=1G

Ciò causerà la creazione di tutte le tabelle caricate come MyISAM Storage Engine

Passaggio 02: configurazione DM e tutti i server RS

• mysqldump lo schema di tutte le tabelle da WM a un file schemadump
• carica il file schemadump in DM e tutti i 5 RSS
• eseguire ALTER TABLE tblname ROW_FORMAT=Fixed;su tutte le tabelle in RSS
• eseguire ALTER TABLE tblname ENGINE=BLACKHOLE;su tutte le tabelle in DM
• solo dati mysqldump (usando --no-create-info) in un datadump
• carica datadump in tutti e 5 gli RSS

Step 03: Setup Replication Da DM a tutti e 5 gli RSS

Passaggio 04: installazione replica da WM a DM

FINE DELLA CONFIGURAZIONE

Ecco come funziona il tuo meccanismo di lettura / scrittura

• Tutte le tue scritture (INSERISCE, AGGIORNAMENTI, CANCELLA) avvengono in WM
• SQL viene registrato nei registri binari del DM (Nessun dato reale risiede nel DM)
• Ogni RSS è uno slave di lettura del DM
• Tutte le tue letture avvengono su RSS

Ora ecco il trucco ...

• Inizialmente si utilizza RSS 1-4 per le letture
• Usa il 5 ° RSS per far girare altri RSS
  • Tu corri service mysql stopal 5 ° RSS
  • Spin Up un altro RSS
  • Copia / var / lib / mysql e /etc/my.cnf del 5 ° RSS nel RSS appena lanciato
  • Corri service mysql stopal 5 ° RSS
  • Corri service mysql stopal nuovo RSS

È possibile utilizzare RSS # 5 per far girare nuovi server più e più volte

Su un sidenote, non utilizzare XEROUND per WM o DM perché non supportano il motore di archiviazione InnoDB o BLACKHOLE.

Spero che queste idee siano d'aiuto.

Se usi Innodb, dovresti considerare i multi-master Mysql gestiti da Galera . Semplifica la configurazione di mysql multi-master e dovrebbe facilitarti il ​​"semi" ridimensionamento automatico.

Se si tratta di un'applicazione che tu o la tua azienda state scrivendo, potete prendere in considerazione l'idea di passare a un progetto (partizionato) per l'applicazione. Ma lo sharding può diventare complicato. Ecco un link per iniziare.

Suppongo che tu abbia "ottimizzato" i file di configurazione mysql, come nella memoria appropriata allocata, ecc.

È in un rack che controlli o è nel cloud? 12 GB è molto database piccolo in relazione alla dimensione dei dischi disponibili. Inseriscilo su un array RAID1 o RAID10 di piccoli SSD SLC e la tua latenza di scrittura scomparirà.

L' SSD SLC da 20 GB della serie Intel 311 ($ 120 ciascuno) farebbe il lavoro in modo brillante.

Se il database fosse più grande, è possibile ottenere risultati altrettanto spettacolari spostando il database su una destinazione iSCSI su un server ZFS SAN (basato sull'hardware del server delle materie prime utilizzando Nexenta, OpenIndiana, FreeNAS o altro) e impostando un mirror di SSD simili per la tua cache di scrittura ZIL. In tutte le circostanze tranne quelle straordinarie, Gigabit Ethernet è più che adeguata per spostare il traffico iSCSI del database.