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

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.

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.

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.

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.

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.

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

ERRO 1040 (08004): Muitas conexões

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.

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.

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>;

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

• Como configurar parâmetros de servidor no Portal do Azure
• Como configurar parâmetros de servidor no CLI do Azure