Os fabricantes de servidores e provedores de nuvem oferecem diferentes tipos de soluções de armazenamento para atender às suas necessidades de banco de dados. Ao comprar um novo servidor ou escolher uma instância de nuvem para executar nosso banco de dados, muitas vezes nos perguntamos - quanto espaço em disco devemos alocar? Como veremos, a resposta não é trivial, pois há vários aspectos a serem considerados. O espaço em disco é algo que deve ser pensado antecipadamente, porque reduzir e expandir o espaço em disco pode ser uma operação arriscada para um banco de dados baseado em disco.
Nesta postagem do blog, veremos como dimensionar inicialmente seu espaço de armazenamento e, em seguida, planejar a capacidade para suportar o crescimento de seu banco de dados MySQL ou MariaDB.
Como o MySQL utiliza o espaço em disco
O MySQL armazena dados em arquivos no disco rígido em um diretório específico que possui a variável de sistema "datadir". O conteúdo do datadir dependerá da versão do servidor MySQL e dos parâmetros de configuração carregados e variáveis do servidor (por exemplo, general_log, slow_query_log, log binário).
As informações reais de armazenamento e recuperação dependem dos mecanismos de armazenamento. Para o mecanismo MyISAM, os índices de uma tabela são armazenados no arquivo .MYI, no diretório de dados, junto com os arquivos .MYD e .frm da tabela. Para o mecanismo InnoDB, os índices são armazenados no tablespace, junto com a tabela. Se innodb_file_per_table estiver definida, os índices estarão no arquivo .ibd da tabela junto com o arquivo .frm. Para o mecanismo de memória, os dados são armazenados na memória (heap) enquanto a estrutura é armazenada no arquivo .frm no disco. No próximo MySQL 8.0, os arquivos de metadados (.frm, .par, dp.opt) são removidos com a introdução do novo esquema de dicionário de dados.
É importante observar que, se você estiver usando o espaço de tabela compartilhado do InnoDB para armazenar dados de tabela (innodb_file_per_table=OFF ), espera-se que o tamanho dos dados físicos do MySQL cresça continuamente, mesmo depois de truncar ou excluir grandes linhas de dados. A única maneira de recuperar o espaço livre nesta configuração é exportar, excluir os bancos de dados atuais e reimportá-los de volta via mysqldump. Assim, é importante definir innodb_file_per_table=ON se você estiver preocupado com o espaço em disco, ao truncar uma tabela, o espaço poderá ser recuperado. Além disso, com essa configuração, uma operação DELETE enorme não liberará espaço em disco, a menos que OPTIMIZE TABLE seja executado posteriormente.
O MySQL armazena cada banco de dados em seu próprio diretório no caminho "datadir". Além disso, arquivos de log e outros arquivos MySQL relacionados, como arquivos de soquete e PID, por padrão, também serão criados em datadir. Por motivos de desempenho e confiabilidade, é recomendado armazenar os arquivos de log do MySQL em um disco ou partição separada - especialmente o log de erros do MySQL e os logs binários.
Estimativa do tamanho do banco de dados
A maneira básica de estimar o tamanho é encontrar a razão de crescimento entre dois pontos diferentes no tempo e depois multiplicá-la pelo tamanho atual do banco de dados. Medir o tráfego do banco de dados no horário de pico para essa finalidade não é a prática recomendada e não representa o uso do banco de dados como um todo. Pense em uma operação em lote ou em um procedimento armazenado executado à meia-noite ou uma vez por semana. Seu banco de dados pode crescer significativamente pela manhã, antes de possivelmente ser reduzido por uma operação de manutenção à meia-noite.
Uma forma possível é usar nossos backups como elemento base para esta medição. Backups físicos como Percona Xtrabackup, MariaDB Backup e instantâneos do sistema de arquivos produziriam uma representação mais precisa do tamanho do seu banco de dados em comparação com o backup lógico, pois contém a cópia binária do banco de dados e dos índices. Backup lógico como mysqldump armazena apenas instruções SQL que podem ser executadas para reproduzir as definições de objetos de banco de dados originais e dados de tabela. No entanto, você ainda pode obter uma boa taxa de crescimento comparando os backups do mysqldump.
Podemos usar a seguinte fórmula para estimar o tamanho do banco de dados:
Onde,
- B - Tamanho do backup completo da semana atual,
- B - Tamanho do backup completo da semana anterior,
- Dbdados - Tamanho total dos dados do banco de dados,
- Dbíndice - Tamanho total do índice do banco de dados,
- 52 - Número de semanas em um ano,
- S - Ano.
O tamanho total do banco de dados (dados e índices) em MB pode ser calculado usando as seguintes instruções:
mysql> SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) "DB Size in MB" FROM information_schema.tables;
+---------------+
| DB Size in MB |
+---------------+
| 2013.41 |
+---------------+A equação acima pode ser modificada se você quiser usar os backups mensais. Altere o valor constante de 52 para 12 (12 meses em um ano) e você está pronto para ir.
Além disso, não se esqueça de contabilizar innodb_log_file_size x 2, innodb_data_file_path e para Galera Cluster, adicione gcache.size valor.
Estimativa de tamanho de registros binários
Os logs binários são gerados pelo MySQL master para fins de replicação e recuperação pontual. É um conjunto de arquivos de log que contém informações sobre modificações de dados feitas no servidor MySQL. O tamanho dos logs binários depende do número de operações de gravação e do formato de log binário - STATEMENT, ROW ou MIXED. O log binário baseado em instrução é geralmente muito menor em comparação com o log binário baseado em linha, porque consiste apenas nas instruções de gravação, enquanto o baseado em linha consiste em informações de linhas modificadas.
A melhor maneira de estimar o uso máximo de disco de logs binários é medir o tamanho do log binário por um dia e multiplicá-lo pelos expire_logs_days valor (o padrão é 0 - sem remoção automática). É importante definir expire_logs_days para que você possa estimar o tamanho corretamente. Por padrão, cada log binário é limitado em torno de 1 GB antes que o MySQL gire o arquivo de log binário. Podemos usar um evento MySQL para simplesmente liberar o log binário para o propósito desta estimativa.
Em primeiro lugar, certifique-se de que a variável event_scheduler esteja habilitada:
mysql> SET GLOBAL event_scheduler = ON;Em seguida, como usuário privilegiado (com privilégios EVENT e RELOAD), crie o seguinte evento:
mysql> USE mysql;
mysql> CREATE EVENT flush_binlog
ON SCHEDULE EVERY 1 HOUR STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 2 HOUR
COMMENT 'Flush binlogs per hour for the next 2 hours'
DO FLUSH BINARY LOGS;Para uma carga de trabalho de gravação intensiva, você provavelmente precisará reduzir o intervalo para 30 minutos ou 10 minutos antes que o log binário atinja o tamanho máximo de 1 GB e, em seguida, arredondar a saída para uma hora. Em seguida, verifique o status do evento usando a seguinte instrução e observe a coluna LAST_EXECUTED:
mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
...
LAST_EXECUTED: 2018-04-05 13:44:25
...Então, dê uma olhada nos logs binários que temos agora:
mysql> SHOW BINARY LOGS;
+---------------+------------+
| Log_name | File_size |
+---------------+------------+
| binlog.000001 | 146 |
| binlog.000002 | 1073742058 |
| binlog.000003 | 1073742302 |
| binlog.000004 | 1070551371 |
| binlog.000005 | 1070254293 |
| binlog.000006 | 562350055 | <- hour #1
| binlog.000007 | 561754360 | <- hour #2
| binlog.000008 | 434015678 |
+---------------+------------+Podemos então calcular a média do crescimento de nossos logs binários, que é de cerca de ~562 MB por hora durante os horários de pico. Multiplique esse valor por 24 horas e os expire_logs_days valor:
mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
| 94416 |
+---------------------------------+Teremos 94416 MB, o que equivale a ~95 GB de espaço em disco para nossos logs binários. Os logs de retransmissão do escravo são basicamente os mesmos que os logs binários do mestre, exceto que são armazenados no lado escravo. Portanto, este cálculo também se aplica aos logs do relé escravo.
Disco fuso ou estado sólido?
Existem dois tipos de operações de E/S em arquivos MySQL:
- Arquivos orientados a E/S sequenciais:
- Espaço de tabela do sistema InnoDB (ibdata)
- Arquivos de log do MySQL:
- Registros binários (binlog.xxxx)
- Registros de REDO (ib_logfile*)
- Registros gerais
- Registros de consulta lenta
- Registro de erros
- Arquivos orientados a E/S aleatória:
- Arquivo de dados de arquivo por tabela do InnoDB (*.ibd) com innodb_file_per_table=ON (padrão).
Considere colocar arquivos orientados a E/S aleatórios em um subsistema de disco de alto rendimento para obter melhor desempenho. Isso pode ser uma unidade flash - SSDs ou cartão NVRAM ou discos de eixo de alta RPM, como SAS 15K ou 10K, com controlador RAID de hardware e unidade com bateria. Para arquivos orientados a E/S sequenciais, armazenar em HDD com cache de gravação com bateria deve ser bom o suficiente para o MySQL. Observe que a degradação do desempenho é provável se a bateria estiver descarregada.
Cobriremos essa área (estimativa da taxa de transferência do disco e alocação de arquivos) em um post separado.
Planejamento e Dimensionamento de Capacidade
O planejamento de capacidade pode nos ajudar a construir um servidor de banco de dados de produção com recursos suficientes para sobreviver às operações diárias. Também devemos prever necessidades inesperadas, levar em conta as necessidades futuras de armazenamento e taxa de transferência do disco. Assim, o planejamento de capacidade é importante para garantir que o banco de dados tenha espaço suficiente para respirar até o próximo ciclo de atualização de hardware.
É melhor ilustrar isso com um exemplo. Considerando o seguinte cenário:
- Próximo ciclo de hardware:3 anos
- Tamanho atual do banco de dados:2013 MB
- Tamanho atual do backup completo (semana N):1177 MB
- Tamanho do backup completo anterior (semana N-1):936 MB
- Tamanho delta:241 MB por semana
- Proporção delta:incremento de 25,7% por semana
- Total de semanas em 3 anos:156 semanas
- Estimativa do tamanho total do banco de dados:((1177 - 936) x 2013 x 156)/936 =80856 MB ~ 81 GB após 3 anos
Se você estiver usando logs binários, resuma a partir do valor obtido na seção anterior:
- 81 + 95 =176 GB de armazenamento para banco de dados e logs binários.
Adicione pelo menos 100% mais espaço para tarefas operacionais e de manutenção (backup local, preparação de dados, log de erros, arquivos do sistema operacional etc.):
- 176 + 176 =352 GB de espaço total em disco.
Com base nessa estimativa, podemos concluir que precisaríamos de pelo menos 352 GB de espaço em disco para nosso banco de dados por 3 anos. Você pode usar esse valor para justificar a compra do novo hardware. Por exemplo, se você quiser comprar um novo servidor dedicado, poderá optar por 6 x 128 SSD RAID 10 com controlador RAID com bateria, que fornecerá cerca de 384 GB de espaço total em disco. Ou, se preferir a nuvem, você pode obter 100 GB de armazenamento em bloco com IOPS provisionado para nosso uso de banco de dados de 81 GB e usar o armazenamento em bloco persistente padrão para nossos logs binários de 95 GB e outros usos operacionais.
Bom dimensionamento!
