Diretrizes operacionais para instâncias do MySQL

O contrato de nível de serviço (SLA, na sigla em inglês) do Cloud SQL não inclui interrupções "causadas por fatores fora do controle razoável do Google". Nesta página, são descritas algumas das configurações controladas pelo usuário que podem causar uma interrupção e, assim, excluir uma instância do Cloud SQL de segunda geração para MySQL.

As diretrizes operacionais ainda não estão disponíveis para as instâncias do Cloud SQL para PostgreSQL, mas os mesmos princípios se aplicam às instâncias do PostgreSQL.

Introdução

Com o Cloud SQL, procuramos dar a você o máximo de controle possível sobre as configurações da sua instância. Isso inclui algumas configurações que aumentam o risco de inatividade da instância, dependendo da carga e de outros parâmetros de configuração. Se a instância ficar inativa e o Cloud SQL determinar que ela não estava em conformidade com os limites operacionais, como descrito nesta página, o período de inatividade não será coberto ou não será descontado do SLA do Cloud SQL.

Fornecemos a lista de limites operacionais para informar quais configurações apresentam esses riscos, maneiras de evitar inadvertidamente essas configurações, bem como formas de mitigar os riscos quando a configuração é necessária para seu ambiente de negócios.

Configurações excluídas

As configurações excluídas se enquadram nas categorias abaixo:

  • requisitos gerais de configuração
  • valores de sinalização do banco de dados
  • restrições de recursos

Requisitos gerais de configuração

Somente as instâncias do Cloud SQL configuradas para alta disponibilidade, com pelo menos uma CPU dedicada, são cobertas pelo SLA. Instâncias de núcleo compartilhado e de zona única não são cobertas pelo SLA.

Valores de sinalização do banco de dados

Com Cloud SQL, é possível configurar uma instância usando sinalizações de banco de dados. Dependendo de como são definidas, algumas dessas sinalizações podem comprometer a estabilidade da instância ou a durabilidade dos dados.

A tabela a seguir lista as sinalizações que têm valores que resultam na exclusão do SLA:

Sinalização Descrição Configuração excluída Possível impacto Mitigação
general_log Ativa o registro geral do MySQL. Ativada, com a sinalização log_output definida como TABLE. Reinícios lentos. Defina a sinalização log_output como FILE.
slow_query_log Ativa o registro de consulta lenta do MySQL. Ativada, com a sinalização log_output definida como TABLE. Reinícios lentos. Defina a sinalização log_output como FILE.
max_heap_table_size Determina o tamanho da tabela de memória. Maior que o valor padrão. Interrupção da instância devido ao erro de memória insuficiente (OOM, na sigla em Inglês). Mantenha a configuração padrão.
temp_table_size Determina o tamanho da tabela temporária. Maior que o valor padrão. Interrupção da instância devido ao erro de memória insuficiente (OOM, na sigla em Inglês). Mantenha a configuração padrão ou planeje cuidadosamente sua carga de trabalho para evitar exceder a capacidade da instância.
query_cache_size e query_cache_type Juntas, essas sinalizações determinam o tamanho do cache da consulta. Maior que o valor padrão. Interrupção da instância devido ao erro de memória insuficiente (OOM, na sigla em Inglês). Mantenha a configuração padrão ou planeje cuidadosamente sua carga de trabalho para evitar exceder a capacidade da instância.

Restrições de recursos

É necessário evitar as restrições de recursos abaixo para manter a cobertura do SLA:

Restrição Descrição Detecção Ação corretiva Prevenção
Armazenamento cheio Se a instância ficar sem capacidade de armazenamento e o recurso de aumento automático do armazenamento não estiver ativado, a instância ficará off-line. Essa interrupção não é coberta pelo SLA. Você pode ver a quantidade de armazenamento que sua instância está usando na página "Detalhes da instância" no Console do GCP. Saiba mais.

Para monitorar o uso do armazenamento e receber alertas quando um limite especificado é atingido, configure um alerta do Stackdriver. Saiba mais.

Aumente o tamanho do armazenamento para a instância. Observe que é possível aumentar o tamanho do armazenamento, mas não reduzi-lo. Ative o aumento automático do armazenamento para a instância. Saiba mais.
CPU sobrecarregada Se a utilização da CPU for superior a 98% durante 6 horas, sua instância não está dimensionada adequadamente para a carga de trabalho e, portanto, não está coberta pelo SLA. Você pode ver a porcentagem de CPU disponível que a instância está usando na página "Detalhes da instância" no Console do GCP. Saiba mais.

Para monitorar o uso da CPU e receber alertas quando um limite especificado é atingido, configure um alerta do Stackdriver. Saiba mais.

Aumente o número de CPUs para a instância. Observe que alterar o nível requer o reinício da instância.

Se a instância já tiver o número máximo de CPUs, será necessário dividir o banco de dados em várias instâncias.

Monitore o uso da CPU e aumente o número de CPUs quando necessário. Observe que alterar o nível da instância requer uma reinicialização.
Atraso de replicação muito grande A inatividade de failover causada pelo atraso de replicação superior a 1.200 segundos não é descontado do SLA da instância. Você pode monitorar o atraso de replicação usando a métrica Seconds Behind Master na réplica de failover. Suprima a carga de entrada na mestre ou fragmente o banco de dados. Crie um alerta de atraso de replicação e tome as medidas corretivas necessárias. Saiba mais.
Muitas tabelas de banco de dados Se você tiver 10.000 ou mais tabelas de banco de dados em uma única instância, ela poderá parar de responder ou de executar operações de manutenção. Além disso, a instância não estará coberta pelo SLA. Para ver quantas tabelas há na instância: SELECT COUNT(*) FROM information_schema.tables; Para ver quantas tabelas há em cada banco de dados: SELECT TABLE_SCHEMA,COUNT(*) FROM information_schema.tables group by TABLE_SCHEMA; Reduza o número de tabelas para menos de 10.000.

Se não for possível reduzir imediatamente o número de tabelas, outra maneira de diminuir a probabilidade da sua instância ser afetada pela alta contagem de tabelas é configurar a sinalização innodb_file_per_table como OFF. No entanto, essa configuração não faz com que a instância esteja novamente em conformidade com o SLA.

Se a arquitetura de dados exigir um grande número de tabelas, divida os dados entre várias instâncias.
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Cloud SQL para MySQL