Backups MySQL atemporais com orçamento limitado

Meu cenário atual de backup do MySQL é replicar nosso banco de dados para um segundo servidor e executar o mysqldump nesse servidor para remover qualquer tempo de inatividade do bloqueio de tabela ou linha. Isso está funcionando bem, mas custa US $ 150 por mês para o segundo servidor (a hospedagem na Austrália é muito mais cara que nos EUA).

Eu li muitas perguntas aqui sobre isso, a maioria das pessoas precisa de ajuda com os backups agendados e outros enfeites, o que não é o que eu preciso. Eu preciso do mysqldump (de preferência a cada 4 horas) sem tempo de inatividade. O banco de dados é de ~ 7 GB descompactado, portanto o mysqldump pode demorar um pouco, dependendo do servidor.

Eu considerei replicar para a mesma máquina, mas não queria que o escravo consumisse a memória necessária. Não tenho certeza se posso restringir o uso de memória em uma base por db? De qualquer forma, isso colocará carga no servidor enquanto estiver descarregando o banco de dados.

Acabei de ler este http://www.zmanda.com/quick-mysql-backup.html e parece bom, US $ 300 por ano é bom, o que me poupa muito.

Infelizmente, não posso replicar para o RDS da Amazon, mas poderia replicar para uma instância de micro RC2, mas a replicação ocorreria na rede e o ping era de ~ 220ms.

Vi algumas pessoas aqui falando sobre instantâneos do LVM, que podem ser uma boa opção. Eu não sei muita coisa sobre essa opção.

As opiniões seriam muito apreciadas.

Se você usa tabelas innodb, pode usar

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

Isso exigirá um despejo de seu banco de dados que pode ser importado por suas ferramentas também sem bloqueio. Acredito que se você tiver tabelas de myisam, elas bloqueiam.

Se você estiver usando innodb ou outro back-end totalmente transacional, poderá usá-lo mysqldump --single-transaction .... Eu usei isso em bancos de dados bastante grandes (~ 100 GB) com bons resultados; se o banco de dados estiver sob carga pesada, pode levar horas, mas funciona sem bloquear suas tabelas. A replicação geralmente é melhor, mas às vezes você deseja um bom arquivo de despejo sólido. Lembre-se de que você também pode despejar um escravo de replicação mysql.

Na página mysqldump (observe as ressalvas sobre as operações que vazarão na transação):

 ·   --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.

Não vejo muito problema em replicar através de uma conexão de alta latência para um VPS barato nos EUA. A alta latência não deve ser realmente um problema. A replicação foi projetada para ser atualizada rapidamente, mesmo quando um escravo fica horas atrasado, ou seja, pode operar de forma assíncrona.

Contanto que você possa suportar tanta largura de banda de saída no seu plano de hospedagem australiano.

Aqui está uma resposta muito mais detalhada para saber se a alta latência importaria

Realisticamente, apenas o tempo necessário para exportar o banco de dados será de inatividade. Faça isso durante um período de tempo suficientemente lento e não deve haver QUALQUER problema. O que um departamento de TI com esse orçamento realmente espera?

Você deve conseguir realizar o mysqldump de um banco de dados de 7 GB em 5 a 10 minutos no máximo, remover o bloqueio de leitura / gravação e o tempo de inatividade terminará. Você pode encontrar a maneira mais eficiente de largura de banda do arquivo de 7 GB para o novo servidor (leia-se: ALTA COMPRESSÃO). Você tem tempo de sobra para transferir o arquivo e importá-lo para o MySQL no novo servidor. Em seguida, insira as informações do masterlog e inicie a replicação. Deve ser um pedaço de bolo!

A documentação do MySQL é fantástica : http://dev.mysql.com/doc/refman/5.0/en/replication.html

Não tenho certeza de que posso restringir o uso de memória por base de db

Claro que você pode - você só precisa executar o escravo com um /etc/my.cnf diferente

Você pode até fazer coisas para manipular a prioridade de agendamento / afinidade da CPU no mestre e no escravo usando nice / renice e taskset (assumindo que seja um servidor Linux).

mas a replicação ocorreria na rede e o ping é de ~ 220ms

A latência é praticamente irrelevante - o importante é a largura de banda - e a largura de banda do banco de dados (supondo que você não esteja replicando os dados da sessão) tem várias ordens de magnitude inferiores à largura de banda HTTP.

Eu preciso [criar um backup consistente do banco de dados] (de preferência a cada 4 horas) sem tempo de inatividade

Mas as estratégias que você discute não permitem a recuperação em nenhum momento.

Eu acho que a opção mais barata seria um escravo na mesma máquina - e se estiver afetando adversamente o desempenho além do que você pode reconfigurar, atualize o pacote de hospedagem atual.

Você também pode considerar executar um escravo desconectado: habilite os logs de lixeira no servidor atual. Obtenha um backup, restaure o backup em uma máquina local, copie os logs da lixeira à medida que eles são girados e role-os para a frente no DBMS local .

Minha sugestão:

1 - mantenha sua segunda conta / servidor e implemente a replicação em um banco de dados em sua conta / servidor original.

2 - interrompa a replicação para a segunda conta / servidor.

3 - monitore o desempenho por alguns dias. Monitore-o por tempo suficiente para incluir os períodos mais movimentados.

4 - esteja pronto para mudar para a configuração antiga, se houver um grande problema de desempenho. Essa é a razão pela qual você manteve a segunda conta.

5 - compre mais capacidade / servidor de atualização em sua conta original. Isso deve ser mais barato do que pagar por dois servidores, acredito.

6 - cancelar a segunda conta.

Boa sorte!