Parâmetros do servidor em Base de Dados do Azure para MySQL
APLICA-SE A:
Base de Dados do Azure para MySQL - Servidor Único
Este artigo fornece considerações e diretrizes para configurar parâmetros do servidor em Base de Dados do Azure para MySQL.
Quais são os parâmetros do servidor?
O motor MySQL fornece muitas variáveis e parâmetros diferentes do servidor que utiliza para configurar e afinar o comportamento do motor. Alguns parâmetros podem ser definidos dinamicamente durante o tempo de execução, enquanto outros são estáticos, e requerem um reinício do servidor para se aplicar.
Base de Dados do Azure para MySQL expõe a capacidade de alterar o valor de vários parâmetros do servidor MySQL utilizando o portal do Azure, o Azure CLI e o PowerShell para corresponder às necessidades da sua carga de trabalho.
Parâmetros de servidor configuráveis
A lista de parâmetros suportados do servidor está em constante crescimento. No separador portal do Azure, utilize o separador parâmetros do servidor para visualizar a lista completa e configurar os valores dos parâmetros do servidor.
Consulte as seguintes secções para saber mais sobre os limites de vários parâmetros do servidor geralmente atualizados. Os limites são determinados pelo nível de preços e vCores do servidor.
Piscinas de rosca
O MySQL atribui tradicionalmente um fio para cada ligação ao cliente. À medida que o número de utilizadores simultâneos aumenta, há uma diminuição correspondente no desempenho. Muitos fios ativos podem afetar significativamente o desempenho, devido ao aumento da comutação de contexto, contenção de fios e má localidade para caches de CPU.
As piscinas de roscas, uma característica do lado do servidor e distintas da ligação, maximizam o desempenho introduzindo um conjunto dinâmico de fios de trabalhadores. Utiliza esta função para limitar o número de fios ativos que correm no servidor e minimizar o churn de rosca. Isto ajuda a garantir que uma explosão de ligações não fará com que o servidor fique sem recursos ou memória. As piscinas de roscas são mais eficientes para consultas curtas e cargas de trabalho intensivas da CPU, como cargas de trabalho OLTP.
Para mais informações, consulte a introdução de piscinas de fios em Base de Dados do Azure para MySQL.
Nota
As piscinas de rosca não são suportadas pelo MySQL 5.6.
Configure a piscina de fios
Para ativar uma piscina de fios, atualize o parâmetro do thread_handling servidor para pool-of-threads. Por predefinição, este parâmetro é definido para one-thread-per-connection, o que significa que o MySQL cria um novo fio para cada nova ligação. Este é um parâmetro estático, e requer um reinício do servidor para aplicar.
Também pode configurar o número máximo e mínimo de fios na piscina definindo os seguintes parâmetros do servidor:
thread_pool_max_threads: Este valor garante que não haverá mais do que este número de fios na piscina.thread_pool_min_threads: Este valor define o número de fios que serão reservados mesmo após o fecho das ligações.
Para melhorar as questões de desempenho de consultas curtas na piscina de fios, pode ativar a execução do lote. Em vez de voltar à piscina de rosca imediatamente após a execução de uma consulta, os fios manter-se-ão ativos por um curto período de tempo para aguardar a próxima consulta através desta ligação. Em seguida, o fio executa a consulta rapidamente e, quando esta está completa, o fio aguarda a próxima. Este processo prossegue até que o tempo total gasto exceda um limiar.
Você determina o comportamento da execução do lote usando os seguintes parâmetros do servidor:
thread_pool_batch_wait_timeout: Este valor especifica o tempo que um fio espera que outra consulta processe.thread_pool_batch_max_time: Este valor determina o tempo máximo que um fio repetirá o ciclo de execução de consultas e aguarda a próxima consulta.
Importante
Não ligue a piscina de rosca em produção até testá-la.
log_bin_trust_function_creators
Em Base de Dados do Azure para MySQL, os registos binários estão sempre ativados (o log_bin parâmetro está definido para ON). Se quiser utilizar gatilhos, obtém erro semelhante ao seguinte: Não tem o privilégio SUPER e a exploração madeireira binária está ativada (é melhor utilizar a variável menos segura log_bin_trust_function_creators ).
O formato de registo binário é sempre ROW, e todas as ligações ao servidor utilizam sempre o registo binário baseado na linha. A exploração binária baseada em linha ajuda a manter a segurança, e o registo binário não pode quebrar, para que possa definir log_bin_trust_function_creators com segurança .TRUE
innodb_buffer_pool_size
Reveja a documentação do MySQL para saber mais sobre este parâmetro.
Servidores em armazenamento de finalidade geral v1 (suportando até 4 TB)
| Escalão de preço | vCore(s) | Valor predefinido (bytes) | Valor mínimo (bytes) | Valor máximo (bytes) |
|---|---|---|---|---|
| Básica | 1 | 872415232 | 134217728 | 872415232 |
| Básica | 2 | 2684354560 | 134217728 | 2684354560 |
| Fins Gerais | 2 | 3758096384 | 134217728 | 3758096384 |
| Fins Gerais | 4 | 8053063680 | 134217728 | 8053063680 |
| Fins Gerais | 8 | 16106127360 | 134217728 | 16106127360 |
| Fins Gerais | 16 | 32749125632 | 134217728 | 32749125632 |
| Fins Gerais | 32 | 66035122176 | 134217728 | 66035122176 |
| Fins Gerais | 64 | 132070244352 | 134217728 | 132070244352 |
| Otimizada para Memória | 2 | 7516192768 | 134217728 | 7516192768 |
| Otimizada para Memória | 4 | 16106127360 | 134217728 | 16106127360 |
| Otimizada para Memória | 8 | 32212254720 | 134217728 | 32212254720 |
| Otimizada para Memória | 16 | 65498251264 | 134217728 | 65498251264 |
| Otimizada para Memória | 32 | 132070244352 | 134217728 | 132070244352 |
Servidores em armazenamento de finalidade geral v2 (suportando até 16 TB)
| Escalão de preço | vCore(s) | Valor predefinido (bytes) | Valor mínimo (bytes) | Valor máximo (bytes) |
|---|---|---|---|---|
| Básica | 1 | 872415232 | 134217728 | 872415232 |
| Básica | 2 | 2684354560 | 134217728 | 2684354560 |
| Fins Gerais | 2 | 7516192768 | 134217728 | 7516192768 |
| Fins Gerais | 4 | 16106127360 | 134217728 | 16106127360 |
| Fins Gerais | 8 | 32212254720 | 134217728 | 32212254720 |
| Fins Gerais | 16 | 65498251264 | 134217728 | 65498251264 |
| Fins Gerais | 32 | 132070244352 | 134217728 | 132070244352 |
| Fins Gerais | 64 | 264140488704 | 134217728 | 264140488704 |
| Otimizada para Memória | 2 | 15032385536 | 134217728 | 15032385536 |
| Otimizada para Memória | 4 | 32212254720 | 134217728 | 32212254720 |
| Otimizada para Memória | 8 | 64424509440 | 134217728 | 64424509440 |
| Otimizada para Memória | 16 | 130996502528 | 134217728 | 130996502528 |
| Otimizada para Memória | 32 | 264140488704 | 134217728 | 264140488704 |
innodb_file_per_table
O MySQL armazena a InnoDB tabela em diferentes espaços de mesa, com base na configuração que fornece durante a criação da tabela. O espaço de mesa do sistema é a área de armazenamento do InnoDB dicionário de dados. Um espaço de tabela de ficheiros por tabela contém dados e índices para uma única InnoDB tabela, e é armazenado no sistema de ficheiros no seu próprio ficheiro de dados.
Controla este comportamento utilizando o parâmetro do innodb_file_per_table servidor. Configurar innodb_file_per_table para OFF causas InnoDB para criar tabelas no espaço de tabela do sistema. Caso contrário, InnoDB cria tabelas em espaços de mesa de ficheiros por mesa.
Nota
Só é possível atualizar innodb_file_per_table nos níveis de preços otimizados para fins gerais e memórias no armazenamento v2 de finalidade geral e no armazenamento de finalidade geral v1.
Base de Dados do Azure para MySQL suporta 4 TB (na maior) num único ficheiro de dados no armazenamento de finalidade geral v2. Se o tamanho da sua base de dados for superior a 4 TB, deverá criar a tabela no espaço de mesa innodb_file_per_table . Se tiver um único tamanho de mesa superior a 4 TB, deve utilizar a tabela de divisórias.
join_buffer_size
Reveja a documentação do MySQL para saber mais sobre este parâmetro.
| Escalão de preço | vCore(s) | Valor predefinido (bytes) | Valor mínimo (bytes) | Valor máximo (bytes) |
|---|---|---|---|---|
| Básica | 1 | Não configurável no nível básico | N/D | N/D |
| Básica | 2 | Não configurável no nível básico | N/D | N/D |
| Fins Gerais | 2 | 262144 | 128 | 268435455 |
| Fins Gerais | 4 | 262144 | 128 | 536870912 |
| Fins Gerais | 8 | 262144 | 128 | 1073741824 |
| Fins Gerais | 16 | 262144 | 128 | 2147483648 |
| Fins Gerais | 32 | 262144 | 128 | 4294967295 |
| Fins Gerais | 64 | 262144 | 128 | 4294967295 |
| Otimizada para Memória | 2 | 262144 | 128 | 536870912 |
| Otimizada para Memória | 4 | 262144 | 128 | 1073741824 |
| Otimizada para Memória | 8 | 262144 | 128 | 2147483648 |
| Otimizada para Memória | 16 | 262144 | 128 | 4294967295 |
| Otimizada para Memória | 32 | 262144 | 128 | 4294967295 |
max_connections
| Escalão de preço | vCore(s) | Valor predefinido | Valor mínimo | Valor máximo |
|---|---|---|---|---|
| Básica | 1 | 50 | 10 | 50 |
| Básica | 2 | 100 | 10 | 100 |
| Fins Gerais | 2 | 300 | 10 | 600 |
| Fins Gerais | 4 | 625 | 10 | 1250 |
| Fins Gerais | 8 | 1250 | 10 | 2500 |
| Fins Gerais | 16 | 2500 | 10 | 5000 |
| Fins Gerais | 32 | 5000 | 10 | 10000 |
| Fins Gerais | 64 | 10000 | 10 | 20 000 |
| Otimizada para Memória | 2 | 625 | 10 | 1250 |
| Otimizada para Memória | 4 | 1250 | 10 | 2500 |
| Otimizada para Memória | 8 | 2500 | 10 | 5000 |
| Otimizada para Memória | 16 | 5000 | 10 | 10000 |
| Otimizada para Memória | 32 | 10000 | 10 | 20 000 |
Quando o número de ligações exceder o limite, poderá receber um erro.
Dica
Para gerir as ligações de forma eficiente, é uma boa ideia usar um pooler de conexão, como o ProxySQL. Para saber sobre a configuração do ProxySQL, consulte as réplicas de saldo de carregamento do blog usando ProxySQL em Base de Dados do Azure para MySQL. Note que o ProxySQL é uma ferramenta comunitária open source. É suportado pela Microsoft numa base de melhor esforço.
max_heap_table_size
Reveja a documentação do MySQL para saber mais sobre este parâmetro.
| Escalão de preço | vCore(s) | Valor predefinido (bytes) | Valor mínimo (bytes) | Valor máximo (bytes) |
|---|---|---|---|---|
| Básica | 1 | Não configurável no nível básico | N/D | N/D |
| Básica | 2 | Não configurável no nível básico | N/D | N/D |
| Fins Gerais | 2 | 16777216 | 16384 | 268435455 |
| Fins Gerais | 4 | 16777216 | 16384 | 536870912 |
| Fins Gerais | 8 | 16777216 | 16384 | 1073741824 |
| Fins Gerais | 16 | 16777216 | 16384 | 2147483648 |
| Fins Gerais | 32 | 16777216 | 16384 | 4294967295 |
| Fins Gerais | 64 | 16777216 | 16384 | 4294967295 |
| Otimizada para Memória | 2 | 16777216 | 16384 | 536870912 |
| Otimizada para Memória | 4 | 16777216 | 16384 | 1073741824 |
| Otimizada para Memória | 8 | 16777216 | 16384 | 2147483648 |
| Otimizada para Memória | 16 | 16777216 | 16384 | 4294967295 |
| Otimizada para Memória | 32 | 16777216 | 16384 | 4294967295 |
query_cache_size
A cache de consulta é desligada por defeito. Para ativar a cache de consulta, configuure o query_cache_type parâmetro.
Reveja a documentação do MySQL para saber mais sobre este parâmetro.
Nota
A cache de consulta é depreciada a partir do MySQL 5.7.20 e foi removida no MySQL 8.0.
| Escalão de preço | vCore(s) | Valor predefinido (bytes) | Valor mínimo (bytes) | Valor máximo |
|---|---|---|---|---|
| Básica | 1 | Não configurável no nível básico | N/D | N/D |
| Básica | 2 | Não configurável no nível básico | N/D | N/D |
| Fins Gerais | 2 | 0 | 0 | 16777216 |
| Fins Gerais | 4 | 0 | 0 | 33554432 |
| Fins Gerais | 8 | 0 | 0 | 67108864 |
| Fins Gerais | 16 | 0 | 0 | 134217728 |
| Fins Gerais | 32 | 0 | 0 | 134217728 |
| Fins Gerais | 64 | 0 | 0 | 134217728 |
| Otimizada para Memória | 2 | 0 | 0 | 33554432 |
| Otimizada para Memória | 4 | 0 | 0 | 67108864 |
| Otimizada para Memória | 8 | 0 | 0 | 134217728 |
| Otimizada para Memória | 16 | 0 | 0 | 134217728 |
| Otimizada para Memória | 32 | 0 | 0 | 134217728 |
lower_case_table_names
O lower_case_table_name parâmetro é definido para 1 por padrão, e pode atualizar este parâmetro no MySQL 5.6 e No MySQL 5.7.
Reveja a documentação do MySQL para saber mais sobre este parâmetro.
Nota
No MySQL 8.0, lower_case_table_name está definido para 1 por padrão, e não pode alterá-lo.
innodb_strict_mode
Se receber um erro semelhante, Row size too large (> 8126)considere desligar o innodb_strict_mode parâmetro. Não se pode modificar innodb_strict_mode globalmente ao nível do servidor. Se o tamanho dos dados de linha for superior a 8K, os dados são truncados, sem uma notificação de erro, levando à perda de dados potenciais. É uma boa ideia modificar o esquema para encaixar no limite do tamanho da página.
Pode definir este parâmetro a um nível de sessão, utilizando init_connect. Para definir innodb_strict_mode a um nível de sessão, consulte o parâmetro de definição não listado.
Nota
Se tiver um servidor de réplica de leitura, a definição innodb_strict_mode para OFF o nível de sessão num servidor de origem quebrará a replicação. Sugerimos manter o parâmetro definido para ON se tiver lido réplicas.
sort_buffer_size
Reveja a documentação do MySQL para saber mais sobre este parâmetro.
| Escalão de preço | vCore(s) | Valor predefinido (bytes) | Valor mínimo (bytes) | Valor máximo (bytes) |
|---|---|---|---|---|
| Básica | 1 | Não configurável no nível básico | N/D | N/D |
| Básica | 2 | Não configurável no nível básico | N/D | N/D |
| Fins Gerais | 2 | 524288 | 32768 | 4194304 |
| Fins Gerais | 4 | 524288 | 32768 | 8388608 |
| Fins Gerais | 8 | 524288 | 32768 | 16777216 |
| Fins Gerais | 16 | 524288 | 32768 | 33554432 |
| Fins Gerais | 32 | 524288 | 32768 | 33554432 |
| Fins Gerais | 64 | 524288 | 32768 | 33554432 |
| Otimizada para Memória | 2 | 524288 | 32768 | 8388608 |
| Otimizada para Memória | 4 | 524288 | 32768 | 16777216 |
| Otimizada para Memória | 8 | 524288 | 32768 | 33554432 |
| Otimizada para Memória | 16 | 524288 | 32768 | 33554432 |
| Otimizada para Memória | 32 | 524288 | 32768 | 33554432 |
tmp_table_size
Reveja a documentação do MySQL para saber mais sobre este parâmetro.
| Escalão de preço | vCore(s) | Valor predefinido (bytes) | Valor mínimo (bytes) | Valor máximo (bytes) |
|---|---|---|---|---|
| Básica | 1 | Não configurável no nível básico | N/D | N/D |
| Básica | 2 | Não configurável no nível básico | N/D | N/D |
| Fins Gerais | 2 | 16777216 | 1024 | 67108864 |
| Fins Gerais | 4 | 16777216 | 1024 | 134217728 |
| Fins Gerais | 8 | 16777216 | 1024 | 268435456 |
| Fins Gerais | 16 | 16777216 | 1024 | 536870912 |
| Fins Gerais | 32 | 16777216 | 1024 | 1073741824 |
| Fins Gerais | 64 | 16777216 | 1024 | 1073741824 |
| Otimizada para Memória | 2 | 16777216 | 1024 | 134217728 |
| Otimizada para Memória | 4 | 16777216 | 1024 | 268435456 |
| Otimizada para Memória | 8 | 16777216 | 1024 | 536870912 |
| Otimizada para Memória | 16 | 16777216 | 1024 | 1073741824 |
| Otimizada para Memória | 32 | 16777216 | 1024 | 1073741824 |
Aquecimento da piscina de tampão InnoDB
Depois de reiniciar Base de Dados do Azure para MySQL, as páginas de dados que residem no disco são carregadas, uma vez que as tabelas são consultadas. Isto leva a um aumento da latência e de um desempenho mais lento para a primeira execução das consultas. Para cargas de trabalho sensíveis à latência, pode achar este desempenho mais lento inaceitável.
Pode utilizar InnoDB o aquecimento da piscina tampão para encurtar o período de aquecimento. Este processo recarrega páginas de disco que estavam na piscina tampão antes do reinício, em vez de esperar que as operações DML ou SELECT tenham acesso às linhas correspondentes. Para obter mais informações, consulte os parâmetros do servidor do buffer InnoDB.
Note que o melhor desempenho vem à custa de tempo de arranque mais longo para o servidor. Quando ativa este parâmetro, espera-se que o início do servidor e o tempo de reinicie aumentem, dependendo do IOPS previsto no servidor. É uma boa ideia testar e monitorizar o tempo de reinício, para garantir que o desempenho do arranque ou reinicie é aceitável, uma vez que o servidor não está disponível durante esse período. Não utilize este parâmetro quando o IOPS forvisionado for inferior a 1000 IOPS (por outras palavras, quando o armazenamento forvisionado for inferior a 335 GB).
Para salvar o estado do conjunto tampão no fecho do servidor, desaceia o parâmetro innodb_buffer_pool_dump_at_shutdown do servidor para ON. Da mesma forma, desacei o parâmetro innodb_buffer_pool_load_at_startup do servidor para ON restaurar o estado do conjunto tampão no arranque do servidor. Pode controlar o impacto no arranque ou reiniciar reduzindo e afinando o valor do parâmetro innodb_buffer_pool_dump_pctdo servidor . Por predefinição, este parâmetro é definido para 25.
Nota
InnoDB os parâmetros de aquecimento da piscina tampão só são suportados em servidores de armazenamento de finalidade geral com até 16 armazenamento de TB. Para mais informações, consulte Base de Dados do Azure para MySQL opções de armazenamento.
time_zone
Após a implementação inicial, um servidor em execução Base de Dados do Azure para MySQL inclui tabelas de sistemas para informações de fuso horário, mas estas tabelas não são povoadas. Pode povoar as tabelas chamando o mysql.az_load_timezone procedimento armazenado a partir de ferramentas como a linha de comando MySQL ou a bancada MySQL Workbench. Para obter informações sobre como ligar para os procedimentos armazenados e definir os fusos horários globais ou ao nível da sessão, consulte Trabalhar com o parâmetro do fuso horário (portal do Azure) ou trabalhar com o parâmetro do fuso horário (Azure CLI).
binlog_expire_logs_seconds
Em Base de Dados do Azure para MySQL, este parâmetro especifica o número de segundos que o serviço aguarda antes de purgar o ficheiro de registo binário.
O registo binário contém eventos que descrevem alterações na base de dados, tais como operações de criação de quadros ou alterações aos dados do quadro. Também contém eventos para declarações que podem potencialmente fazer alterações. O registo binário é utilizado principalmente para duas finalidades, operações de replicação e recuperação de dados.
Normalmente, os registos binários são purgados assim que a pega estiver livre de serviço, cópia de segurança ou do conjunto de réplicas. Em caso de múltiplas réplicas, os registos binários aguardam que a réplica mais lenta leia as alterações antes de ser purgada. Se quiser que os registos binários persistam mais tempo, pode configurar o parâmetro binlog_expire_logs_seconds. Se definir binlog_expire_logs_seconds para 0- que é o valor padrão, ele purga assim que a pega para o log binário é libertada. Se definir binlog_expire_logs_seconds para mais de 0, então o tronco binário só purga após esse período de tempo.
Para Base de Dados do Azure para MySQL, funcionalidades geridas como cópia de segurança e leitura de réplicas de ficheiros binários são tratadas internamente. Quando replicar os dados do serviço Base de Dados do Azure para MySQL, deve definir este parâmetro nas primárias para evitar a purga de registos binários antes que a réplica leia a partir das alterações a partir do primário. Se definir o binlog_expire_logs_seconds valor mais alto, então os registos binários não serão purgados em breve. Isto pode levar a um aumento da faturação de armazenamento.
Parâmetros de servidor não configuráveis
Os seguintes parâmetros do servidor não são configuráveis no serviço:
| Parâmetro | Valor fixo |
|---|---|
innodb_file_per_table no nível básico |
OFF |
innodb_flush_log_at_trx_commit |
1 |
sync_binlog |
1 |
innodb_log_file_size |
256 MB |
innodb_log_files_in_group |
2 |
Outras variáveis não listadas aqui são definidas para os valores padrão do MySQL. Consulte os docs MySQL para versões 8.0, 5.7 e 5.6.