Backups sem tempo do MySQL em um orçamento

Question

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 do que nos EUA).

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

Eu considerei replicar para a mesma máquina, mas eu não queria que o escravo come a memória necessária. Não tenho certeza se posso restringir o uso de memória por DB. De qualquer forma, isso colocará carga no servidor enquanto despeja o db.

Acabei de ler este link e parece bom, $ 300 por ano é ok, isso me salva muito.

Infelizmente eu não posso replicar para o RDS da Amazon, mas eu poderia replicar para uma instância micro RC2, mas a replicação seria over-net e o ping é ~ 220ms.

Eu vi algumas pessoas aqui falando sobre instantâneos do LVM que podem ser uma boa opção. Eu não sei muito sobre esta opção tho.

Opiniões seriam muito apreciadas.

    

Answer 1

Se você usar tabelas innodb, você pode usar

link

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

    

Answer 2

Se você estiver usando innodb ou outro backend que seja totalmente transacional, use mysqldump --single-transaction ... . Eu usei isso em bancos de dados razoavelmente grandes (~ 100GB) com bons resultados; se o banco de dados estiver sob carga pesada, ele pode levar horas , mas funciona sem bloquear suas tabelas. A replicação geralmente é melhor, mas às vezes você quer um arquivo de despejo sólido. Tenha em mente que você também pode descarregar um escravo de replicação mysql.

Na página mysqldump (observe as advertências sobre as operações que irão vazar para a 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.

    

Answer 3

Não vejo muito problema na replicação de uma conexão de alta latência para um VPS barato nos EUA. A alta latência não deve ser um grande problema. A replicação é projetada para ser alcançada rapidamente mesmo quando um escravo cai horas por trás, ou seja, pode operar de forma assíncrona.

Desde que você consiga suportar essa largura de banda em seu plano de hospedagem na Austrália.

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

    

Answer 4

Realisticamente, apenas o tempo necessário para exportar o banco de dados será interrompido. Fazê-lo durante um período de tempo lento o suficiente e não deve haver qualquer problema. O que é realmente um departamento de TI desse orçamento?

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

A documentação do MySQL é fantástica : link

    

Answer 5

I'm not sure I can constrain memory usage on a per db basis

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

Você pode até mesmo fazer coisas para manipular a afinidade de prioridade de programação / CPU no mestre e no escravo usando nice / renice e taskset (assumindo que é um servidor Linux).

but the replication would take place over-net and the ping is ~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 está replicando dados de sessão) é várias ordens de magnitude menor que a largura de banda HTTP.

I need to [create a consistent backup of the database] (preferably every 4hrs) with no downtime

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

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

Você também pode considerar a execução de um escravo desconectado: ative os logs da caixa no servidor atual. Obtenha um backup, restaure o backup em uma máquina local e, em seguida, copie os logs bin enquanto eles são girados e envie-os para a frente no DBMS local .

    

Answer 6

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 - interrompe a replicação para a segunda conta / servidor.

3 - monitora o desempenho por alguns dias. Certifique-se de monitorá-lo por tempo suficiente para incluir os períodos mais ocupados.

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

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

6 - cancelar segunda conta.

Boa sorte!