Descripción general de los índices de réplica de lectura

En este documento, se describen los conceptos y mecanismos para administrar índices secundarios en réplicas de lectura de Cloud SQL en las ediciones Cloud SQL Enterprise y Cloud SQL Enterprise Plus. En MySQL, puedes crear dos tipos principales de índices en una tabla:

  • Índice agrupado: Es el índice principal de una tabla de MySQL que ordena físicamente las filas en el disco. Cuando defines una clave primaria en una tabla, MySQL la usa como el índice agrupado. Una tabla solo puede tener un índice agrupado.

  • Índice secundario: Es un índice adicional en una tabla de MySQL que optimiza el rendimiento de las consultas.

    Si bien una réplica suele ser de solo lectura, puedes crear índices secundarios en tablas para generar informes. Cloud SQL admite dos métodos para crear índices secundarios de réplica:

    • Índices de réplica administrados (recomendado): Cloud SQL almacena las definiciones de índices en la instancia principal y vuelve a compilar los índices secundarios de forma automática después de que la réplica falla o se vuelve a crear. Google recomienda los índices administrados en lugar de los índices autoadministrados para evitar la pérdida de índices y la restauración manual de índices.
    • Índices de réplica autoadministrados: Te permiten agregar y quitar índices secundarios directamente en una réplica, pero estos índices no persisten después de que la réplica falla o se vuelve a crear. Si usas índices autoadministrados, puedes migrar para usar índices de réplica administrados.

Compara los métodos de índice de réplica

En la siguiente tabla, se comparan los índices de réplicas administradas y los índices de réplicas autoadministradas en Cloud SQL:

Función Índices de réplica administrados Índices de réplica autoadministrados
Persistencia en la recreación de réplicas Se vuelve a compilar automáticamente Se descartó (se requiere una reconstrucción manual)
Modelo de configuración Metadatos centralizados en la instancia principal DDL directo en la réplica de lectura de destino
Mecanismo de ejecución Proceso periódico en segundo plano
(aproximadamente cada cinco minutos)		 Ejecución inmediata
Protección contra el retraso de replicación Pausa automáticamente la creación de índices si el retraso de replicación supera los 20 minutos. Ninguna (administrada por el usuario)
Ediciones compatibles Edición Cloud SQL Enterprise y edición Cloud SQL Enterprise Plus Cloud SQL Enterprise y Cloud SQL Enterprise Plus
Versiones de bases de datos compatibles Cloud SQL para MySQL
(versión de mantenimiento R20260726.00_05 o posterior)		 Cloud SQL para MySQL
(todas las versiones compatibles)
Compatibilidad con réplicas de servidores externos No compatible Admitido

Índices de réplica administrados

Para evitar la pérdida de índices después de volver a crear la réplica, Cloud SQL admite índices de réplica administrados. Google recomienda este método de creación y retención de índices. Cloud SQL habilita este método de forma predeterminada.

Los índices de réplica administrados requieren la versión de mantenimiento de Cloud SQL R20260726.00_05 o una posterior.

En las siguientes secciones, se describe cómo Cloud SQL mantiene los índices de réplica, sus beneficios y cómo se comportan durante los eventos del ciclo de vida.

Cómo Cloud SQL mantiene los índices de réplicas administradas

Con este método, defines los índices secundarios de réplica, los agrupas y designas qué réplicas pueden mantener esos grupos de índices. Cloud SQL ejecuta un proceso en segundo plano en la réplica para crear y descartar los índices necesarios de forma automática y mantenerlos con el tiempo. Cuando Cloud SQL crea un índice de réplica administrado, antepone una etiqueta [SIC_X_Y] al comentario del índice, en el que X y Y son números enteros. Esta etiqueta se usa únicamente para la administración interna y no tiene ninguna funcionalidad.

Cloud SQL realiza el mantenimiento de los índices de réplica administrados, como la creación y la eliminación de índices, en lotes. Después de que el proceso de mantenimiento de índices de Cloud SQL selecciona un grupo de acciones CREATE o DROP, crea una entrada de estado PENDING para cada índice secundario. Luego, ejecuta de forma serial cada sentencia del lenguaje de definición de datos (DDL). Una falla en un índice no bloquea la ejecución de los índices posteriores en la cola. Luego, Cloud SQL recoge el siguiente lote después de unos cinco minutos.

Beneficios y casos de uso

Los índices de réplica administrados proporcionan los siguientes beneficios:

  • Retención de índices automatizada: Cuando Cloud SQL vuelve a crear una réplica de lectura (como después de una falla de la instancia), Cloud SQL vuelve a compilar automáticamente los índices secundarios asignados a esa réplica. No es necesario que ejecutes procedimientos almacenados manuales ni que mantengas secuencias de comandos externas de seguimiento de esquemas para restablecer los índices faltantes.
  • Rendimiento de consultas coherente: Con la reconstrucción automática de los índices secundarios después de la recuperación de la réplica, Cloud SQL mantiene la capacidad de procesamiento de las consultas y evita los aumentos repentinos de latencia de las consultas y el uso elevado de CPU que causan las consultas sin indexar.
  • Configuración basada en grupos: Defines los índices secundarios una vez en la instancia principal y los organizas en grupos de réplicas con nombre. Luego, puedes asignar un grupo de índices que contenga cientos de índices a una réplica de lectura configurando una sola marca de base de datos (cloudsql_index_recreate_replica_group). Esto elimina la necesidad de ejecutar procedimientos almacenados individuales en varias réplicas.
  • Asignación selectiva de índices por rol de réplica: Puedes asignar grupos de índices específicamente a réplicas de lectura de informes y estadísticas para acelerar las consultas de lectura, mientras mantienes las réplicas de lectura de recuperación ante desastres (DR) sin indexar y con un esquema idéntico al de la instancia principal. Esto evita la sobrecarga de transacciones de escritura y el retraso de replicación en las instancias de DR.
  • Aislamiento del rendimiento de la instancia principal: Los índices secundarios en las réplicas de lectura optimizan las consultas de lectura y de informes sin consumir almacenamiento ni agregar latencia de transacciones de escritura a la instancia principal.
  • Observabilidad integrada: Los procedimientos almacenados dedicados te permiten supervisar el progreso de la creación de índices, la duración de la ejecución y los registros de errores en la réplica de lectura.
  • Migración y coexistencia sin interrupciones: Los índices de réplica administrados coexisten de forma segura con los índices de réplica autoadministrados existentes en la misma instancia y tabla. Puedes adoptar índices de réplica administrados de forma incremental sin tiempo de inactividad ni interrupciones en las cargas de trabajo de consultas de lectura activas.

Promoción de réplicas

Cloud SQL mantiene los índices de réplica administrados solo en las instancias de réplica de lectura. Si asciendes una réplica de lectura a una instancia principal, Cloud SQL descarta de forma automática los índices secundarios creados como índices de réplica administrados. Puede haber un retraso de aproximadamente cinco minutos antes de que Cloud SQL ejecute la eliminación.

Aunque Cloud SQL descarta los índices secundarios y quita las marcas de base de datos de la instancia ascendida, la instancia principal conserva las definiciones de los índices secundarios y las asignaciones de grupos.

Cambio de recuperación ante desastres (DR)

Durante un cambio de DR, cuando asciendes la réplica de DR a la nueva instancia principal, Cloud SQL descarta de forma automática todos los índices secundarios creados en la réplica de DR. Cloud SQL no crea automáticamente estos índices secundarios en la instancia principal anterior cuando se convierte en una réplica.

Para crear índices secundarios en la instancia principal anterior después del cambio, establece la marca de base de datos cloudsql_index_recreate_replica_group en esa instancia.

Intervalo de replicación

Cloud SQL pausa las operaciones de creación de índices secundarios si el retraso de replicación supera los 20 minutos. Si la creación del índice de la réplica administrada ya está en curso cuando el retraso supera los 20 minutos, Cloud SQL permite que se complete la operación. El retraso de la replicación no pausa las operaciones de eliminación de índices de réplicas administradas.

Limitaciones

Cuando usas índices de réplica administrados, se aplican las siguientes limitaciones:

  • No puedes crear índices de réplicas administradas en réplicas de servidores externos: Cloud SQL no admite la creación de índices de réplicas administradas para réplicas de servidores externos.
  • Máximo de 1,000 índices por grupo de réplicas: Puedes asignar un máximo de 1,000 índices secundarios a un grupo de réplicas.
  • No se admite la actualización ni la modificación de los metadatos de índice: No puedes actualizar ni modificar los metadatos de índice existentes. Para modificar un índice, debes borrar la definición del índice existente y crear una nueva.

Índices de réplica autoadministrados

Los índices de réplica autoadministrados son índices secundarios que creas y descartas directamente en réplicas de lectura individuales de Cloud SQL. Al igual que los índices de réplica administrados, optimizan el rendimiento de las consultas de lectura, como para las cargas de trabajo de informes y estadísticas, sin consumir almacenamiento ni afectar la latencia de escritura en la instancia principal.

Administración de índices autoadministrada

Administras los índices de réplica autoadministrados directamente en la réplica de lectura con los siguientes procedimientos almacenados en el esquema mysql:

  • mysql.addSecondaryIdxOnReplica: Agrega un índice secundario en una tabla especificada en la réplica de lectura. Este procedimiento almacenado es un wrapper para la declaración DDL CREATE INDEX.
  • mysql.dropSecondaryIdxOnReplica: Descarta un índice secundario creado anteriormente de la réplica de lectura. Este procedimiento almacenado es un wrapper para la declaración DDL DROP INDEX.

Para ejecutar estos procedimientos almacenados, se requiere el rol cloudsqlsuperuser.

Cuando creas un índice autoadministrado, Cloud SQL registra metadatos básicos en la tabla mysql.cloudsql_replica_index de la réplica, incluidos el nombre de la base de datos, el nombre de la tabla y el nombre del índice. A diferencia de los índices de réplica administrados, los índices autoadministrados no se registran en la instancia principal y no se mantienen mediante el proceso de replicación en segundo plano de Cloud SQL.

Para obtener detalles de la sintaxis y ejemplos de uso, consulta Índices de réplica autoadministrados.

Beneficios y casos de uso

Los índices de réplica autoadministrados proporcionan los siguientes beneficios para flujos de trabajo específicos:

  • Aislamiento del rendimiento de la instancia principal: Los índices secundarios en las réplicas de lectura optimizan las consultas de lectura y de informes sin consumir almacenamiento ni agregar latencia de transacciones de escritura a la instancia principal.
  • Ejecución inmediata: Las llamadas a procedimientos almacenados se ejecutan de inmediato como sentencias DDL en la réplica, sin esperar el ciclo periódico de mantenimiento en segundo plano (aproximadamente cada cinco minutos) que requieren los índices de réplica administrados.
  • Pruebas y experimentación aisladas: Puedes probar el rendimiento de las consultas y validar las optimizaciones de índices en una réplica de lectura individual antes de crear índices de réplica administrados en un grupo de réplicas.

Limitaciones

Los índices de réplica autoadministrados tienen limitaciones operativas significativas:

  • Falta de persistencia en la recreación de réplicas: si Cloud SQL vuelve a crear una réplica de lectura (como durante la recuperación de la instancia, el mantenimiento o la falla de hardware), todos los índices secundarios autoadministrados en esa réplica se quitan y no se restablecen automáticamente.
  • Sobrecarga de restablecimiento manual: Cloud SQL no puede reconstruir ni volver a compilar los índices. Debes volver a crear los índices de forma manual ejecutando mysql.addSecondaryIdxOnReplica de nuevo.
  • Degradación del rendimiento de las consultas: Las consultas de lectura pueden experimentar una degradación del rendimiento después de volver a crear la réplica hasta que vuelvas a compilar de forma manual los índices faltantes.

Debido a que los índices de réplica administrados se conservan y se vuelven a compilar de forma automática en los eventos de recreación de réplicas, Google recomienda usar índices de réplica administrados para las cargas de trabajo de producción. Si tienes índices autoadministrados existentes, migrarlos a índices de réplica administrados.

Coexistencia de tipos de índices de réplica

Los índices de réplica autoadministrados (creados con mysql.addSecondaryIdxOnReplica) y los índices de réplica administrados pueden coexistir en la misma instancia de réplica de lectura de Cloud SQL y en la misma tabla. Esto te permite adoptar índices de réplicas administradas de forma incremental sin interrumpir las cargas de trabajo de la base de datos existentes.

Cuando uses ambos métodos de administración de índices, ten en cuenta los siguientes comportamientos:

  • Operación independiente: Los índices autoadministrados que creas directamente en la réplica de lectura siguen funcionando junto con los índices de réplica administrados.
  • Evaluación periódica: El proceso de mantenimiento en segundo plano de Cloud SQL evalúa de forma periódica (aproximadamente cada cinco minutos) las definiciones de índices asignadas al grupo de réplicas que asignas a la réplica.
  • Manejo de conflictos de nombres: Si registras una definición de índice de réplica administrada con el mismo nombre que un índice autoadministrado existente en la réplica de lectura, el proceso en segundo plano detecta que ya existe un índice con ese nombre. El proceso registra un estado FAILED en la tabla mysql.cloudsql_replica_idx_status. Este error no afecta el tráfico de la base de datos, no crea bloqueos de tablas ni afecta el índice autoadministrado existente.
  • Resolución automática tras la recreación: Cuando se vuelve a crear la réplica de lectura, Cloud SQL descarta el índice autoadministrado existente como parte de la recreación de la instancia y crea automáticamente el índice de réplica administrado a partir de la definición registrada.

¿Qué sigue?