Partilhar via

Parâmetros do servidor no Banco de Dados do Azure para MySQL - Servidor flexível

  • Artigo

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

Nota

Este artigo contém referências ao termo escravo, que a Microsoft não usa mais. Quando o termo for removido do software, iremos removê-lo deste artigo.

O que são parâmetros de servidor?

O mecanismo MySQL fornece muitos parâmetros de servidor (também chamados de variáveis) que você pode usar para configurar e ajustar o comportamento do mecanismo. Alguns parâmetros podem ser definidos dinamicamente durante o tempo de execução. Outros são estáticos e exigem uma reinicialização do servidor depois de defini-los.

No Banco de Dados do Azure para MySQL - Servidor Flexível, você pode alterar o valor de vários parâmetros do servidor MySQL usando Configurar parâmetros de servidor no Banco de Dados do Azure para MySQL - Servidor Flexível usando o portal do Azure e Configurar parâmetros de servidor no Banco de Dados do Azure para MySQL - Servidor Flexível usando a CLI do Azure para corresponder às necessidades da sua carga de trabalho.

Parâmetros configuráveis do servidor

Você pode gerenciar a configuração de um Banco de Dados do Azure para o Servidor Flexível MySQL usando parâmetros de servidor. Os parâmetros do servidor são configurados com os valores padrão e recomendados quando você cria o servidor. O painel Parâmetros do servidor no portal do Azure mostra os parâmetros modificáveis e não modificáveis. Os parâmetros de servidor não modificáveis não estão disponíveis.

A lista de parâmetros de servidor suportados está em constante crescimento. Você pode usar o portal do Azure para exibir periodicamente a lista completa de parâmetros do servidor e configurar os valores.

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. Se você estiver usando scripts de automação (por meio de ferramentas como modelos do Azure Resource Manager, Terraform ou a CLI do Azure), seu script deverá ter uma provisão para reiniciar o serviço para que as configurações entrem em vigor, mesmo que você esteja alterando a configuração como parte da experiência de criação.

Se você quiser modificar um parâmetro de servidor não modificável para seu ambiente, publique uma ideia por meio do feedback da comunidade ou vote se o feedback já existir (o que pode nos ajudar a priorizar).

As seções a seguir descrevem os limites dos parâmetros de servidor comumente atualizados. A camada de computação e o tamanho (vCores) do servidor determinam os limites.

lower_case_table_names

Para o MySQL versão 5.7, o valor padrão de está 1 no Banco de lower_case_table_names Dados do Azure para MySQL - Servidor Flexível. Embora seja possível alterar o valor suportado para 2, a reversão de 2 volta para 1 não é permitida. Para obter assistência na alteração do valor padrão, crie um tíquete de suporte.

Para o MySQL versão 8.0+ você pode configurar lower_case_table_names somente quando estiver inicializando o servidor. Mais informações. É proibido alterar a lower_case_table_names configuração depois que o servidor é inicializado.

Os valores suportados para o MySQL versão 8.0 estão 1 e 2 no Banco de Dados do Azure para MySQL - Servidor Flexível. O valor predefinido é 1. Para obter assistência na alteração do valor padrão durante a criação do servidor, crie um tíquete de suporte.

innodb_tmpdir

Use o parâmetro innodb_tmpdir no Banco de Dados do Azure para MySQL - Servidor Flexível para definir o diretório para arquivos de classificação temporários criados durante operações online ALTER TABLE que são reconstruídas.

O valor padrão de innodb_tmpdir é /mnt/temp. Este local corresponde ao armazenamento temporário (SSD) e está disponível em gibibytes (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 precisar de mais espaço, você pode definir innodb_tmpdir como /app/work/tmpdir. Essa configuração utiliza a capacidade de armazenamento disponível em seu Banco de Dados do Azure para o Servidor Flexível MySQL. Essa configuração pode ser útil para operações maiores que exigem mais armazenamento temporário.

Lembre-se de que o uso /app/work/tmpdir resulta em um desempenho mais lento em comparação com o valor padrão de armazenamento temporário (SSD). /mnt/temp Faça a escolha com base nos requisitos específicos das operações.

As informações fornecidas innodb_tmpdir são aplicáveis aos parâmetros innodb_temp_tablespaces_dir, tmpdir e slave_load_tmpdir quando:

  • O valor /mnt/temp padrão é comum.
  • O diretório /app/work/tmpdir alternativo está disponível para configurar o 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 MySQL - Servidor Flexível, os logs binários são sempre habilitados (ou seja, log_bin estão definidos como ON). O log_bin_trust_function_creators parâmetro é definido como ON por padrão em servidores flexíveis.

O formato de log binário é sempre ROW, e 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 como ON.

Se log_bin_trust_function_creators estiver definido como OFF e você tentar criar gatilhos, você pode obter erros semelhantes a: "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

Para saber mais sobre o innodb_buffer_pool_size parâmetro, consulte a documentação do MySQL.

O tamanho da memória física na tabela a seguir representa a memória de acesso aleatório (RAM) disponível, em gigabytes (GB), em seu Banco de Dados do Azure para o Servidor Flexível MySQL.

Escalão de preço vCores Tamanho da memória física (GB) Valor padrão (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Burstable (B1s) 1 1 134217728 33554432 268435456
Burstable (B1ms) 1 2 536870912 134217728 1073741824
Burstable (B2s) 2 4 2147483648 134217728 2147483648
Burstable (B2ms) 2 8 4294967296 134217728 5368709120
Expansível 4 16 12884901888 134217728 12884901888
Expansível 8 32 25769803776 134217728 25769803776
Expansível 12 48 51539607552 134217728 51539607552
Expansível 16 64 2147483648 134217728 2147483648
Expansível 20 80 64424509440 134217728 64424509440
Fins Gerais 2 8 4294967296 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 20 160 128849018880 134217728 128849018880
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 que você forneceu 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. O parâmetro innodb_file_per_table server controla esse comportamento.

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.

A Base de Dados do Azure para MySQL - Servidor Flexível suporta um máximo de 8 terabytes (TB) num único ficheiro de dados. Se o tamanho do banco de dados for maior que 8 TB, você deverá criar a tabela no espaço de innodb_file_per_table tabela. Se você tiver um único tamanho de tabela maior que 8 TB, deverá usar a tabela de partição.

innodb_log_file_size

O valor de 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 a desvantagem é que o tempo de recuperação após uma falha é alto. Você precisa equilibrar o tempo de recuperação para o raro evento de uma falha versus maximizar a taxa de transferência durante as operações de pico. Um tamanho maior do arquivo de log também pode resultar em tempos de reinicialização mais longos.

Você pode configurar innodb_log_size para 256 megabytes (MB), 512 MB, 1 GB ou 2 GB para o Banco de Dados do Azure para MySQL - Servidor Flexível. O parâmetro é estático e requer um reinício.

Nota

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

max_connections

O tamanho da memória do servidor determina o valor de max_connections. O tamanho da memória física na tabela a seguir representa a RAM disponível, em gigabytes, em seu Banco de Dados do Azure para Servidor Flexível MySQL.

Escalão de preço vCores Tamanho da memória física (GB) Default value Valor mínimo Valor máximo
Burstable (B1s) 1 1 85 10 171
Burstable (B1ms) 1 2 171 10 341
Burstable (B2s) 2 4 341 10 683
Burstable (B2ms) 2 4 683 10 1365
Expansível 4 16 1365 10 2731
Expansível 8 32 2731 10 5461
Expansível 12 48 4097 10 8193
Expansível 16 64 5461 10 10923
Expansível 20 80 6827 10 13653
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 20 160 13653 10 27306
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): Conexões demais."

Criar novas conexões de cliente para o MySQL leva tempo. Depois de estabelecer essas conexões, elas ocupam os recursos do banco de dados, mesmo quando estão 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 esse problema. 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. Para saber mais sobre como configurar o ProxySQL, consulte esta postagem no blog.

Nota

ProxySQL é uma ferramenta de comunidade de código aberto. A Microsoft oferece suporte com base no melhor esforço. Para obter suporte à produção com orientação autorizada, entre 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 innodb_strict_mode parâmetro do servidor. Esse parâmetro 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 erro. Esse truncamento pode levar à perda potencial de dados. Recomendamos modificar o esquema para se ajustar ao limite de tamanho da página.

Você pode definir esse parâmetro no nível da sessão usando init_connect. Para obter mais informações, consulte Definindo parâmetros de servidor não modificáveis.

Nota

Se você tiver um servidor de réplica de leitura, a configuração 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 para ON se você tiver réplicas de leitura.

time_zone

Após a implantação inicial, uma instância do Banco de Dados do Azure para MySQL - Servidor Flexível inclui tabelas do sistema para informações de fuso horário, mas essas tabelas não são preenchidas. Você pode preencher as tabelas de fuso horário chamando o mysql.az_load_timezone procedimento armazenado de uma ferramenta como a linha de comando MySQL ou o MySQL Workbench. Você também pode chamar o procedimento armazenado e definir os fusos horários globais ou de nível de sessão usando o portal do Azure ou a CLI do Azure.

binlog_expire_logs_seconds

No Banco de Dados do Azure para MySQL - Servidor Flexível, o parâmetro especifica o binlog_expire_logs_seconds número de segundos que o serviço aguarda antes de excluir 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. O log binário também contém eventos para instruçõ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 excluídos assim que o identificador está livre do serviço, backup ou 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 serem excluídas.

Se quiser persistir os logs binários por um período maior, você pode configurar o binlog_expire_logs_seconds parâmetro. Se binlog_expire_logs_seconds estiver definido como o valor padrão de , um log binário será excluído 0assim que o identificador for liberado. Se o valor de binlog_expire_logs_seconds for maior que 0, o log binário será excluído após o número de segundos configurado.

O Banco de Dados do Azure para MySQL - Servidor Flexível lida com recursos gerenciados, como backup e exclusão de réplica de leitura de arquivos binários, internamente. Quando você replica os dados do Banco de Dados do Azure para MySQL - Servidor Flexível, esse parâmetro precisa ser definido no primário para evitar a exclusão de logs binários antes que a réplica leia as alterações no primário. Se você definir binlog_expire_logs_seconds para um valor mais alto, os logs binários não serão excluídos tão cedo. Esse atraso pode levar a um aumento no faturamento do armazenamento.

event_scheduler

No Banco de Dados do Azure para MySQL - Servidor Flexível, o parâmetro server gerencia a criação, o agendamento e a event_scheduler execução de eventos. Ou seja, o parâmetro gerencia tarefas que são executadas de acordo com um cronograma por um thread especial do MySQL Event Scheduler. Quando o event_scheduler parâmetro é definido como ON, o thread do Agendador de Eventos é listado como um processo de daemon na saída do SHOW PROCESSLIST.

Para servidores MySQL versão 5.7, o parâmetro event_scheduler do servidor é automaticamente desligado quando o backup é iniciado e o parâmetro event_scheduler do servidor é desativado novamente 'ON' depois que o backup é concluído com êxito. No MySQL versão 8.0 para o Banco de Dados do Azure para MySQL - Servidor Flexível, o event_scheduler permanece inalterado durante os backups. Para garantir operações mais suaves, é recomendável atualizar seus servidores MySQL 5.7 para a versão 8.0 usando uma atualização de versão principal.

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

Para obter mais informações sobre como criar um evento, consulte a seguinte documentação sobre o Agendador de Eventos no manual de referência do MySQL:

Configurar o parâmetro event_scheduler server

O cenário a seguir ilustra uma maneira de usar o event_scheduler parâmetro no Banco de Dados do Azure para MySQL - Servidor Flexível.

Para demonstrar o cenário, considere o seguinte exemplo de 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) |
| ``` |
| To configure the `event_scheduler` server parameter in Azure Database for MySQL - Flexible Server, perform the following steps: |

1. In the Azure portal, go to your Azure Database for MySQL - Flexible Server instance. Under **Settings**, select **Server parameters**.
1. On the **Server parameters** pane, search for `event_scheduler`. In the **VALUE** dropdown list, select **ON**, and then select **Save**.

    > [!NOTE]
    > Deployment of the dynamic configuration change to the server parameter doesn't require a restart.

1. To create an event, connect to the Azure Database for MySQL - Flexible Server instance and run the following SQL command:
    ```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());

    ```
1. To view the Event Scheduler details, run the following SQL statement:
    ```sql

    SHOW EVENTS;

    ```
    The following output appears:
    ```sql

    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) |
    | ``` |

1. After a few minutes, query the rows from the table to begin viewing the rows inserted every minute according to the `event_scheduler` parameter that you configured:

    ```azurecli
    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) |
    | ``` |
| 1. After an hour, run a `select` statement on the table to view the complete result of the values inserted into table every minute for an hour (as `event_scheduler` is configured in this case): |
    ```azurecli

    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) |
    | ``` |

#### Other scenarios

You can set up an event based on the requirements of your specific scenario. A few examples of scheduling SQL statements to run at various time intervals follow.

To run a SQL statement now and repeat one time per day with no end:

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

Para executar uma instrução SQL a cada hora sem fim:

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

Para 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 event_scheduler parâmetro server esteja 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

O painel Parâmetros do servidor no portal do Azure mostra os parâmetros do servidor modificáveis e não modificáveis. Os parâmetros de servidor não modificáveis não estão disponíveis. Você pode configurar um parâmetro de servidor não modificável no nível da sessão usando init_connect no portal do Azure ou na CLI do Azure.

Conteúdos relacionados