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 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 o portal do Azure e 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 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/temppadrão é comum. - O diretório
/app/work/tmpdiralternativo 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 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 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 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.
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:
Configurando 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)
Para configurar o event_scheduler parâmetro de servidor no Banco de Dados do Azure para MySQL - Servidor Flexível, execute as seguintes etapas:
No portal do Azure, vá para sua instância do Banco de Dados do Azure para MySQL - Servidor Flexível. Em Configurações, selecione Parâmetros do servidor.
No painel Parâmetros do servidor, procure
event_scheduler. Na lista pendente VALOR, selecione ATIVADO e, em seguida, selecione Guardar.Nota
A implantação da alteração de configuração dinâmica no parâmetro server não requer uma reinicialização.
Para criar um evento, conecte-se ao Banco de Dados do Azure para MySQL - instância do Servidor Flexível 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());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)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_schedulerparâ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)Após uma hora, execute uma
selectinstrução na tabela para visualizar o resultado completo dos valores inseridos na tabela a cada minuto durante uma hora (comoevent_scheduleré configurado neste 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 de agendamento de instruções SQL para serem executadas em vários intervalos de tempo.
Para 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>;
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.