É ruim ter um disco rígido muito cheio em um servidor de banco de dados de alto tráfego?

Question

Executando um servidor Ubuntu com MySQL para um servidor de banco de dados de produção de alto tráfego. Nada mais está sendo executado na máquina, exceto na instância do MySQL.

Armazenamos backups diários de bancos de dados no servidor de banco de dados. Há algum impacto no desempenho ou motivo pelo qual devemos manter o disco rígido relativamente vazio? Se o disco estiver preenchido até 86% + com o banco de dados e todos os backups, isso prejudicará o desempenho?

Assim, o servidor de banco de dados executando com 86-90% + capacidade total tem um desempenho menor do que o servidor executando com apenas 10% de disco completo?

O tamanho total do disco no servidor é superior a 1 TB, de modo que até 10% do disco deve ser suficiente para a troca básica de O / S e tal.

    

Answer 1

Primeiro de tudo, você NÃO deseja manter seus backups de banco de dados na mesma unidade física ou grupo de RAID que seu banco de dados. A razão para isso é que uma falha de disco (se você estiver executando sem qualquer proteção de RAID) ou uma falha de RAID catastrófica (se você estiver usando RAID-1 ou RAID-5) fará com que você perca seu banco de dados e seus backups de banco de dados. / p>

Sua pergunta sobre o desempenho do disco está relacionada à capacidade total da unidade de disco depende de como os dados no disco são acessados. Para discos giratórios, há dois fatores físicos que afetam o desempenho de E / S. Eles são:

• tempo de busca - que é o tempo que leva a unidade de disco para mover o disco cabeça de sua posição atual da pista para a pista que contém o dados solicitados

• latência rotacional - que é o tempo médio que leva para o dados desejados para alcançar a cabeça de leitura enquanto a unidade gira - por um Unidade de RPM, isto é 2 ms (milissegundos)

O tamanho da sua unidade pode afetar o tempo médio de busca que a E / S do seu servidor está passando. Por exemplo, se sua unidade estiver cheia e você tiver tabelas de banco de dados fisicamente localizadas na unidade nas extremidades opostas dos pratos do disco, ao executar I / Os acessando dados de cada uma dessas tabelas, as I / Os o tempo máximo de busca da unidade.

No entanto, se a sua unidade estiver cheia e seu aplicativo acessar apenas uma pequena fração dos dados armazenados na unidade e todos esses dados estiverem localizados contíguos na unidade, essas E / Ss serão minimamente afetadas. pelo tempo de busca.

Infelizmente, a resposta a essa pergunta é que "sua milhagem irá variar", o que significa que a forma como seu aplicativo acessa os dados e onde esses dados estão localizados determinará qual será o desempenho de I / O.

Além disso, como mencionado por @gravyface, seria "prática recomendada" separar os requisitos de armazenamento do sistema operacional do banco de dados. Novamente, isso ajudaria a minimizar o movimento da cabeça na superfície do disco, já que ter ambos na mesma unidade pode causar uma busca constante entre o sistema operacional e as áreas de banco de dados da unidade, pois tanto o sistema operacional quanto o software de banco de dados fazem solicitações de E / S. / p>     

Answer 2

Existem dois ângulos a serem considerados aqui: Desempenho e Robustez.

Em termos de desempenho, geralmente é recomendado ter fusos de disco separados (ou grupos de RAID / conjuntos de unidades) para:

1. O material do SO (binários, logs, diretórios iniciais, etc.)
2. Espaço de troca (que pode ser combinado com (1) se você não espera usar swap)
3. O banco de dados de produção
4. Os logs de transação do DB de produção (se usado)
5. Dumps / backups do banco de dados

O raciocínio por trás disso é bastante simples: você não quer que o desempenho do banco de dados seja impactado por "outras coisas" exigindo o disco (por exemplo, se a máquina começar a trocar muito e a partição swap estiver do outro lado do disco Dados do banco de dados com os quais o disco longo procura lidar).

Do ponto de vista da robustez, você deseja o mesmo tipo de detalhamento, mas por um motivo diferente: como outros apontaram, você não deseja que um disco com falha elimine o banco de dados e seus backups (embora, realisticamente, você esteja copiando os backups do servidor de qualquer maneira no caso de uma falha catastrófica).

Você também quer evitar qualquer configuração com uma partição / monolítica que contenha tudo - esse é um erro infeliz, trágico e assustadoramente comum cometido no mundo Linux que não é compartilhado por os outros sistemas do tipo Unix.
Como Gravyface mencionou em seu comentário, se você de alguma forma conseguir encher / seu sistema quase certamente falhará, e a limpeza / recuperação pode ser demorada e cara se o sistema tiver uma única partição / em vez de uma partição bem estruturada hierarquia de pontos de montagem.

    

Answer 3

Eu recomendaria mover o banco de dados e backups temporários (veja abaixo) para uma partição diferente da raiz (/).

Além disso, crie um esquema sensato de rotação / retenção para seus backups de despejo de banco de dados (assumidos). Não há (normalmente) nenhuma razão para manter tantas cópias dos backups no disco local. Não faz nada para recuperação de desastres e quando movido para fora do local, deve ser removido do disco.

Esse é praticamente o procedimento operacional padrão.

    

Answer 4

Isso me lembrou de um bug na NetApp em que os sistemas de arquivos quase completos tiveram um desempenho significativamente menor (como a metade). (admitidamente isso foi há alguns anos atrás).

A resposta como todos disseram é que depende, mas vale a pena pensar nisso.

A principal desvantagem dos sistemas de arquivos completos é que a lista de inodes livres provavelmente será fragmentada e em todo lugar.

Existem três tipos de dados que ficam no disco rígido para um banco de dados.

1. Seu arquivo de banco de dados real. Esse será um grande arquivo pré-alocado que geralmente cresce em grandes blocos (10%, por exemplo).
2. Registros, seu log de transações que está sendo continuamente gravado, excluído, gravado em, etc ...
3. Arquivos temporários para consultas grandes que não podem ser executados na memória.

(1) só precisa de espaço livre ao alocar mais espaço para o seu conjunto de arquivos. Se o seu banco de dados não estiver crescendo, ele não será afetado por um sistema de arquivos com pouco espaço em disco. No entanto, se estiver alocando, ele poderá solicitar um pedaço muito grande que não se encaixe em nenhuma lista livre que você tenha fragmentado imediatamente seu banco de dados e que cause a busca quando precisar que os dados estejam prontos na memória.

(2) uma impelementation ingênua de logs onde usa o sistema operacional para gerenciar a alocação de espaço e excluí-lo sofrerá. Supondo que seu banco de dados não seja somente leitura, haverá um fluxo constante de logs, eles serão freqüentemente fragmentados em um espaço de disco rígido baixo. Em última análise, isso prejudicará seu desempenho de gravação.

(3) tempDB, se o banco de dados precisar dele para consultas escritas de má qualidade ou RAM insuficiente, você terá problemas maiores do que o espaço em disco insuficiente, causando problemas de desempenho, já que seu desempenho de leitura pode se tornar vinculado ao disco. Você também corre o risco de uma falha se o MySql precisar alocar espaço em disco para o tempDB e o disco rígido acabar.

Sobre os backups ...

1. Toda empresa em que trabalhei mantém backups na mesma máquina. Quando se trata de uma restauração (quem se importa com backups, são as restaurações que contam). Nada vai bater a velocidade de ter o arquivo db ali mesmo no mesmo disco.
2. Espero que seja óbvio, garanta que os backups não sejam apenas locais.

Em suma, eu diria que você vai sobreviver fornecendo seu DB não é escrever pesado. Se estiver, o baixo espaço em disco é um problema. Mas se eu fosse você, eu trabalharia com o seguinte, mais cedo ou mais tarde.

1. Confirmando que tenho RAM suficiente
2. Segregando os logs e todos os dados temporários do seu banco de dados.
3. Segregando seu sistema operacional, seu MySql é instalado a partir do restante.

Use fusos e controladores separados, se puder, por 1.

Seguido por fusos separados

Seguido por partições separadas de um homem pobre.

    

Answer 5

Recentemente, tive um problema semelhante quando usei todo o espaço em disco em um dos meus servidores de replicação. O efeito imediato foi que a replicação falhasse e então eu não consegui logar no MySQL porque o arquivo mysqld.sock não pôde ser aberto.