Recuperación rápida después de una conmutación por error con la administración de caché del clúster para Aurora PostgreSQL - Amazon Aurora

Recuperación rápida después de una conmutación por error con la administración de caché del clúster para Aurora PostgreSQL

Para la recuperación rápida de la instancia de base de datos del escritor en sus clústeres de Aurora PostgreSQL si se produce una conmutación por error, utilice la administración de caché del clúster para Amazon Aurora PostgreSQL. La administración de caché del clúster garantiza que el rendimiento de la aplicación se mantiene si se produce una conmutación por error.

En una situación de conmutación por error típica, puede que observe una degradación del rendimiento temporal, pero acusada, después de la conmutación por error. Esta degradación se produce porque cuando se inicia la instancia de base de datos de conmutación por error, la caché del búfer está vacía. Una caché vacía se conoce también como caché fría. Una caché fría degrada el rendimiento porque la instancia de base de datos tiene que realizar la lectura a partir del disco inferior en lugar de aprovechar los valores almacenados en la caché del búfer.

Con la administración de la caché del clúster, establecerá una instancia de base de datos del lector específica como destino de conmutación por error. La administración de la caché del clúster garantiza que los datos en la caché del lector designada se mantiene sincronizada con los datos en la caché de la instancia de la base de datos del escritor. La caché del lector designado con los valores precompletados se conoce como caché templada. Si se produce una conmutación por error, el lector designado utiliza valores en su caché templada de inmediato cuando se promociona en la nueva instancia de base de datos del escritor. Este enfoque proporciona a su aplicación un rendimiento de recuperación mucho mejor.

La administración de caché de clústeres requiere que la instancia de lector designada tenga el mismo tipo y tamaño de clase de instancia (db.r5.2xlarge o db.r5.xlarge, por ejemplo) que el escritor. Tenga esto en cuenta cuando cree sus clústeres de base de datos Aurora PostgreSQL para que el clúster pueda recuperarse durante una conmutación por error. Para obtener una lista de los tipos y tamaños de clase de instancia, consulte Especificaciones de hardware para clases de instancia de base de datos para Aurora.

nota

La administración de caché de clúster no es compatible con los clústeres de base de datos Aurora PostgreSQL que forman parte de bases de datos globales de Aurora. Se recomienda no ejecutar ninguna carga de trabajo en el lector de nivel 0 designado.

Configuración de la administración de la caché del clúster

Para configurar la administración de caché de clúster, realice los siguientes procesos en orden.

nota

Deje que transcurra al menos un minuto después de completar estos pasos para que la gestión de la caché del clúster esté totalmente operativa.

Habilitación de la administración de la caché del clúster

Para habilitar la administración de caché de clúster, siga los pasos que se describen a continuación.

Para habilitar la administración de la caché del clúster, realice el siguiente procedimiento:
  1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

  2. En el panel de navegación, seleccione Parameter groups (Grupos de parámetros).

  3. En la lista, elija el grupo de parámetros para el clúster de base de datos Aurora PostgreSQL.

    El clúster de base de datos debe utilizar un grupo de parámetros distinto al predeterminado, ya que no puede cambiar los valores en un grupo de parámetros predeterminado.

  4. En Parameter group actions (Acciones de grupos de parámetros), seleccione Edit (Editar).

  5. Establezca el valor del parámetro del clúster de apg_ccm_enabled en 1.

  6. Elija Guardar cambios.

Para habilitar la administración de la caché del clúster para el clúster de base de datos de Aurora PostgreSQL, utilice el comando de la AWS CLI modify-db-cluster-parameter-group con los siguientes parámetros necesarios:

  • --db-cluster-parameter-group-name

  • --parameters

ejemplo

Para Linux, macOS, o Unix:

aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name my-db-cluster-parameter-group \ --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"

En Windows:

aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name my-db-cluster-parameter-group ^ --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"

Establecimiento de la prioridad de la capa de promoción para la instancia de base de datos del escritor

Para la administración de caché de clúster, asegúrese de que la prioridad de promoción sea tier-0 para la instancia de base de datos del escritor del clúster de base de datos de Aurora PostgreSQL. La prioridad de la capa de promoción es un valor que especifica el orden en el que se promociona el lector de Aurora en la instancia de base de datos del escritor después de un error. Los valores válidos con de 0 a 15, donde 0 es la primera prioridad y 15 la última. Para obtener más información sobre la capa de promoción, consulte Tolerancia a errores para un clúster de base de datos de Aurora.

Para establecer la prioridad de la promoción para la instancia de base de datos del escritor en tier-0, realice el siguiente procedimiento
  1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

  2. En el panel de navegación, seleccione Databases (Bases de datos).

  3. Elija la instancia de base de datos del escritor del clúster de base de datos de Aurora PostgreSQL.

  4. Elija Modify (Modificar). Aparece la página Modify DB Instance.

  5. En el panel Configuración adicional elija el nivel 0 para Failover priority (Prioridad de conmutación por error).

  6. Elija Continue (Continuar) y consulte el resumen de las modificaciones.

  7. Para aplicar los cambios inmediatamente después de guardarlos, elija Apply immediately (Aplicar inmediatamente).

  8. Seleccione Modify DB Instance (Modificar instancia de base de datos) para guardar los cambios.

Para configurar la prioridad de la capa de promoción en 0 para la instancia de base de datos del escritor mediante la AWS CLI, invoque el comando modify-db-instance con los siguientes parámetros necesarios:

  • --db-instance-identifier

  • --promotion-tier

  • --apply-immediately

ejemplo

Para Linux, macOS, o Unix:

aws rds modify-db-instance \ --db-instance-identifier writer-db-instance \ --promotion-tier 0 \ --apply-immediately

En Windows:

aws rds modify-db-instance ^ --db-instance-identifier writer-db-instance ^ ---promotion-tier 0 ^ --apply-immediately

Establecimiento de la prioridad de la capa de promoción para una instancia de base de datos del lector

Debe configurar solamente una instancia de base de datos del lector para la administración de la caché del clúster. Para ello, elija un lector del clúster de Aurora PostgreSQL que sea del mismo tipo y tamaño de instancia que la instancia de base de datos del escritor. Por ejemplo, si el escritor utiliza db.r5.xlarge, elija un lector que utilice el mismo tipo y tamaño de clase de instancia. A continuación, establezca su prioridad de la capa de promoción en 0.

La prioridad de la capa de promoción es un valor que especifica el orden en el que se promociona el lector de Aurora en la instancia de base de datos del escritor después de un error. Los valores válidos con de 0 a 15, donde 0 es la primera prioridad y 15 la última.

Para establecer la prioridad de la promoción para la instancia de base de datos del escritor en tier-0, realice el siguiente procedimiento:
  1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

  2. En el panel de navegación, seleccione Databases (Bases de datos).

  3. Elija una instancia de base de datos del lector del clúster de base de datos de Aurora PostgreSQL que sea la misma clase de instancia que la instancia de base de datos del escritor.

  4. Elija Modify (Modificar). Aparece la página Modify DB Instance.

  5. En el panel Configuración adicional elija el nivel 0 para Failover priority (Prioridad de conmutación por error).

  6. Elija Continue (Continuar) y consulte el resumen de las modificaciones.

  7. Para aplicar los cambios inmediatamente después de guardarlos, elija Apply immediately (Aplicar inmediatamente).

  8. Seleccione Modify DB Instance (Modificar instancia de base de datos) para guardar los cambios.

Para configurar la prioridad de la capa de promoción en 0 para la instancia de base de datos del lector mediante la AWS CLI, invoque el comando modify-db-instance con los siguientes parámetros necesarios:

  • --db-instance-identifier

  • --promotion-tier

  • --apply-immediately

ejemplo

Para Linux, macOS, o Unix:

aws rds modify-db-instance \ --db-instance-identifier reader-db-instance \ --promotion-tier 0 \ --apply-immediately

En Windows:

aws rds modify-db-instance ^ --db-instance-identifier reader-db-instance ^ ---promotion-tier 0 ^ --apply-immediately

Monitoreo de la caché del búfer

Después de configurar la gestión de la caché del clúster, podrá monitorizar el estado de la sincronización entre la caché del búfer de la instancia de base de datos del escritor y la caché del búfer en caliente del lector designado. Para examinar el contenido de la caché del búfer en la instancia de base de datos del escritor y la instancia de base de datos del lector designada, utilice el módulo pg_buffercache de PostgreSQL. Para obtener más información, consulte la documentación de PostgreSQL sobre pg_buffercache.

Uso de la función aurora_ccm_status

La administración de la caché del clúster también proporciona la función aurora_ccm_status. Utilice la función aurora_ccm_status en la instancia de base de datos del escritor para obtener la siguiente información sobre el progreso del calentamiento de la caché en el lector designado:

  • buffers_sent_last_minute: la cantidad de búferes enviados al lector designado en el último minuto.

  • buffers_found_last_minute: el número de búferes de acceso frecuente identificados durante el último minuto.

  • buffers_sent_last_scan: la cantidad de búferes enviados al lector designado durante el último análisis completo de la caché del búfer.

  • buffers_found_last_scan: la cantidad de búferes identificados como de acceso frecuente y que tienen que enviarse durante el último análisis completo de la caché del búfer. Los búferes ya almacenados en la caché en el lector designado no se envían.

  • buffers_sent_current_scan: la cantidad de búferes enviados hasta el momento durante el análisis actual.

  • buffers_found_current_scan: la cantidad de búferes identificados como de acceso frecuente en el análisis actual.

  • current_scan_progress: la cantidad de búferes visitados hasta el momento durante el análisis actual.

En el siguiente ejemplo se muestra cómo utilizar la función aurora_ccm_status para convertir algunos de sus resultados en una tasa templada y un porcentaje templado.

SELECT buffers_sent_last_minute*8/60 AS warm_rate_kbps, 100*(1.0-buffers_sent_last_scan::float/buffers_found_last_scan) AS warm_percent FROM aurora_ccm_status();

Solución de problemas de configuración de CCM

Al habilitar el parámetro de clúster apg_ccm_enabled, la administración de la caché del clúster se activa automáticamente en el nivel de instancia en la instancia de base de datos de escritura y en una instancia de base de datos de lectura en el clúster de base de datos de Aurora PostgreSQL. La instancia de escritura y la de lectura deben usar el mismo tipo y tamaño de clase de instancia. La prioridad de su nivel de promoción está establecida en 0. Las demás instancias de lectura del clúster de base de datos deben tener un nivel de promoción distinto de cero y la administración de la caché del clúster está deshabilitada para esas instancias.

Los siguientes motivos pueden provocar problemas en la configuración e inhabilitar la administración de la caché del clúster:

  • Cuando no hay una instancia de base de datos de lectura única configurada para el nivel de promoción 0.

  • Cuando la instancia de base de datos del escritor no está configurada en el nivel de promoción 0.

  • Cuando hay más de un lector, las instancias de base de datos configuradas en el nivel de promoción 0.

  • Cuando las instancias de base de datos del escritor y de un lector con el nivel de promoción 0 no tienen el mismo tamaño de instancia.