Ponto de vista do RAID5
Embora alguns considerem o RAID5 como uma solução de redundância de disco do homem pobre, para sua própria segurança e sanidade, por favor, livre-se do RAID5 o mais rápido possível. Por que ???
- Em um ambiente de pouca gravação e leitura pesada em um RAID5, eu apenas deixaria isso para
- Seu orçamento
- Sua tolerância
- Sua pressão arterial
- Em um ambiente de leitura pesada, leitura baixa ou gravação pesada, o RAID5 está fora de questão . Isto é especialmente verdade para o InnoDB.
Agora vamos discutir InnoDB e MyISAM
InnoDB
Se você não usar innodb_file_per_table , OMG toda a atividade seria centrada em torno de apenas um arquivo, ibdata1. O que está contido no ibdata1 do InnoDB?
- Páginas de dados de tabela
- Índice de páginas de tabela
- Metadados de tabela para gerenciar IDs do TableSpace
-
Dados MVCC (para conformidade com conformidade e transação de ACID)
Mesmo as leituras no InnoDB tendem a encobrir linhas com proteção MVCC para permitir leituras repetitivas e permitir que as transações atinjam as mesmas linhas que estão sendo lidas. Assim, as leituras, assim como as gravações, produzem E / S de disco em ibdata1.
O uso de innodb_file_per_table pode aliviar parte da E / S do disco, separando as páginas Table Data e Index de ibdata1 em .ibd files. No entanto, eu esperaria uma melhoria notável de desempenho apenas por um tempo limitado em um ambiente RAID5. A interação da tabela ainda é um pouco a mesma. Todo acesso a um arquivo .ibd é sempre precedido por verificações de referência em relação ao ibdata1.
Embora a separação possa trazer mudanças significativas no desempenho, o RAID5 seria o que eles chamam no mundo da química, um reagente limitante. Quaisquer benefícios esperados das mudanças de layout do InnoDB seriam neutralizados por fatores externos, como o RAID5. A presença de arquivos de espaço de tabela extras devido a innodb_file_per_table não compra nada ao longo do tempo, mas apenas a presença de arquivos extras de espaço de tabela.
MyISAM
Quando se trata de MyISAM, o RAID5 é OK em um ambiente de pouca gravação e leitura , desde que você mapeie todas as tabelas temporárias (usando tmpdir ) para outro disco, separado do RAID5 . (Soa como derrotar o propósito do RAID5, hein?)
Lembre-se de que as páginas de dados da tabela estão em .MYD files e suas páginas de índice correspondentes estão em .MYI files. Um ambiente de gravação pesada (INSERTs, UPDATEs, DELETEs) obrigará o RAID5 a atrasar as coisas. Dado o comportamento de bloqueio do MyISAM (bloqueio total de tabela com cada INSERT, UPDATE e DELETE) em um ambiente de gravação pesada, um fluxo constante de DML manterá o RAID5 bastante ocupado e fará com que os usuários de DB entrem em um tempo breve mas irritante esperando por DML para completar.
Conclusão sobre o RAID5
Sob o capô, o RAID5 tem as seguintes características para escrever com paridade
- Leia o bloco de dados antigo
- Leia o antigo bloco de paridade
- Compare o bloco de dados antigo com a solicitação de gravação. Para cada bit que foi invertido (alterado de 0 para 1, ou de 1 para 0) no bloco de dados, inverta o bit correspondente no bloco de paridade
- Escreva o novo bloco de dados
- Escreva o novo bloco de paridade
Se qualquer uma dessas etapas exibir a menor intermitência, o conjunto RAID5 entrará em uma distorção de tempo breve, mas incômoda. Multiplique isso por um grande número de gravações e você a sentirá no desempenho do banco de dados. Cada uma dessas etapas pode ser um ponto de falha. Por quê?
De acordo com a Wikipédia sobre o RAID5
In the event of a system failure while there are active writes, the
parity of a stripe may become inconsistent with the data. If this is
not detected and repaired before a disk or block fails, data loss may
ensue as incorrect parity will be used to reconstruct the missing
block in that stripe. This potential vulnerability is sometimes known
as the write hole. Battery-backed cache and similar techniques are
commonly used to reduce the window of opportunity for this to occur.
RECOMENDAÇÃO (RAID5)
O RAID10 não apenas fornece estabilidade, mas permite uma certa margem de manobra na manutenção do disco, sem precisar baixar o mysql na maioria dos casos. Quando os dados são espelhados, você sabe para onde os dados estão indo e você sabe de onde os dados estão sendo lidos.
Eu diria que vá com o RAID10. A menos que você não se importe com longos períodos de inatividade, você não poderá fazer a manutenção do disco RAID5 em vez da necessária sincronização de disco. Na verdade, quanto menores forem os discos que você distribui no RAID10, mais rápido será o tempo de sincronização após a manutenção do disco RAID 10.
Outras coisas a serem consideradas
- Ajustar suas consultas
- Remover índices redundantes
- Armazene o máximo de dados possível
- Use índices de cobertura com sabedoria
VMWare Viewpoint
Em relação ao mestre e ao escravo no VMWare, certifique-se de que o mestre e o escravo estejam em discos físicos separados. Se os discos no VMWare forem RAID5, por favor, obtenha outro Cluster VMWare agora mesmo usando o RAID10.