Compartilhar via

Parâmetros do servidor no Banco de Dados do Azure para MySQL – Servidor Flexível

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL – Servidor flexível

Este artigo fornece diretrizes e considerações para configurar parâmetros de servidor no Banco de Dados do Azure para MySQL - servidor flexível.

Observação

Este artigo contém referências ao termo servidor subordinado, um termo que a Microsoft não usa mais. Quando o termo for removido do software, também o removeremos deste artigo.

O que são variáveis de servidor?

O mecanismo MySQL fornece diferentes variáveis/parâmetros de servidor que podem ser usados para configurar e ajustar o comportamento do mecanismo. Alguns parâmetros podem ser definidos dinamicamente durante o runtime, enquanto outros são "estáticos", exigindo uma reinicialização do servidor para serem aplicados.

O servidor flexível do Banco de Dados do Azure para MySQL expõe a capacidade de alterar o valor de vários parâmetros do MySQL Server usando o portal do Azure e a CLI do Azure para corresponder às necessidades da sua carga de trabalho.

Parâmetros de servidor configuráveis

Você pode gerenciar a configuração do servidor flexível do Banco de Dados do Azure para MySQL usando os parâmetros de servidor. Os parâmetros de servidor são configurados com o valor padrão e recomendado quando você cria o servidor. A folha de parâmetros do servidor no portal do Azure mostra os parâmetros de servidor modificáveis e não modificáveis. Os parâmetros do servidor não modificáveis estão esmaecidos.

A lista de parâmetros de servidor com suporte está em constante crescimento. Use a guia de parâmetros do servidor no portal do Azure para ver a lista completa e configurar os valores desses parâmetros.

Veja as seções a seguir para saber mais sobre os limites dos parâmetros de servidor atualizados mais frequentemente. Os limites são determinados pela camada de computação e pelo tamanho (vCores) do servidor.

Observação

  • Se você modificar um parâmetro do servidor estático usando o portal, precisará reiniciar o servidor para que as alterações entrem em vigor. Se você usa scripts de automação (com ferramentas como modelos do ARM, Terraform, CLI do Azure etc.), o script deverá ter uma provisão para reiniciar o serviço para que as definições entrem em vigor mesmo se você estiver alterando as configurações como parte da experiência de criação.
  • Se você quiser modificar um parâmetro de servidor não modificável para seu ambiente, abra um item UserVoice ou vote se os comentários já existirem, o que pode nos ajudar a priorizar.

lower_case_table_names

Para o MySQL versão 5.7, o valor padrão é 1 no servidor flexível do Banco de Dados do Azure para MySQL. É importante observar que, embora seja possível alterar o valor com suporte para 2, a reversão de 2 para 1 não é permitida. Entre em contato com nossa equipe de suporte para obter ajuda para alterar o valor padrão. No MySQL versão 8.0+, lower_case_table_names só pode ser configurado ao inicializar o servidor. Saiba mais. É proibido alterar a configuração de lower_case_table_names após a inicialização do servidor. Para o MySQL versão 8.0, o valor padrão é 1 no servidor flexível do Banco de Dados do Azure para MySQL. O valor com suporte para o MySQL versão 8.0 é 1 e 2 no servidor flexível do Banco de Dados do Azure para MySQL. Entre em contato com nossa equipe de suporte para obter ajuda para alterar o valor padrão durante a criação do servidor.

innodb_tmpdir

O parâmetro innodb_tmpdir no Servidor Flexível do Banco de Dados do Azure para MySQL é usado para definir o diretório para arquivos de classificação temporários criados durante operações ALTER TABLE online que são recompiladas. O valor padrão de innodb_tmpdir é /mnt/temp. Esse local corresponde ao SSD de armazenamento temporário, disponível no GiB com cada tamanho da computação do servidor. Esse local é ideal para operações que não exigem uma grande quantidade de espaço. Se for necessário mais espaço, você poderá definir innodb_tmpdir para /app/work/tmpdir. Isso utiliza seu armazenamento, a capacidade disponível no Servidor Flexível do Banco de Dados do Azure para MySQL. Isso pode ser útil para operações maiores que exigem mais armazenamento temporário. É importante observar que utilizar /app/work/tmpdir resulta em um desempenho mais lento em comparação com o armazenamento temporário padrão (SSD) /mnt/temp. A escolha deve ser feita com base nos requisitos específicos das operações.

As informações fornecidas para innodb_tmpdir são aplicáveis aos parâmetros innodb_temp_tablespaces_dir, tmpdir e slave_load_tmpdir em que o valor padrão /mnt/temp é comum e o diretório alternativo /app/work/tmpdir está disponível para configurar o armazenamento temporário aumentado, com uma compensação no desempenho com base em requisitos operacionais específicos.

log_bin_trust_function_creators

No servidor flexível do Banco de Dados do Azure para MySQL, os logs binários são sempre habilitados (ou seja, log_bin está definido como ON). log_bin_trust_function_creators é definido como ON por padrão em servidores flexíveis.

O log binário tem sempre o formato de LINHA e todas as conexões com o servidor SEMPRE usam o log binário baseado em linha. Com o log binário baseado em linha, não existem problemas de segurança e o log binário não pode ser interrompido, o que permite que você defina log_bin_trust_function_creators como ON com segurança.

Se [log_bin_trust_function_creators] estiver definido como OFF, caso você utilize gatilhos, receberá um erro semelhante a você não tem o privilégio SUPER e o log binário está habilitado (o ideal é usar a variável log_bin_trust_function_creators menos segura).

innodb_buffer_pool_size

Consulte a documentação do MySQL para saber mais sobre esse parâmetro. O tamanho da memória física (GB) na tabela abaixo representa a memória de acesso aleatório (RAM) disponível em gigabytes (GB) no servidor flexível do Banco de Dados do Azure para MySQL.

Tipo de preço vCore(s) Tamanho de memória física (GiB) Valor padrão (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Expansível (B1s) 1 1 134217728 33554432 268435456
Expansível (B1ms) 1 2 536870912 134217728 1073741824
Com capacidade de intermitência (B2s) 2 4 2147483648 134217728 2147483648
Com capacidade de intermitência (B2ms) 2 8 4294967296 134217728 5368709120
Com capacidade de intermitência 4 16 12884901888 134217728 12884901888
Com capacidade de intermitência 8 32 25769803776 134217728 25769803776
Com capacidade de intermitência 12 48 51539607552 134217728 51539607552
Com capacidade de intermitência 16 64 2147483648 134217728 2147483648
Com capacidade de intermitência 20 80 64424509440 134217728 64424509440
Uso Geral 2 8 4294967296 134217728 5368709120
Uso Geral 4 16 12884901888 134217728 12884901888
Uso Geral 8 32 25769803776 134217728 25769803776
Uso Geral 16 64 51539607552 134217728 51539607552
Uso Geral 32 128 103079215104 134217728 103079215104
Uso Geral 48 192 154618822656 134217728 154618822656
Uso Geral 64 256 206158430208 134217728 206158430208
Comercialmente Crítico 2 16 12884901888 134217728 12884901888
Comercialmente Crítico 4 32 25769803776 134217728 25769803776
Comercialmente Crítico 8 64 51539607552 134217728 51539607552
Comercialmente Crítico 16 128 103079215104 134217728 103079215104
Comercialmente Crítico 20 160 128849018880 134217728 128849018880
Comercialmente Crítico 32 256 206158430208 134217728 206158430208
Comercialmente Crítico 48 384 309237645312 134217728 309237645312
Comercialmente Crítico 64 504 405874409472 134217728 405874409472

innodb_file_per_table

O MySQL armazena a tabela InnoDB em espaços de tabela diferentes com base na configuração fornecida durante a criação da tabela. O espaço de tabela do sistema é a área de armazenamento do dicionário de dados InnoDB. Um espaço de tabela de arquivo por tabela contém dados e índices de uma única tabela InnoDB e é armazenado no sistema de arquivos em seu próprio arquivo de dados. Esse comportamento é controlado pelo parâmetro do servidor innodb_file_per_table. Definir innodb_file_per_table como OFF faz com que o InnoDB crie tabelas no espaço de tabela do sistema. Caso contrário, o InnoDB cria tabelas em espaços de tabela de arquivo por tabela.

O servidor flexível do Banco de Dados do Azure para MySQL oferece suporte abrangente, de 8 TB em um único arquivo de dados. Se o banco de dados tiver mais que 8 TB, você deverá criar a tabela no espaço de tabela innodb_file_per_table. Se você tiver um tamanho de tabela único maior que 8 TB, deverá usar a tabela de partição.

innodb_log_file_size

innodb_log_file_size é o tamanho em bytes de cada arquivo de log em um grupo de log. O tamanho combinado dos arquivos de log (innodb_log_file_size * innodb_log_files_in_group) não pode exceder um valor máximo que seja ligeiramente menor que 512 GB). Um tamanho do arquivo de log maior é melhor para o desempenho, mas tem a desvantagem de que o tempo de recuperação após uma falha é alto. Você precisa equilibrar o tempo de recuperação no raro evento de uma recuperação de falha versus maximizar a taxa de transferência durante as operações de pico. Isso também pode resultar em tempos de reinicialização mais longos. Configure innodb_log_size para qualquer um desses valores: 256 MB, 512 MB, 1 GB ou 2 GB para o servidor flexível do Banco de Dados do Azure para MySQL. O parâmetro é estático e requer uma reinicialização.

Observação

Se você alterou o parâmetro innodb_log_file_size do padrão, verifique se o valor de "mostrar status global como 'innodb_buffer_pool_pages_dirty'" permanece em 0 por 30 segundos para evitar atraso na reinicialização.

max_connections

O valor de max_connection é determinado pelo tamanho da memória do servidor. O tamanho da memória física (GB) na tabela abaixo representa a memória de acesso aleatório (RAM) disponível em gigabytes (GB) no servidor flexível do Banco de Dados do Azure para MySQL.

Tipo de preço vCore(s) Tamanho de memória física (GiB) Valor padrão Valor mínimo Valor máximo
Expansível (B1s) 1 1 85 10 171
Expansível (B1ms) 1 2 171 10 341
Com capacidade de intermitência (B2s) 2 4 341 10 683
Com capacidade de intermitência (B2ms) 2 4 683 10 1365
Com capacidade de intermitência 4 16 1365 10 2731
Com capacidade de intermitência 8 32 2731 10 5461
Com capacidade de intermitência 12 48 4097 10 8193
Com capacidade de intermitência 16 64 5461 10 10923
Com capacidade de intermitência 20 80 6827 10 13653
Uso Geral 2 8 683 10 1365
Uso Geral 4 16 1365 10 2731
Uso Geral 8 32 2731 10 5461
Uso Geral 16 64 5461 10 10923
Uso Geral 32 128 10923 10 21845
Uso Geral 48 192 16384 10 32768
Uso Geral 64 256 21845 10 43691
Comercialmente Crítico 2 16 1365 10 2731
Comercialmente Crítico 4 32 2731 10 5461
Comercialmente Crítico 8 64 5461 10 10923
Comercialmente Crítico 16 128 10923 10 21845
Comercialmente Crítico 20 160 13653 10 27306
Comercialmente Crítico 32 256 21845 10 43691
Comercialmente Crítico 48 384 32768 10 65536
Comercialmente Crítico 64 504 43008 10 86016

Quando as conexões excederem o limite, você poderá receber o seguinte erro:

ERRO 1040 (08004): Muitas conexões

Importante

Para obter a melhor experiência, recomendamos usar um pool de conexões como o ProxySQL para gerenciar conexões com eficiência.

A criação de novas conexões de cliente com o MySQL leva tempo e, uma vez estabelecidas, essas conexões ocupam recursos do banco de dados, mesmo quando ociosas. A maioria dos aplicativos solicita muitas conexões de curta duração, o que agrega a essa situação. O resultado é um número menor de recursos disponíveis para sua carga de trabalho real, o que leva à redução do desempenho. Um pooler de conexões que diminui as conexões ociosas e reutiliza as conexões existentes ajuda a evitar isso. Para saber mais sobre a configuração do ProxySQL, visite nossa postagem do blog.

Observação

ProxySQL é uma ferramenta de comunidade de software livre. Ela tem suporte da Microsoft com base no melhor esforço. Para obter suporte à produção com diretrizes autoritativas, avalie e entre em contato com o Suporte ao produto ProxySQL.

innodb_strict_mode

Se você receber um erro semelhante a "Tamanho de linha muito grande (> 8126)", desative o parâmetro innodb_strict_mode. O parâmetro de servidor innodb_strict_mode não pode ser modificado globalmente no nível do servidor porque, se o tamanho dos dados da linha exceder 8 K, eles serão truncados sem um erro, o que pode resultar em perda de dados. É recomendável modificar o esquema para se ajustar ao limite do tamanho de página.

Esse parâmetro pode ser definido no nível de sessão por meio de init_connect. Para definir innodb_strict_mode no nível de sessão, confira Parâmetro de configuração não listado.

Observação

Caso você tenha um servidor de réplica de leitura, a replicação será interrompida se innodb_strict_mode for definido como Desativado no nível de sessão em um servidor de origem. Sugerimos manter o parâmetro definido como ON caso você tenha réplicas de leitura.

time_zone

Após a implantação inicial, uma instância do servidor flexível do Banco de Dados do Azure para MySQL inclui tabelas do sistema para informações de fuso horário, embora essas tabelas não estejam preenchidas. As tabelas de fuso horário podem ser preenchidas, chamando o procedimento armazenado mysql.az_load_timezone de uma ferramenta como a linha de comando do MySQL ou o Workbench do MySQL. Consulte os artigos Portal do Azure ou CLI do Azure para saber como chamar o procedimento armazenado e definir os fusos horários globais ou no nível da sessão.

binlog_expire_logs_seconds

No servidor flexível do Banco de Dados do Azure para MySQL, esse parâmetro especifica o número de segundos que o serviço aguarda antes de limpar o arquivo de log binário.

O log binário contém “eventos” que descrevem as alterações no banco de dados, como operações de criação de tabelas ou alterações em dados de tabela. Ele também contém eventos para instruções que potencialmente poderiam ter feito alterações. O log binário é usado principalmente para duas finalidades: operações de replicação e de recuperação de dados. Normalmente, os logs binários são limpos assim que o identificador fica livre do serviço, de backup ou do conjunto de réplicas. Se houver várias réplicas, os logs binários aguardam a réplica mais lenta ler as alterações antes de ser limpa. Se você quiser persistir os logs binários para obter mais duração de tempo, poderá configurar o parâmetro binlog_expire_logs_seconds. Se binlog_expire_logs_seconds for definido como 0, que é o valor padrão, ele será limpo assim que o identificador para o log binário for liberado. Se binlog_expire_logs_seconds > 0, ele esperará os segundos configurados antes de limpar. Para o servidor flexível do Banco de Dados do Azure para MySQL, os recursos gerenciados como backup e limpeza de réplica de leitura de arquivos binários são manipulados internamente. Quando você replica os dados para fora do servidor flexível do Banco de Dados do Azure para MySQL, esse parâmetro precisa ser definido no primário para evitar a limpeza dos logs binários antes que a réplica leia as alterações do primário. Se você definir binlog_expire_logs_seconds como um valor mais alto, os logs binários não serão limpos em tempo hábil e poderão levar a um aumento na cobrança de armazenamento.

event_scheduler

No servidor flexível do Banco de Dados do Azure para MySQL, o parâmetro de servidor event_schedule gerencia a criação, o agendamento e a execução de eventos, ou seja, tarefas executadas de acordo com um agendamento, e elas são executadas por um thread do agendador de eventos especial. Quando o parâmetro event_scheduler é definido como ON, o thread do agendador de eventos é listado como um processo de daemon na saída de SHOW PROCESSLIST. Você pode criar e agendar eventos usando a seguinte sintaxe SQL:

CREATE EVENT <event name>
ON SCHEDULE EVERY _ MINUTE / HOUR / DAY
STARTS TIMESTAMP / CURRENT_TIMESTAMP
ENDS TIMESTAMP / CURRENT_TIMESTAMP + INTERVAL 1 MINUTE / HOUR / DAY
COMMENT ‘<comment>’
DO
<your statement>;

Observação

Para obter mais informações sobre como criar um evento, confira a documentação do Event Scheduler do MySQL aqui:

Configurando o parâmetro de servidor event_scheduler

O cenário a seguir ilustra uma maneira de usar o parâmetro event_scheduler no servidor flexível do Banco de Dados do Azure para MySQL. Para demonstrar o cenário, considere o exemplo a seguir, uma tabela simples:

mysql> describe tab1;
+-----------+-------------+------+-----+---------+----------------+
| Field     | Type        | Null | Key | Default | Extra          |
+-----------+-------------+------+-----+---------+----------------+
| id        | int(11)     | NO   | PRI | NULL    | auto_increment |
| CreatedAt | timestamp   | YES  |     | NULL    |                |
| CreatedBy | varchar(16) | YES  |     | NULL    |                |
+-----------+-------------+------+-----+---------+----------------+
3 rows in set (0.23 sec)

Para configurar o parâmetro do servidor event_scheduler no servidor flexível do Banco de Dados do Azure para MySQL, execute as seguintes etapas:

  1. No portal do Azure, acesse a instância do servidor flexível do Banco de Dados do Azure para MySQL e, em Configurações, selecione Parâmetros do servidor.

  2. Na folha Parâmetros do servidor, procure event_scheduler, na lista suspensa VALUE, selecione ON e, em seguida, escolha Salvar.

    Observação

    A alteração de configuração do parâmetro de servidor dinâmico será implantada sem uma reinicialização.

  3. Em seguida, para criar um evento, conecte-se à instância do servidor flexível do Banco de Dados do Azure para MySQL e execute o seguinte comando SQL:

    CREATE EVENT test_event_01
ON SCHEDULE EVERY 1 MINUTE
STARTS CURRENT_TIMESTAMP
ENDS CURRENT_TIMESTAMP + INTERVAL 1 HOUR
COMMENT ‘Inserting record into the table tab1 with current timestamp’
DO
INSERT INTO tab1(id,createdAt,createdBy)
VALUES('',NOW(),CURRENT_USER());

  4. Para exibir os Detalhes do Agendador de Eventos, execute a seguinte instrução SQL:

    SHOW EVENTS;

    O seguinte resultado é exibido:

    mysql> show events;
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
| Db  | Name          | Definer     | Time zone | Type      | Execute at | Interval value | Interval field | Starts              | Ends                | Status  | Originator | character_set_client | collation_connection | Database Collation |
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
| db1 | test_event_01 | azureuser@% | SYSTEM    | RECURRING | NULL       | 1              | MINUTE         | 2023-04-05 14:47:04 | 2023-04-05 15:47:04 | ENABLED | 3221153808 | latin1               | latin1_swedish_ci    | latin1_swedish_ci  |
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
1 row in set (0.23 sec)

  5. Após alguns minutos, consulte as linhas da tabela para começar a exibir as linhas inseridas a cada minuto de acordo com o parâmetro event_scheduler configurado:

    mysql> select * from tab1;
+----+---------------------+-------------+
| id | CreatedAt           | CreatedBy   |
+----+---------------------+-------------+
|  1 | 2023-04-05 14:47:04 | azureuser@% |
|  2 | 2023-04-05 14:48:04 | azureuser@% |
|  3 | 2023-04-05 14:49:04 | azureuser@% |
|  4 | 2023-04-05 14:50:04 | azureuser@% |
+----+---------------------+-------------+
4 rows in set (0.23 sec)

  6. Após uma hora, execute uma instrução Select na tabela para exibir o resultado completo dos valores inseridos na tabela a cada minuto durante uma hora, pois o event_scheduler é configurado em nosso caso.

    mysql> select * from tab1;
+----+---------------------+-------------+
| id | CreatedAt           | CreatedBy   |
+----+---------------------+-------------+
|  1 | 2023-04-05 14:47:04 | azureuser@% |
|  2 | 2023-04-05 14:48:04 | azureuser@% |
|  3 | 2023-04-05 14:49:04 | azureuser@% |
|  4 | 2023-04-05 14:50:04 | azureuser@% |
|  5 | 2023-04-05 14:51:04 | azureuser@% |
|  6 | 2023-04-05 14:52:04 | azureuser@% |
..< 50 lines trimmed to compact output >..
| 56 | 2023-04-05 15:42:04 | azureuser@% |
| 57 | 2023-04-05 15:43:04 | azureuser@% |
| 58 | 2023-04-05 15:44:04 | azureuser@% |
| 59 | 2023-04-05 15:45:04 | azureuser@% |
| 60 | 2023-04-05 15:46:04 | azureuser@% |
| 61 | 2023-04-05 15:47:04 | azureuser@% |
+----+---------------------+-------------+
61 rows in set (0.23 sec)

Outros cenários

Você pode configurar um evento com base nos requisitos de seu cenário específico. A seguir, alguns exemplos semelhantes de agendamento de instruções SQL para execução em intervalos de tempo diferentes.

Executar uma instrução SQL agora e repetir uma vez por dia sem fim

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;

Executar uma instrução SQL a cada hora sem fim

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;

Executar uma instrução SQL todos os dias sem fim

CREATE EVENT <event name>
ON SCHEDULE 
EVERY 1 DAY
STARTS str_to_date( date_format(now(), '%Y%m%d 0200'), '%Y%m%d %H%i' ) + INTERVAL 1 DAY
COMMENT 'Comment'
DO
<your statement>;

Limitações

Para servidores com Alta Disponibilidade configurada, quando ocorre failover, é possível que o parâmetro do servidor event_scheduler seja definido como 'OFF'. Se isso ocorrer, quando o failover for concluído, configure o parâmetro para definir o valor como 'ON'.

Parâmetros de servidor não modificáveis

A folha de parâmetros do servidor no portal do Azure mostra os parâmetros de servidor modificáveis e não modificáveis. Os parâmetros do servidor não modificáveis estão esmaecidos. Se você quiser configurar um parâmetro de servidor não modificável no nível da sessão, consulte o artigo portal do Azure ou CLI do Azure para definir o parâmetro no nível de conexão usando init_connect.

Próximas etapas