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

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 a instância do MySQL.

Armazenamos backups diários do banco de dados no servidor de banco de dados. Existe algum problema de 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?

Então, o servidor de banco de dados em execução com capacidade total de 86 a 90% + teria um desempenho menos eficiente do que o servidor em execução com apenas 10% de disco completo?

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

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

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

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

• latência de rotação - que é o tempo médio necessário para os dados desejados atingirem a cabeça de leitura à medida que a unidade gira - para uma unidade de 15K RPM, isso é 2 ms (milissegundos)

A capacidade da unidade pode afetar o tempo médio de busca das E / Ss do servidor. Por exemplo, se sua unidade estiver cheia e você tiver tabelas de banco de dados localizadas fisicamente na unidade nas extremidades opostas dos pratos do disco, ao executar E / Ss acessando dados de cada uma dessas tabelas, essas E / Ss sofrerão o tempo máximo de busca da unidade.

Entretanto, se sua unidade estiver cheia e seu aplicativo acessar apenas uma pequena fração dos dados armazenados na unidade e todos esses dados estiverem localizados contiguamente na unidade, essas E / Ss serão impactadas minimamente pelo tempo de busca .

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

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 do cabeçote na superfície do disco, pois ter ambos na mesma unidade poderia causar busca constante entre o sistema operacional e as áreas de banco de dados da unidade, pois o sistema operacional e o software de banco de dados solicitam E / S.

Há dois ângulos a serem considerados aqui: desempenho e robustez.

Em termos de desempenho, geralmente é recomendável ter eixos de disco separados (ou grupos / conjuntos de unidades RAID) para:

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

O raciocínio por trás disso é bastante direto: você não deseja que o desempenho do banco de dados seja afetado por "outras coisas" que exigem o disco (por exemplo, se a máquina começar a trocar muito e a partição de troca estiver do outro lado do disco a partir dos dados do banco de dados tem disco longo procura lidar com).

Do ponto de vista da robustez, você deseja o mesmo tipo de detalhamento, mas por um motivo diferente: Como outros salientaram, você não deseja que um disco com falha retire o banco de dados e seus backups (embora, na realidade, você deva copiar os backups) servidor de qualquer maneira no caso de uma falha catastrófica).

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

Eu recomendo 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 compactados (supostos). Geralmente, não há motivo para manter tantas cópias dos backups no disco local. Não faz nada para a recuperação de desastres e, quando movido para fora do local, deve ser removido do disco.

Esse é o procedimento operacional padrão.

Isso me lembrou de um bug na NetApp em que os sistemas de arquivos que estavam quase cheios tiveram um desempenho significativamente menor (como a metade). (é verdade que isso foi há alguns anos).

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 o lugar.

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

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

(1) precisa apenas 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 deve ser afetado por um sistema de arquivos com pouco espaço em disco. Se estiver alocando, pode pedir um pedaço muito grande que não se encaixe em nenhuma lista gratuita que você tenha imediatamente fragmentado seu banco de dados e causando procura quando precisar de dados para ficar pronto na memória.

(2) uma impelementação ingênua de logs em que ele usa o sistema operacional para gerenciar a alocação de espaço e a exclusão dele. Supondo que seu banco de dados não seja somente leitura, haverá um fluxo constante de logs, eles serão frequentemente fragmentados em um espaço insuficiente no disco rígido. 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 que pouco espaço em disco, causando problemas de desempenho, pois mesmo o desempenho de leitura pode ficar vinculado ao disco. Você também corre o risco de uma interrupção se o MySql precisar alocar espaço em disco para o tempDB e o disco rígido acabar.

Sobre backups ...

1. Cada 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 superar a velocidade de ter o arquivo db ali no mesmo disco.
2. Espero que seja óbvio, garanta que os backups não sejam apenas locais.

Em resumo, eu diria que você sobreviverá, desde que seu banco de dados não seja pesado. Se estiver, pouco espaço em disco é um problema. Mas se eu fosse você, trabalharia no seguinte mais cedo ou mais tarde.

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

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

Seguido por eixos separados

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

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 o travamento da replicação e, portanto, não consegui entrar no MySQL porque o arquivo mysqld.sock não pôde ser aberto.