Backup MySQL senza tempo con un budget limitato

Il mio attuale scenario di backup MySQL è replicare il nostro db su un secondo server ed eseguire mysqldump su quel server per rimuovere eventuali tempi di inattività dal blocco delle tabelle o delle righe. Funziona bene ma costa $ 150 al mese per il secondo server (l'hosting australiano è molto più costoso degli Stati Uniti).

Ho letto molte domande qui su questo, la maggior parte delle persone ha bisogno di aiuto con i backup programmati e quant'altro che non è quello di cui ho bisogno. Ho bisogno di mysqldump (preferibilmente ogni 4 ore) senza tempi di inattività. Il db è ~ 7 GB non compresso, quindi il mysqldump può richiedere del tempo a seconda del server.

Ho considerato di replicare sulla stessa macchina, ma non volevo che lo schiavo mangiasse nella memoria tanto necessaria. Non sono sicuro di poter limitare l'utilizzo della memoria su base per db? Ad ogni modo, questo caricherà il server mentre scarica il db.

Ho appena letto questo http://www.zmanda.com/quick-mysql-backup.html e sembra buono, $ 300 all'anno è ok, il che mi fa risparmiare molto.

Sfortunatamente non posso replicare su RDS di Amazon ma potrei replicare su un'istanza micro RC2 ma la replica avverrebbe su rete e il ping è di ~ 220ms.

Ho visto alcune persone qui che parlavano di istantanee LVM che potrebbero essere una buona opzione. Non so molto su questa opzione.

Le opinioni sarebbero molto apprezzate.

Se usi le tabelle innodb, puoi usare

http://www.percona.com/docs/wiki/percona-xtrabackup:start

Ciò richiederà un dump del database che può essere importato dai loro strumenti anche senza blocco. Credo che se hai tavoli myisam li blocca.

Se si utilizza innodb o un altro backend completamente transazionale, è possibile utilizzare mysqldump --single-transaction .... L'ho usato su database abbastanza grandi (~ 100 GB) con buoni risultati; se il database è sotto carico, possono essere necessarie ore ma funziona senza bloccare le tabelle. La replica è generalmente migliore ma a volte vuoi un bel file di dump solido. Tieni presente che puoi anche scaricare uno slave di replica mysql.

Dalla pagina mysqldump (notare le avvertenze sulle operazioni che andranno a finire nella transazione):

 ·   --single-transaction

   This option sends a START TRANSACTION SQL statement to the server
   before dumping data. It is useful only with transactional tables
   such as InnoDB, because then it dumps the consistent state of the
   database at the time when BEGIN was issued without blocking any
   applications.

   When using this option, you should keep in mind that only InnoDB
   tables are dumped in a consistent state. For example, any MyISAM or
   MEMORY tables dumped while using this option may still change
   state.

   While a --single-transaction dump is in process, to ensure a valid
   dump file (correct table contents and binary log coordinates), no
   other connection should use the following statements: ALTER TABLE,
   CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE. A
   consistent read is not isolated from those statements, so use of
   them on a table to be dumped can cause the SELECT that is performed
   by mysqldump to retrieve the table contents to obtain incorrect
   contents or fail.

Non vedo gran parte dei problemi che si replicano su una connessione ad alta latenza a un VPS economico negli Stati Uniti. L'elevata latenza non dovrebbe essere un problema. La replica è progettata per essere in grado di recuperare rapidamente anche quando uno slave è in ritardo di ore , ovvero può funzionare in modo asincrono.

Finché puoi sopportare quella larghezza di banda in uscita sul tuo piano di hosting australiano.

Ecco una risposta molto più dettagliata se l'importante latenza sarebbe importante

Realisticamente, solo il tempo necessario per esportare effettivamente il database sarà inattività. Fallo durante un periodo di tempo abbastanza lento e non dovrebbe esserci NESSUN problema. Cosa si aspetta davvero un dipartimento IT con quel budget?

Dovresti essere in grado di mysqldump un database da 7 GB in 5-10 minuti MAX, togliere il blocco di lettura / scrittura e il tempo di inattività sarà finito. È quindi possibile trovare il modo più efficace per la larghezza di banda del file da 7 GB sul nuovo server (leggi: ALTA COMPRESSIONE). Hai un sacco di tempo per trasferire e importare il file in MySQL sul nuovo server. Quindi, immettere le informazioni del masterlog e avviare la replica. Dovrebbe essere un gioco da ragazzi!

La documentazione di MySQL è fantastica : http://dev.mysql.com/doc/refman/5.0/en/replication.html

Non sono sicuro di poter limitare l'utilizzo della memoria su base db

Certo che puoi - devi solo far funzionare lo slave con un /etc/my.cnf diverso

Puoi persino fare cose per manipolare la priorità di pianificazione / affinità della CPU sul master e sullo slave usando nice / renice e tasket (supponendo che sia un server Linux).

ma la replica avverrebbe su rete e il ping è di ~ 220ms

La latenza è praticamente irrilevante - l'importante è la larghezza di banda - e la larghezza di banda del database (supponendo che non si stiano replicando i dati di sessione) è di molti ordini di grandezza inferiore alla larghezza di banda HTTP.

Devo [creare un backup coerente del database] (preferibilmente ogni 4 ore) senza tempi di inattività

Ma le strategie che discuti non consentono il recupero in un momento come quello.

Penso che l'opzione più economica sarebbe uno slave sulla stessa macchina - e se influisce negativamente sulle prestazioni oltre ciò che è possibile riconfigurare, aggiornare il pacchetto di hosting corrente.

Si potrebbe anche considerare l'esecuzione di uno slave disconnesso: abilitare i registri bin sul server corrente. Ottieni un backup, ripristina il backup su un computer locale, quindi copia i registri bin mentre vengono ruotati e spostali in avanti sul DBMS locale .

Il mio consiglio:

1 - conserva il tuo secondo account / server e implementa la replica in un database nel tuo account / server originale.

2 - interrompe la replica sul secondo account / server.

3 - monitorare le prestazioni per alcuni giorni. Assicurati di monitorarlo abbastanza a lungo da includere i periodi più occupati.

4 - essere pronti a passare alla vecchia configurazione in caso di problemi di prestazioni importanti. Questo è il motivo per cui hai tenuto il secondo account.

5 - acquista più capacità / aggiorna il server nel tuo account originale. Credo che questo dovrebbe essere più economico del pagamento per due server.

6 - cancella il secondo account.

In bocca al lupo!