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

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

O que são parâmetros do 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 a reinicialização do servidor após serem definidos.

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 do servidor no Banco de Dados do Azure para MySQL - Servidor Flexível usando o portal do Azure e Configurar parâmetros do 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 de servidor configuráveis

Você pode gerenciar a configuração de um Servidor Flexível do Banco de Dados do Azure para 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 do 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 visualizar periodicamente a lista completa de parâmetros do servidor e configurar os valores.

Se você modificar um parâmetro estático do servidor usando o portal, será necessário 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 CLI do Azure), seu script deverá ter uma provisão para reiniciar o serviço para que as configurações entrem em vigor, mesmo se você estiver 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 do 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 lower_case_table_names é 1 no Banco de Dados do Azure para MySQL - Servidor Flexível. Embora seja possível alterar o valor suportado para 2, reverter de 2 para 1 não é permitido. 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. Saiba mais. É proibido alterar a lower_case_table_names configuração após a inicialização do servidor.

Os valores suportados para o MySQL versão 8.0 são 1 e 2 no Banco de Dados do Azure para MySQL - Servidor Flexível. O valor padrão é 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. Esse local corresponde ao armazenamento temporário (SSD) e está disponível em gibibytes (GiB) com cada tamanho de computação do servidor. Esse local é ideal para operações que não exigem muito espaço.

Se precisar de mais espaço, você pode definir innodb_tmpdir para /app/work/tmpdir. Essa configuração utiliza a capacidade de armazenamento disponível no seu Servidor Flexível do Banco de Dados do Azure para MySQL. Essa configuração pode ser útil para operações maiores que exigem mais armazenamento temporário.

Tenha em mente que o uso /app/work/tmpdir resulta em desempenho mais lento em comparação ao 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 para innodb_tmpdir são aplicáveis ​​aos parâmetros innodb_temp_tablespaces_dir, tmpdir e slave_load_tmpdir onde:

• O valor padrão /mnt/temp é comum.
• O diretório alternativo /app/work/tmpdir 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 estão sempre habilitados (ou seja, log_bin são definidos como ON). O parâmetro log_bin_trust_function_creators é definido como ON por padrão em servidor flexível.

O formato de registro binário é sempre ROW e as conexões com o servidor sempre usam registro binário baseado em linha. Com o registro binário baseado em linha, não existem problemas de segurança e o registro binário não pode ser interrompido, então você pode permitir com segurança que log_bin_trust_function_creators permaneça como ON.

Se log_bin_trust_function_creators estiver definido OFF como e você tentar criar gatilhos, poderá receber erros semelhantes a: "Você não tem o privilégio SUPER e o registro binário está habilitado (talvez você queira 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, revise 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), no seu Servidor Flexível do Banco de Dados do Azure para MySQL.

innodb_file_per_table

O MySQL armazena a tabela InnoDB em diferentes tablespaces com base na configuração que você forneceu durante a criação da tabela. O tablespace do sistema é a área de armazenamento do dicionário de dados do InnoDB. Um tablespace 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 do servidor innodb_file_per_table controla esse comportamento.

Definir innodb_file_per_tablecomoOFF faz com que o InnoDB crie tabelas no tablespace do sistema. Caso contrário, o InnoDB cria tabelas em tablespaces de arquivo por tabela.

O Banco de Dados do Azure para MySQL - Servidor Flexível suporta no máximo 8 terabytes (TB) em um único arquivo de dados. Se o tamanho do seu banco de dados for maior que 8 TB, você deverá criar a tabela no innodb_file_per_table tablespace. Se você tiver uma única tabela maior que 8 TB, deverá usar a tabela de partição.

innodb_log_file_size (tamanho do arquivo de log do InnoDB)

O valor de 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 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 evento raro de uma falha e maximizar a taxa de transferência durante as operações de pico. Um tamanho de arquivo de log maior 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 uma reinicialização.

máximo de conexões

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

Quando as conexões excedem o limite, você pode receber o seguinte erro: "ERROR 1040 (08004): Muitas conexões."

Criar novas conexões de clientes com o MySQL leva tempo. Depois de estabelecer essas conexões, elas ocupam 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, 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 esse problema. Para uma melhor experiência, recomendamos que você use um pooler de conexões como o ProxySQL para gerenciar conexões com eficiência. Para saber mais sobre como configurar o ProxySQL, consulte essa postagem do blog.

innodb_strict_mode

Se você receber um erro semelhante a "Tamanho da linha muito grande (> 8126)", talvez seja necessário desativar o parâmetro innodb_strict_mode server. 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 8 K, os dados serão truncados sem erro. Esse truncamento pode levar à potencial perda de dados. Recomendamos modificar o esquema para ajustá-lo 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, vejaConfiguração de parâmetros de servidor não modificáveis.

fuso horário

Você pode preencher as tabelas de fuso horário com as informações de fuso horário mais recentes chamando o mysql.az_load_timezone procedimento armazenado de uma ferramenta como a linha de comando MySQL ou o MySQL Workbench e, em seguida, definir os fusos horários globais usando o portal do Azure ou a CLI do Azure. Os fusos horários são carregados automaticamente durante a criação do servidor, removendo a necessidade de os clientes executarem manualmente o mysql.az_load_timezone procedimento armazenado posteriormente para carregar o fuso horário.

binlog_expire_logs_seconds

No Banco de Dados do Azure para MySQL - Servidor Flexível, o parâmetro binlog_expire_logs_seconds especifica o 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 tabelas ou alterações nos dados da tabela. O log binário também contém eventos para instruções que potencialmente podem ter feito alterações. O log binário é usado principalmente para duas finalidades: operações de replicação e recuperação de dados.

Normalmente, os logs binários são excluídos assim que o identificador é liberado 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 você quiser persistir logs binários por mais tempo, você pode configurar o parâmetro binlog_expire_logs_seconds. Se binlog_expire_logs_seconds for definido como o valor padrão de 0, um log binário será excluído assim que o identificador para ele 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 manipula recursos gerenciados, como backup e exclusão de réplicas de leitura de arquivos binários, internamente. Ao replicar 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 em tempo hábil. Esse atraso pode levar a um aumento na fatura de armazenamento.

agendador de eventos

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

Para servidores MySQL versão 5.7, o parâmetro do servidor event_scheduler é automaticamente OFF quando o backup é iniciado e o parâmetro event_scheduler do servidor é ativado novamente após a conclusão bem-sucedida do backup. Na versão 8.0 do MySQL para o Banco de Dados do Azure para MySQL - Servidor Flexível, o event_scheduler permanece inalterado durante 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 Event Scheduler no manual de referência do MySQL:

• Usando o Event Scheduler no MySQL 5.7
• Usando o Event Scheduler no MySQL 8.0

Configurar o parâmetro do servidor event_scheduler

O cenário a seguir ilustra uma maneira de usar o parâmetro event_scheduler 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 parar:

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 event_scheduler server esteja definido como OFF. Se isso ocorrer, quando o failover for concluído, configure o parâmetro para definir o valor como ON.

innodb_ft_user_stopword_table

innodb_ft_user_stopword_table é um parâmetro de servidor no MySQL que especifica o nome da tabela que contém palavras irrelevantes personalizadas para a Pesquisa de Texto Completo do InnoDB. A tabela deve estar no mesmo banco de dados que a tabela indexada em texto completo e sua primeira coluna deve ser do tipo VARCHAR. No Banco de Dados do Azure para MySQL - Servidor Flexível, a configuração padrão de sql_generate_invisible_primary_key=ON faz com que todas as tabelas sem uma chave primária explícita incluam automaticamente uma chave primária invisível. Esse comportamento está em conflito com os requisitos de innodb_ft_user_stopword_table, pois a chave primária invisível se torna a primeira coluna da tabela, impedindo que ela funcione conforme pretendido durante a Pesquisa de Texto Completo. Para resolver esse problema, você deve definir sql_generate_invisible_primary_key=OFF na mesma sessão antes de criar a tabela de stopwords personalizada. Por exemplo:

SET sql_generate_invisible_primary_key = OFF;
CREATE TABLE my_stopword_table (
    stopword VARCHAR(50) NOT NULL
);
INSERT INTO my_stopword_table (stopword) VALUES ('and'), ('or'), ('the');

Isso garante que a tabela de stopwords atenda aos requisitos do MySQL e permite que stopwords personalizadas funcionem corretamente.

Parâmetros de servidor não modificáveis

O painel 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 ​​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 o portal do Azure ou o CLI do Azure.

Variáveis do sistema mysql do Azure

azure_server_name

A azure_server_name variável fornece o nome exato do servidor da instância do Banco de Dados do Azure para MySQL – Servidor Flexível. Essa variável é útil quando aplicativos ou scripts precisam recuperar programaticamente o nome do host do servidor ao qual estão conectados, sem depender de configurações externas e podem ser recuperados executando o comando a seguir dentro do MySQL.

mysql> SHOW GLOBAL VARIABLES LIKE 'azure_server_name';
+-------------------+---------+
| Variable_name     | Value   |
+-------------------+---------+
| azure_server_name | myflex  |
+-------------------+---------+

Observação: O azure_server_name retorna consistentemente o nome do servidor original que você usa para se conectar ao serviço (por exemplo, myflex), tanto para servidores com HA habilitado quanto desabilitado.

nome_do_servidor_lógico

A logical_server_name variável representa o nome do host da instância em que o Banco de Dados do Azure para MySQL – Servidor Flexível está em execução. Essa variável é útil para identificar o host em que o serviço está em execução no momento, auxiliando na solução de problemas e no monitoramento de failover. Você pode recuperar essa variável executando o comando a seguir no MySQL.

mysql> SHOW GLOBAL VARIABLES LIKE 'logical_server_name';
+---------------------+--------------+
| Variable_name       | Value        |
+---------------------+--------------+
| logical_server_name | myflex	     |
+---------------------+--------------+

Observação: para um servidor habilitado para HA, a logical_server_name variável reflete o nome do host da instância que atua como o servidor primário. Para um servidor em que a HA está desabilitada, o valor logical_server_name é igual à azure_server_name variável, pois há apenas uma única instância.

Conteúdo relacionado

• Configurar parâmetros do servidor no Banco de Dados do Azure para MySQL - Servidor Flexível usando o portal do Azure
• Configurar parâmetros do servidor no Banco de Dados do Azure para MySQL - Servidor Flexível usando a CLI do Azure