Visão geral dos índices de réplica de leitura

Neste documento, descrevemos conceitos e mecanismos para gerenciar índices secundários em réplicas de leitura do Cloud SQL nas edições Cloud SQL Enterprise e Cloud SQL Enterprise Plus. No MySQL, é possível criar dois tipos principais de índices em uma tabela:

  • Índice em cluster: o índice principal em uma tabela do MySQL que ordena fisicamente as linhas no disco. Quando você define uma chave primária em uma tabela, o MySQL a usa como o índice em cluster. Uma tabela só pode ter um índice clusterizado.

  • Índice secundário: um índice adicional em uma tabela do MySQL que otimiza o desempenho da consulta.

    Embora uma réplica seja normalmente somente leitura, é possível criar índices secundários em tabelas para fins de relatório. O Cloud SQL é compatível com dois métodos para criar índices secundários de réplica:

    • Índices de réplica gerenciados (recomendado): o Cloud SQL armazena definições de índice na instância principal e recria índices secundários automaticamente após falhas ou recriação de réplicas. O Google recomenda índices gerenciados em vez de índices autogerenciados para evitar a perda de índices e a restauração manual de índices.
    • Índices de réplica autogerenciados: permitem adicionar e remover índices secundários diretamente em uma réplica, mas esses índices não persistem após uma falha ou recriação da réplica. Se você estiver usando índices autogerenciados, poderá migrar para o uso de índices de réplica gerenciados.

Comparar métodos de índice de réplica

A tabela a seguir compara os índices de réplica gerenciados e os índices de réplica autogerenciados no Cloud SQL:

Recurso Índices de réplica gerenciados Índices de réplica autogerenciados
Persistência na recriação de réplicas Recriação automática Descartado (é necessário recriar manualmente)
Modelo de configuração Metadados centralizados na instância principal DDL direto na réplica de leitura de destino
Mecanismo de execução Processo periódico em segundo plano
(aproximadamente a cada cinco minutos)		 Execução imediata
Proteção contra atraso de replicação Pausa automaticamente a criação do índice se o atraso de replicação exceder 20 minutos Nenhum (gerenciado pelo usuário)
Edições compatíveis Edições Cloud SQL Enterprise e Cloud SQL Enterprise Plus Edições Cloud SQL Enterprise e Cloud SQL Enterprise Plus
Versões de banco de dados compatíveis Cloud SQL para MySQL
(versão de manutenção R20260726.00_05 ou mais recente)		 Cloud SQL para MySQL
(todas as versões compatíveis)
Suporte a réplicas de servidores externos Sem suporte Com suporte

Índices de réplica gerenciados

Para evitar a perda de índices após a recriação da réplica, o Cloud SQL é compatível com índices de réplica gerenciados. O Google recomenda esse método de criação e retenção de índices. O Cloud SQL ativa esse método por padrão.

Os índices de réplica gerenciada exigem a versão de manutenção do Cloud SQL R20260726.00_05 ou mais recente.

As seções a seguir descrevem como o Cloud SQL mantém os índices de réplica, os benefícios deles e como eles se comportam durante eventos de ciclo de vida.

Como o Cloud SQL mantém índices de réplica gerenciados

Com esse método, você define índices secundários de réplica, os agrupa e designa quais réplicas podem manter esses grupos de índices. O Cloud SQL executa um processo em segundo plano na réplica para criar e descartar os índices necessários automaticamente e mantê-los ao longo do tempo. Quando o Cloud SQL cria um índice de réplica gerenciada, ele adiciona uma tag [SIC_X_Y] ao comentário do índice, em que X e Y são números inteiros. Essa tag é usada apenas para gerenciamento interno e não tem funcionalidade.

O Cloud SQL realiza a manutenção de índices de réplica gerenciados, como criar e descartar índices, em lotes. Depois que o processo de manutenção de índice do Cloud SQL seleciona um grupo de ações CREATE ou DROP, ele cria uma entrada de status PENDING para cada índice secundário. Em seguida, ele executa em série cada instrução de linguagem de definição de dados (DDL). Uma falha em um índice não bloqueia a execução dos índices subsequentes na fila. Em seguida, o Cloud SQL seleciona o próximo lote após aproximadamente cinco minutos.

Benefícios e casos de uso

Os índices de réplica gerenciados oferecem os seguintes benefícios:

  • Retenção de índice automatizada: quando o Cloud SQL recria uma réplica de leitura (como após uma falha na instância), ele recria automaticamente os índices secundários mapeados para essa réplica. Não é necessário executar procedimentos armazenados manuais nem manter scripts externos de rastreamento de esquema para restaurar índices ausentes.
  • Desempenho de consulta consistente: ao recriar automaticamente índices secundários após a recuperação da réplica, o Cloud SQL mantém a capacidade de processamento de consultas e evita picos de latência de consulta e alta utilização de CPU causados por consultas não indexadas.
  • Configuração baseada em grupo: você define os índices secundários uma vez na instância principal e os organiza em grupos de réplicas nomeados. Em seguida, é possível atribuir um grupo de índices com centenas de índices a uma réplica de leitura definindo uma única flag de banco de dados (cloudsql_index_recreate_replica_group). Isso elimina a necessidade de executar procedimentos armazenados individuais em várias réplicas.
  • Atribuição seletiva de índice por função de réplica: é possível atribuir grupos de índices especificamente a réplicas de leitura de relatórios e análises para acelerar as consultas de leitura, mantendo as réplicas de leitura de recuperação de desastres (DR) não indexadas e idênticas ao esquema da instância principal. Isso evita a sobrecarga de transações de gravação e o atraso de replicação em instâncias de DR.
  • Isolamento de desempenho da instância principal: os índices secundários em réplicas de leitura otimizam as consultas de leitura e de relatórios sem consumir armazenamento nem adicionar latência de transação de gravação à instância principal.
  • Observabilidade integrada: os procedimentos armazenados dedicados permitem monitorar o progresso da criação de índices, a duração da execução e os registros de erros na réplica de leitura.
  • Migração e coexistência sem interrupções: os índices de réplica gerenciados coexistem com segurança com os índices de réplica autogerenciados na mesma instância e tabela. É possível adotar índices de réplica gerenciados de forma incremental sem inatividade ou interrupção das cargas de trabalho de consulta de leitura ativa.

Promoção de réplica

O Cloud SQL mantém índices de réplica gerenciada apenas em instâncias de réplica de leitura. Se você promover uma réplica de leitura para uma instância principal, o Cloud SQL vai descartar automaticamente todos os índices secundários criados como índices de réplica gerenciados. Pode ocorrer um atraso de aproximadamente cinco minutos antes que o Cloud SQL execute a remoção.

Embora o Cloud SQL elimine os índices secundários e remova as flags de banco de dados da instância promovida, a instância principal mantém as definições de índice secundário e os mapeamentos de grupo.

Troca de recuperação de desastres (DR)

Durante uma troca de DR, quando você promove a réplica de DR para a nova instância principal, o Cloud SQL descarta automaticamente todos os índices secundários criados na réplica de DR. O Cloud SQL não cria automaticamente esses índices secundários na instância principal antiga quando ela se torna uma réplica.

Para criar índices secundários na instância principal antiga após a alternância, defina a flag de banco de dados cloudsql_index_recreate_replica_group nessa instância.

Atraso da replicação

O Cloud SQL pausa as operações de criação de índice secundário se o atraso de replicação exceder 20 minutos. Se a criação do índice de réplica gerenciada já estiver em andamento quando o atraso exceder 20 minutos, o Cloud SQL vai permitir que a operação seja concluída. O atraso de replicação não pausa as operações de descarte de índice de réplica gerenciada.

Limitações

Ao usar índices de réplica gerenciados, as seguintes limitações se aplicam:

  • Não é possível criar índices de réplica gerenciada em réplicas de servidores externos: o Cloud SQL não é compatível com a criação de índices de réplica gerenciada para réplicas de servidores externos.
  • Máximo de 1.000 índices por grupo de réplicas: é possível atribuir no máximo 1.000 índices secundários a um grupo de réplicas.
  • Não é possível atualizar ou alterar os metadados do índice: não é possível atualizar ou alterar os metadados do índice atual. Para modificar um índice, exclua a definição atual e crie uma nova.

Índices de réplica autogerenciados

Os índices de réplica autogerenciados são índices secundários que você cria e descarta diretamente em réplicas de leitura individuais do Cloud SQL. Assim como os índices de réplica gerenciada, eles otimizam o desempenho de consultas de leitura, como para cargas de trabalho de relatórios e análises, sem consumir armazenamento ou afetar a latência de gravação na instância principal.

Gerenciamento de índices autogerenciados

Você gerencia índices de réplica autogerenciados diretamente na réplica de leitura usando os seguintes procedimentos armazenados no esquema mysql:

  • mysql.addSecondaryIdxOnReplica: adiciona um índice secundário em uma tabela especificada na réplica de leitura. Esse procedimento armazenado é um wrapper para a instrução DDL CREATE INDEX.
  • mysql.dropSecondaryIdxOnReplica: descarta um índice secundário criado anteriormente da réplica de leitura. Esse procedimento armazenado é um wrapper para a instrução DDL DROP INDEX.

A execução desses procedimentos armazenados requer o papel cloudsqlsuperuser.

Quando você cria um índice autogerenciado, o Cloud SQL registra metadados básicos na tabela mysql.cloudsql_replica_index na réplica, incluindo o nome do banco de dados, da tabela e do índice. Ao contrário dos índices de réplica gerenciados, os índices autogerenciados não são registrados na instância principal e não são mantidos pelo processo de replicação em segundo plano do Cloud SQL.

Para detalhes de sintaxe e exemplos de uso, consulte Índices de réplica autogerenciados.

Benefícios e casos de uso

Os índices de réplica autogerenciados oferecem os seguintes benefícios para fluxos de trabalho específicos:

  • Isolamento de desempenho da instância principal: os índices secundários em réplicas de leitura otimizam as consultas de leitura e de relatórios sem consumir armazenamento nem adicionar latência de transação de gravação à instância principal.
  • Execução imediata: as chamadas de procedimento armazenado são executadas imediatamente como instruções DDL na réplica, sem esperar pelo ciclo periódico de manutenção em segundo plano (aproximadamente a cada cinco minutos) exigido pelos índices de réplica gerenciados.
  • Testes e experimentos isolados: é possível testar o desempenho de consultas e validar otimizações de índice em uma réplica de leitura individual antes de criar índices de réplica gerenciados em um grupo de réplicas.

Limitações

Os índices de réplica autogerenciados têm limitações operacionais significativas:

  • Falta de persistência na recriação de réplicas: se o Cloud SQL recriar uma réplica de leitura (como durante a recuperação da instância, manutenção ou falha de hardware), todos os índices secundários autogerenciados nessa réplica serão descartados e não serão restaurados automaticamente.
  • Sobrecarga de restauração manual: o Cloud SQL não pode reconstruir e recriar os índices. É preciso recriar os índices manualmente executando mysql.addSecondaryIdxOnReplica de novo.
  • Degradação do desempenho da consulta: as consultas de leitura podem ter uma degradação de desempenho após a recriação da réplica até que você recrie manualmente os índices ausentes.

Como os índices de réplica gerenciados persistem e são recriados automaticamente em eventos de recriação de réplicas, o Google recomenda o uso de índices de réplica gerenciados para cargas de trabalho de produção. Se você tiver índices autogerenciados, migre-os para índices de réplica gerenciados.

Coexistência de tipos de índice de réplica

Os índices de réplica autogerenciados (criados usando mysql.addSecondaryIdxOnReplica) e os índices de réplica gerenciados podem coexistir na mesma instância de réplica de leitura do Cloud SQL e na mesma tabela. Isso permite que você adote índices de réplica gerenciada de forma incremental sem interromper as cargas de trabalho do banco de dados.

Ao usar os dois métodos de gerenciamento de índices, considere os seguintes comportamentos:

  • Operação independente: os índices autogerenciados que você cria diretamente na réplica de leitura continuam funcionando com os índices de réplica gerenciados.
  • Avaliação periódica: o processo de manutenção em segundo plano do Cloud SQL avalia periodicamente (aproximadamente a cada cinco minutos) as definições de índice mapeadas para o grupo de réplicas que você atribui à réplica.
  • Tratamento de conflitos de nome: se você registrar uma definição de índice de réplica gerenciada com o mesmo nome de um índice autogerenciado na réplica de leitura, o processo em segundo plano vai detectar que já existe um índice com esse nome. O processo registra um status FAILED na tabela mysql.cloudsql_replica_idx_status. Esse erro não afeta o tráfego do banco de dados, não cria bloqueios de tabela nem afeta o índice autogerenciado atual.
  • Resolução automática na recriação: quando a réplica de leitura é recriada, o Cloud SQL descarta o índice autogerenciado atual como parte da recriação da instância e cria automaticamente o índice de réplica gerenciado com base na definição registrada.

A seguir