Come scaricare in modo efficiente un enorme database innodb di MySQL?

Ho un server di database MySQL di produzione Ubuntu 10.04 in cui la dimensione totale del database è 260 GB mentre la dimensione della partizione root è di per sé 300 GB in cui è archiviato il DB, essenzialmente significa che circa il 96% di / è pieno e non c'è spazio per l'archiviazione di dump / backup ecc. Nessun altro disco è collegato al server al momento.

Il mio compito è migrare questo database su un altro server che si trova in un datacenter diverso. La domanda è come farlo in modo efficiente con tempi di inattività minimi?

Sto pensando in linea di:

• Richiesta di collegare un'unità aggiuntiva al server e eseguire il dump in tale unità. [EDIT: non è possibile ora.]
• Trasferisci il dump su un nuovo server, ripristinalo e rendi il nuovo server schiavo di quello esistente per mantenere sincronizzati i dati
• Quando è necessaria la migrazione, interrompere la replica, aggiornare la configurazione dello slave per accettare le richieste di lettura / scrittura e rendere il vecchio server di sola lettura in modo che non accolga alcuna richiesta di scrittura e dire agli sviluppatori di app di aggiornare lì la configurazione con il nuovo indirizzo IP per db.

Quali sono i tuoi suggerimenti per migliorare questo o un approccio alternativo alternativo per questo compito?

Se state pensando di migrare ad un altro DB server con la stessa versione di MySQL, si consiglia rsyncdella datadirdal vecchio server al nuovo server.

Funzionerà indipendentemente dal layout del file InnoDB o anche dalla presenza di tabelle MyISAM.

1. installa la stessa versione di mysql su ServerB di ServerA
2. Su ServerA, eseguire RESET MASTER;per cancellare tutti i registri binari prima del processo rsycn. Se la registrazione binaria non è abilitata, è possibile saltare questo passaggio.
3. Su ServerA, esegui SET GLOBAL innodb_max_dirty_pages_pct = 0;da mysql e circa 10 minuti (Questo elimina le pagine sporche dal pool di buffer InnoDB. Aiuta anche a eseguire un arresto di mysql più velocemente) Se il tuo database è tutto MyISAM, puoi saltare questo passaggio.
4. rsync / var / lib / mysql di ServerA su / var / lib / mysql su ServerB
5. Ripetere il passaggio 3 fino a quando un rsync impiega meno di 1 minuto
6. service mysql stop su ServerA
7. Eseguire un altro rsync
8. scp ServerA: /etc/my.cnf su ServerB: / etc /.
9. service mysql start su ServerB
10. service mysql start su ServerA (opzionale)

In sostanza, ecco cosa vorrebbe questo script

mysql -u... -p... -e"RESET MASTER;"
mysql -u... -p... -e"SET GLOBAL innodb_max_dirty_pages_pct = 0;"
RSYNCSTOTRY=10
cd /var/lib/mysql
X=0
while [ ${X} -lt ${RSYNCSTOTRY} ]
do
    X=`echo ${X}+1|bc`
    rsync -r * targetserver:/var/lib/mysql/.
    sleep 60
done
service mysql stop
rsync -r * targetserver:/var/lib/mysql/.
service mysql start

Un membro del DBA StackExchange ha detto che dovrei stare lontano da FLUSH TABLES WITH READ LOCK;basato su qualcosa in mysqlperformanceblog.com

Ho letto e appreso che SELECTs contro le tabelle InnoDB nel mezzo di un FLUSH TABLES WITH READ LOCK;può ancora consentire che le scritture avvengano in qualche modo. Come sottolineato nel commento di Arlukin , LVM avrebbe lavorato bene FLUSH TABLES WITH READ LOCKsu InnoDB (+1 per il suo commento).

• http://www.mysqlperformanceblog.com/2012/03/23/how-flush-tables-with-read-lock-works-with-innodb-tables/
• http://forums.mysql.com/read.php?22,184590,184610

Per tutti gli utenti non LVM, si è d'accordo con un database all-MyISAM da utilizzare con FLUSH TABLES WITH READ LOCK;. Per InnoDB, attenersi --single-tranactionall'utilizzo in mysqldumps per favore.

Un dump e un ripristino di un database di quelle dimensioni richiederebbero ore. Vorrei, a seconda delle versioni di mysql purché il numero di versione aumenti e non ci siano salti nel numero di revisione principale. Dovresti essere in grado di prendere i file di database non elaborati in / var / lib / mysql e metterli sul nuovo server, impostare le autorizzazioni e accendere il server con l'opzione --skip-grant-tables. Aggiungi le sovvenzioni necessarie per gli utenti che riflettono il nuovo indirizzo IP, quindi riavvia normalmente.

Vorrei affrontare le dimensioni del database in quanto è troppo grande per essere efficiente.

Puoi seguire questi passaggi per migrare questo enorme database InnoDB.

• Installare SSHFS e montare la relativa partizione del server remoto sul server di produzione
• Utilizzare Percona XtraBackup per ottenere una hotcopy del database InnoDB e salvarlo direttamente nella directory montata SSHFS

• Questa operazione richiederà diverse ore. Per ridurre al minimo l'effetto dello script hotcopy sul server live, impostare la priorità bassa su di esso usando renice

  $ renice -n 5 -p <SCRIPT-PID>

• Assicurarsi che entrambi i server eseguano la stessa versione del server MySQL.
• Una volta completata la hotcopy, è possibile ripristinarla nel nuovo server e avviare il processo di replica

Potresti riscontrare lentezza durante questo processo ma sicuramente nessun tempo di inattività. Percona XtraBackup creerà un hotcopy che è più veloce e consuma meno risorse rispetto a mysqldump. Questo è l'ideale per un enorme database InnoDB.

A seconda dei modelli di utilizzo e delle statistiche, è possibile eseguire questo processo in presenza di traffico minimo sul server. Forse farlo nel fine settimana è una buona idea? Quanto sopra è solo uno schema del processo. Potrebbe essere necessario consultare la documentazione di Percona XtraBackup e SSHFS.

Potresti semplicemente scaricare il database direttamente sul server remoto ...

$ mysqldump | ssh user@server 'cat - > dumpfile.sql.gz'

... SQL dovrebbe comprimersi bene, quindi dovresti farlo molto più velocemente con una di queste opzioni anche se dipenderà anche dalla quantità di RAM che hai nella scatola ...

$ mysqldump | ssh -C user@server 'cat - > dumpfile.sql.gz'
$ mysqldump | gzip -c | ssh user@server 'cat - > dumpfile.sql.gz'