Diretrizes operacionais para instâncias do MySQL

O contrato SLA do Cloud SQL não inclui interrupções "causadas por fatores fora do controle razoável do Google". Nesta página, descrevemos algumas configurações controladas por usuário que podem causar uma interrupção e, assim, excluir uma instância do Cloud SQL para MySQL de segunda geração.

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

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 estará protegido) pelo contrato SLA do Cloud SQL.

Fornecemos esta lista de limites operacionais para informar as configurações que apresentam esses riscos, maneiras de evitar o uso inadvertido delas e como 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 de 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 de banco de dados

O Cloud SQL permite configurar sua 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.
tmp_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. Veja o volume de armazenamento que sua instância está usando na página "Detalhes da instância" no Console do Cloud. 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. O tamanho do armazenamento pode ser aumentado, porém, não pode ser reduzido. 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 seis horas, sua instância não estará dimensionada adequadamente para a carga de trabalho e, portanto, não será coberta pelo SLA. Veja a porcentagem de CPU disponível que sua instância está usando na página "Detalhes da instância" no Console do Cloud. 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 a reinicialização da instância.

Se a instância já estiver com o número máximo de CPUs, fragmente 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.
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, minimize a probabilidade de sua instância ser afetada pela contagem alta de tabelas definindo a sinalização innodb_file_per_table como OFF. No entanto, essa configuração não recupera a conformidade da instância com o SLA.

Se a arquitetura de dados exigir muitas tabelas, divida os dados em várias instâncias.