MySQL InnoDB sobre um dispositivo bruto em uma topologia ativa/passiva

Question

Temos uma topologia Ativo/Passivo onde existem dois complexos x86 com armazenamento bruto compartilhado, onde apenas um dos nós em um determinado momento tem acesso ao armazenamento compartilhado (também conhecido como nó ativo).No caso de um failover no nó ativo, o nó passivo inicia um controle e se torna o nó ativo com acesso ao armazenamento compartilhado.Cada nó possui seu próprio armazenamento de dispositivo de inicialização com um sistema de arquivos.Entretanto, o armazenamento compartilhado não pode ter um sistema de arquivos montado nele.

Estamos interessados ​​em instalar o MySQL em ambos os nós, onde seus dados residem no armazenamento compartilhado e apenas o nó ativo está executando o servidor.

MySQL com InnoDB é capaz de rodar em um dispositivo bruto, e também há um guia sobre como executar MySQL em um cluster semelhante à nossa topologia.No entanto, no segundo exemplo, eles possuem um sistema de arquivos montado no armazenamento compartilhado.A questão do sistema de arquivos levanta uma grande preocupação:

ib_logfile* ainda requer um sistema de arquivos.Portanto, o recurso bruto do MySQL não é exatamente totalmente bruto.Por favor, corrija-me se eu estiver enganado.Existe uma solução alternativa para armazenar esses arquivos no armazenamento bruto?Podemos salvar os redo logs (ib_logfile0, ib_logfile1) no dispositivo de inicialização do nó e sempre exclua esses arquivos antes de o servidor ser iniciado (para que não tenhamos arquivos de log antigos no caso de vários failovers).No entanto, isto pode levar a que uma transação não confirmada seja parcialmente confirmada em caso de falha no meio de uma transação, contradizendo assim toda a ideia de transações.

Existem mais arquivos/recursos que podem afetar o comportamento do mysql nesta topologia?

Answer 1

É importante notar que o log write ahead (WAL) do InnoDB, o ib_logfile*, não é a única coisa que precisará de um sistema de arquivos.Você tem:

1. Tabelas de sistema no esquema mysql que provavelmente usam o mecanismo de armazenamento MyISAM (.frm, .MYD, .MYI por tabela) (a maioria agora está usando InnoDB na versão 5.7)
2. Arquivos .frm para cada tabela do InnoDB, mesmo ao usar o espaço de tabela do sistema compartilhado (metadados da tabela necessários)
3. Arquivos de log do MySQL (log de erros, log geral, log binário)
4. Artefatos SSL
5. auto.cnf (onde o UUID da instância MySQL é gerado e armazenado automaticamente)
6. arquivo db.opt para cada esquema (em /<datadir>/<schema>/)
7. Arquivo .par se você criar uma tabela particionada (desaparecido em 5.7)
8. Arquivos .trn e .trg se você criar gatilhos
9. Espaço de tabela tmp do InnoDB (5.6+)
10. Mapa de páginas do buffer pool persistente (ib_buffer_pool, 5.6+)

Todos os itens acima estão normalmente dentro do diretório de dados, então contanto que você tenha datadir=/some/valid/fs/path - isso também é replicado (por exemploDRBD) ou compartilhado (por exemploNFS, GFS, OCFS) entre os dois nós - então você ficará bem.

É importante notar que os arquivos .frm, .par, .trn, .trg e .opt desaparecerão com o novo dicionário de dados.

Fique ligado em alguns grandes anúncios nos próximos meses!:)

Não está claro para mim por que você está usando o dispositivo RAW?Tenho certeza que você tem seus motivos.:)

Boa sorte!

Answer 2

A técnica de armazenamento bruto só é boa para ibdata1 com innodb_file_per_table desabilitado.

Eu mencionei a configuração disso algumas vezes

• Jul 25, 2012 : Design de banco de dados - Criação de vários bancos de dados para evitar a dor de cabeça do limite no tamanho da tabela
• Feb 26, 2013 : Manutenção no MYSQL quando innodb_file_per_table desabilitado

Observe a arquitetura InnoDB (foto do CTO da Percona, Vadim Tkachenko)

Com innodb_file_per_table desativado, os dados e índices de todas as tabelas do InnoDB cairiam dentro do armazenamento bruto junto com o buffer de gravação duplo, buffer de inserção, dicionário de dados, segmentos de rollback e espaço de desfazer.

Com relação aos redo logs, você deve considerar ter um pequeno dispositivo de bloco DRBD apenas para armazenar /var/lib/mysql, com ib_logfile0 e ib_logfile1 nessa pasta.Assim, o failover seria da seguinte forma

• Quebre o DRBD entre os dois servidores
• Defina o estado DRBD do novo servidor como Primary/Unknown
• Monte o DRBD em /var/lib/mysql
• Monte o dispositivo bruto com as informações do ibdata1
• service mysql start
• Sincronizar dispositivos DRBD
• Configurar Marcapasso/ucarpo serviços para preparar o próximo failover

Eu preferi DRBD/ucarp para configurações de failover. Veja meus posts antigos sobre eles

ATUALIZAÇÃO 14/10/2015 11:30 EDT

Como já mencionei, os redo logs devem estar no dispositivo de bloco DRBD montado em /var/lib/mysql.No que diz respeito a outros arquivos essenciais, como

• registros binários
• registros de retransmissão
• registro de erros
• registro lento
• registro geral

todos esses arquivos devem estar em /var/lib/mysql também.Dessa forma, os failovers carregarão tudo relacionado ao MySQL (menos os dados brutos que estão em seu próprio disco).

AVISO :Esta configuração não é para tabelas MyISAM.Se ocorrer um hard failover, todas as tabelas MyISAM abertas antes da falha/failover serão marcadas como corrompidas e exigirão execução REPAIR TABLE em todas as tabelas MyISAM.

Se todas as suas tabelas forem InnoDB, ignore este aviso.Se você converter suas tabelas MyISAM restantes em InnoDB, poderá ignorar este aviso.(NÃO CONVERTA NENHUMA TABELAS MyISAM NO mysql ESQUEMA NO InnoDB).