Partilhar 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 considerações e diretrizes para configurar parâmetros de servidor no Banco de Dados do Azure para servidor flexível MySQL.

Nota

Este artigo poderá conter referências ao termo slave (secundário), um termo que a Microsoft já não utiliza. Quando o termo for removido do software, iremos removê-lo deste artigo.

O que são variáveis de servidor?

O mecanismo MySQL fornece muitas variáveis/parâmetros de servidor diferentes que podem ser usados para configurar e ajustar o comportamento do mecanismo. Alguns parâmetros podem ser definidos dinamicamente durante o tempo de execução, 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 servidor MySQL usando o portal do Azure e a CLI do Azure para atender às necessidades da sua carga de trabalho.

Parâmetros configuráveis do servidor

Você pode gerenciar o Banco de Dados do Azure para a configuração flexível do servidor MySQL usando parâmetros de servidor. Os parâmetros do 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 de servidor não modificáveis estão acinzentados.

A lista de parâmetros de servidor suportados está em constante crescimento. Use a guia Parâmetros do servidor no portal do Azure para exibir a lista completa e configurar os valores dos parâmetros do servidor.

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

Nota

  • Se você modificar um parâmetro de servidor estático usando o portal, precisará reiniciar o servidor para que as alterações entrem em vigor. Caso você esteja usando scripts de automação (usando ferramentas como modelos ARM, Terraform, CLI do Azure etc.), seu script deve ter uma provisão para reiniciar o serviço para que as configurações entrem em vigor, mesmo que você esteja 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 o feedback já existir que pode nos ajudar a priorizar.

lower_case_table_names

Para o MySQL versão 5.7, o valor padrão é 1 no Banco de Dados do Azure para o servidor flexível MySQL. É importante notar que, embora seja possível alterar o valor suportado para 2, a reversão de 2 para 1 não é permitida. Entre em contato com nossa equipe de suporte para obter assistência na alteração do valor padrão. Para o MySQL versão 8.0+ lower_case_table_names só pode ser configurado ao inicializar o servidor. Mais informações. É proibido alterar a configuração de lower_case_table_names depois que o servidor é inicializado. Para o MySQL versão 8.0, o valor padrão é 1 no Banco de Dados do Azure para o servidor flexível MySQL. O valor suportado para o MySQL versão 8.0 é 1 e 2 no Banco de Dados do Azure para o servidor flexível MySQL. Entre em contato com nossa equipe de suporte para obter assistência na alteração do valor padrão durante a criação do servidor.

innodb_tmpdir

O parâmetro innodb_tmpdir no Banco de Dados do Azure para o Servidor Flexível MySQL é usado para definir o diretório para arquivos de classificação temporários criados durante operações ALTER TABLE online que são reconstruídas. O valor padrão de innodb_tmpdir é /mnt/temp. Este local corresponde ao SSD de armazenamento temporário, disponível em GiB com cada tamanho de computação do servidor. Este local é ideal para operações que não exigem uma grande quantidade de espaço. Se for necessário mais espaço, pode definir innodb_tmpdir como /app/work/tmpdir. Isso utiliza seu armazenamento, capacidade disponível em seu Banco de Dados do Azure para o Servidor Flexível MySQL. Isso pode ser útil para operações maiores que exigem mais armazenamento temporário. É importante notar que a utilização /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 o são aplicáveis aos parâmetros innodb_temp_tablespaces_dir, tmpdir e slave_load_tmpdir onde o valor /mnt/temp padrão é comum, e o diretório /app/work/tmpdir alternativo está disponível para configurar o innodb_tmpdir aumento do armazenamento temporário, com uma compensação no desempenho com base em requisitos operacionais específicos.

log_bin_trust_function_creators

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

O formato de log binário é sempre ROW e todas as conexões com o servidor SEMPRE usam log binário baseado em linha. Com o log binário baseado em linha, os problemas de segurança não existem e o log binário não pode ser quebrado, para que você possa permitir que log_bin_trust_function_creators permaneça ON com segurança.

Se [log_bin_trust_function_creators] estiver definido como OFF, se você tentar criar gatilhos, poderá obter erros semelhantes aos que você não tem o privilégio SUPER e o log binário está habilitado (você pode querer usar a variável menos segura log_bin_trust_function_creators ).

innodb_buffer_pool_size

Consulte a documentação do MySQL para saber mais sobre esse parâmetro.

Escalão de Preço vCore(s) Tamanho da memória (GiB) Valor padrão (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Burstable (B1s) 1 1 134217728 33554432 134217728
Burstable (B1ms) 1 2 536870912 134217728 536870912
Expansível 2 4 2147483648 134217728 2147483648
Fins Gerais 2 8 5368709120 134217728 5368709120
Fins Gerais 4 16 12884901888 134217728 12884901888
Fins Gerais 8 32 25769803776 134217728 25769803776
Fins Gerais 16 64 51539607552 134217728 51539607552
Fins Gerais 32 128 103079215104 134217728 103079215104
Fins Gerais 48 192 154618822656 134217728 154618822656
Fins Gerais 64 256 206158430208 134217728 206158430208
Crítico para a Empresa 2 16 12884901888 134217728 12884901888
Crítico para a Empresa 4 32 25769803776 134217728 25769803776
Crítico para a Empresa 8 64 51539607552 134217728 51539607552
Crítico para a Empresa 16 128 103079215104 134217728 103079215104
Crítico para a Empresa 32 256 206158430208 134217728 206158430208
Crítico para a Empresa 48 384 309237645312 134217728 309237645312
Crítico para a Empresa 64 504 405874409472 134217728 405874409472

innodb_file_per_table

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

O servidor flexível do Banco de Dados do Azure para MySQL oferece suporte maior, 4 TB, em um único arquivo de dados. Se o tamanho da base de dados for superior a 4 TB, deverá criar a tabela no espaço de tabela innodb_file_per_table. Se tiver um tamanho de tabela superior a 4 TB, deverá utilizar a tabela de partições.

innodb_log_file_size

innodb_log_file_size é o tamanho, em bytes, de cada arquivo de log em um grupo de logs. O tamanho combinado dos ficheiros de registo (innodb_log_file_size * innodb_log_files_in_group) não pode exceder um valor máximo ligeiramente inferior a 512 GB). Um tamanho de arquivo de log maior é melhor para o desempenho, mas tem uma desvantagem de que o tempo de recuperação após uma falha é alto. Você precisa equilibrar o tempo de recuperação no caso raro 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. Você pode configurar innodb_log_size para qualquer um desses valores - 256 MB, 512 MB, 1 GB ou 2 GB para o Banco de Dados do Azure para o servidor flexível MySQL. O parâmetro é estático e requer um reinício.

Nota

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 é determinado pelo tamanho da max_connection memória do servidor.

Escalão de Preço vCore(s) Tamanho da memória (GiB) Valor predefinido Valor mínimo Valor máximo
Burstable (B1s) 1 1 85 10 171
Burstable (B1ms) 1 2 171 10 341
Expansível 2 4 341 10 683
Fins Gerais 2 8 683 10 1365
Fins Gerais 4 16 1365 10 2731
Fins Gerais 8 32 2731 10 5461
Fins Gerais 16 64 5461 10 10923
Fins Gerais 32 128 10923 10 21845
Fins Gerais 48 192 16384 10 32768
Fins Gerais 64 256 21845 10 43691
Crítico para a Empresa 2 16 1365 10 2731
Crítico para a Empresa 4 32 2731 10 5461
Crítico para a Empresa 8 64 5461 10 10923
Crítico para a Empresa 16 128 10923 10 21845
Crítico para a Empresa 32 256 21845 10 43691
Crítico para a Empresa 48 384 32768 10 65536
Crítico para a Empresa 64 504 43008 10 86016

Quando as conexões excedem o limite, você pode receber o seguinte erro:

ERRO 1040 (08004): Demasiadas ligações

Importante

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

Criar novas conexões de cliente com o MySQL leva tempo e, uma vez estabelecidas, essas conexões ocupam recursos de banco de dados, mesmo quando ociosas. A maioria dos aplicativos solicita muitas conexões de curta duração, o que agrava essa situação. O resultado é menos recursos disponíveis para sua carga de trabalho real, levando a uma diminuição do desempenho. Um pool de conexões que diminui conexões ociosas e reutiliza conexões existentes ajuda a evitar isso. Para saber mais sobre como configurar o ProxySQL, visite nossa postagem no blog.

Nota

ProxySQL é uma ferramenta de comunidade de código aberto. Ele é suportado pela Microsoft em uma base de melhor esforço. Para obter suporte à produção com orientação autorizada, você pode avaliar e entrar em contato com o suporte ao produto ProxySQL.

innodb_strict_mode

Se você receber um erro semelhante a "Tamanho da linha muito grande (> 8126)", convém desativar o parâmetro innodb_strict_mode. O parâmetro do servidor innodb_strict_mode não pode ser modificado globalmente no nível do servidor porque se o tamanho dos dados da linha for maior que 8k, os dados serão truncados sem um erro, o que pode levar à perda potencial de dados. Recomendamos modificar o esquema para se ajustar ao limite de tamanho da página.

Este parâmetro pode ser definido em um nível de sessão usando init_connect. Para definir innodb_strict_mode no nível da sessão, consulte o parâmetro de configuração não listado.

Nota

Se você tiver um servidor de réplica de leitura, definir innodb_strict_mode como OFF no nível da sessão em um servidor de origem interromperá a replicação. Sugerimos manter o parâmetro definido como ON se você tiver lido réplicas.

time_zone

Após a implantação inicial, uma instância de servidor flexível do Banco de Dados do Azure para MySQL inclui tabelas do sistema para informações de fuso horário, mas essas tabelas não são preenchidas. As tabelas de fuso horário podem ser preenchidas chamando o mysql.az_load_timezone procedimento armazenado de uma ferramenta como a linha de comando MySQL ou MySQL Workbench. Consulte o portal do Azure ou os artigos da 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 Banco de Dados do Azure para servidor flexível 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 alterações no banco de dados, como operações de criação de tabela ou alterações nos dados da tabela. Ele também contém eventos para declarações que potencialmente poderiam ter feito alterações. O log binário é usado principalmente para duas finalidades, replicação e operações de recuperação de dados. Normalmente, os logs binários são limpos assim que o identificador está livre de serviço, backup ou o conjunto de réplicas. Se houver várias réplicas, os logs binários aguardam que a réplica mais lenta leia as alterações antes de ser limpa. Se quiser persistir os logs binários por mais tempo, você pode configurar o parâmetro binlog_expire_logs_seconds. Se o binlog_expire_logs_seconds estiver 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, então ele esperaria até os segundos configurados antes de limpar. Para o servidor flexível do Banco de Dados do Azure para MySQL, recursos gerenciados, como backup e limpeza de réplica de leitura de arquivos binários, são tratados internamente. Quando você replica a saída de dados do Banco de Dados do Azure para o servidor flexível MySQL, esse parâmetro precisa ser definido como primário para evitar a limpeza de logs binários antes que a réplica leia as alterações do primário. Se você definir o binlog_expire_logs_seconds para um valor mais alto, os logs binários não serão limpos logo o suficiente e podem levar a um aumento no faturamento do armazenamento.

event_scheduler

No servidor flexível do Banco de Dados do Azure para MySQL, o parâmetro de servidor gerencia a criação, o agendamento e a event_schedule execução de eventos, ou seja, tarefas que são executadas de acordo com uma agenda e são executadas por um thread especial do agendador de eventos. Quando o parâmetro é definido como ON, o event_scheduler 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>;

Nota

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

Configurando o parâmetro event_scheduler server

O cenário a seguir ilustra uma maneira de usar o parâmetro no Banco de Dados do Azure para o event_scheduler servidor flexível MySQL. Para demonstrar o cenário, considere o seguinte exemplo, 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 server no Banco de Dados do Azure para o event_scheduler servidor flexível MySQL, execute as seguintes etapas:

  1. No portal do Azure, navegue até sua instância de 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 VALOR, selecione ATIVADO e, em seguida, selecione Salvar.

    Nota

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

  3. Em seguida, para criar um evento, conecte-se à instância de 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;

    É apresentada a seguinte saída:

    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 visualizar as linhas inseridas a cada minuto de acordo com o event_scheduler parâmetro que você configurou:

    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 visualizar o resultado completo dos valores inseridos na tabela a cada minuto durante uma hora, conforme configurado event_scheduler no 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 do seu cenário específico. Seguem-se alguns exemplos semelhantes de agendamento de instruções SQL para execução em intervalos de tempo diferentes.

Execute uma instrução SQL agora e repita 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>;

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

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

Execute 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 event_scheduler parâmetro do servidor seja definido como 'OFF'. Se isso ocorrer, quando o failover estiver 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 de servidor não modificáveis estão acinzentados. Se você quiser configurar um parâmetro de servidor não modificável no nível da sessão, consulte o portal do Azure ou o artigo da CLI do Azure para definir o parâmetro no nível de conexão usando init_connect.

Próximos passos