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.

Passos seguintes