Compartir a través de


Réplicas de lectura en Azure Cosmos DB for PostgreSQL

SE APLICA A: Azure Cosmos DB for PostgreSQL (con tecnología de la extensión de base de datos de Citus en PostgreSQL)

La característica de réplica de lectura permite replicar datos de un clúster en un clúster de solo lectura. Las réplicas se actualizan de manera asincrónica mediante la tecnología de replicación física de PostgreSQL. Puede ejecutar hasta cinco réplicas desde el servidor principal.

Las réplicas son clústeres nuevos que se administran de forma similar a los clústeres normales. En cada réplica de lectura, se le cobra por el proceso aprovisionado en núcleos virtuales y el almacenamiento aprovisionado en GiB/mes. Los costos de proceso y almacenamiento de los clústeres de réplica son los mismos que para los clústeres normales.

Vea cómo crear y administrar réplicas.

Casos en los que utilizar las réplicas de lectura

La finalidad de la característica de réplica de lectura es ayudar a mejorar el rendimiento y la escala de las cargas de trabajo que conllevan un gran número de operaciones de lectura. Las cargas de trabajo de lectura se pueden aislar en las réplicas, mientras que las cargas de trabajo de escritura se pueden dirigir al servidor principal.

Un caso habitual es que las cargas de trabajo de análisis e inteligencia empresarial utilicen la réplica de lectura como origen de datos para los informes.

Dado que las réplicas son de solo lectura, no reducen directamente las cargas de capacidad de escritura en el servidor principal.

Consideraciones

La característica está pensada para escenarios donde el retraso de replicación es aceptable y para consultas de descarga. No está diseñada para escenarios de replicación sincrónica en los que se espera que los datos de réplica estén actualizados. Habrá un retraso medible entre el servidor principal y la réplica. El retraso puede ser de minutos o incluso horas, según la carga de trabajo y la latencia entre el servidor principal y la réplica. Los datos de la réplica se vuelven finalmente coherentes con los datos del servidor principal. Use esta característica con cargas de trabajo que puedan admitir este retraso.

Creación de una réplica

Cuando se inicia el flujo de trabajo de creación de la réplica, se crea un clúster en blanco. El nuevo clúster se rellena con los datos que estaban en el clúster principal. El tiempo que se tarda en crear la réplica depende de la cantidad de datos en el servidor principal y del tiempo que ha transcurrido desde la última copia de seguridad completa semanal. Puede oscilar desde unos minutos hasta varias horas.

La característica de réplica de lectura usa la replicación física de PostgreSQL (replicación no lógica). El modo predeterminado es la replicación de streaming mediante ranuras de replicación. Cuando es necesario, se usa el trasvase de registros para actualizarse.

Aprenda a crear una réplica de lectura en Azure Portal.

Conexión a una réplica

Al crear una réplica, no hereda las reglas de firewall del clúster principal. Estas reglas se deben configurar de forma independiente para la réplica.

La réplica hereda la cuenta de administrador (citus) del clúster principal. Todas las cuentas de usuario se replican en las réplicas de lectura. Solo se puede conectar a una réplica de lectura a través de las cuentas de usuario disponibles en el servidor principal.

Puede conectarse al nodo de coordinación de la réplica usando su nombre de host y una cuenta de usuario válida, tal y como haría en un clúster normal. Por ejemplo, en un servidor denominado my replica con el nombre de usuario administrador citus, puede conectarse al nodo de coordinación de la réplica usando psql:

psql -h c-myreplica.12345678901234.postgres.cosmos.azure.com -U citus@myreplica -d postgres

Cuando se le solicite, escriba la contraseña de la cuenta de usuario.

Promoción de réplicas al clúster independiente

Puede promover una réplica a un clúster independiente que sea legible y grabable. Una réplica promocionada ya no recibe actualizaciones de su original, y la promoción no se puede deshacer. Las réplicas promocionadas pueden tener réplicas propias.

Hay dos escenarios comunes para promover una réplica:

  1. Recuperación ante desastres Si algo va mal con la principal o con una región completa, puede abrir otro clúster para escrituras como un procedimiento de emergencia.

  2. Migración a otra región. Si desea cambiar a otra región, cree una réplica en la nueva región, espere a que los datos se actualicen y, a continuación, promueva la réplica. Para evitar perder datos durante la promoción, es conveniente que deshabilite las escrituras en el clúster original después de que la réplica se haya actualizado.

    Puede ver hasta qué punto una réplica se ha detectado mediante la métrica replication_lag. Vea Métricas para obtener más información.

Consideraciones

En esta sección se resumen las consideraciones sobre la característica de réplica de lectura.

Nuevas réplicas

Se crea una réplica de lectura como un nuevo clúster. Un clúster existente no se puede convertir en una réplica. No se puede crear una réplica de otra réplica de lectura.

Configuración de réplicas

Las réplicas heredan la configuración de los nodos de proceso, almacenamiento y trabajo de sus nodos primarios. Puede cambiar algunas opciones de configuración de una réplica, pero no todas. Por ejemplo, puede cambiar el proceso, las reglas de firewall para el acceso público y los puntos de conexión privados para el acceso privado. No se puede cambiar el tamaño de almacenamiento ni el número de nodos de trabajo.

Recuerde mantener réplicas con la solidez necesaria para soportar los cambios que llegan desde el grupo principal. Por ejemplo, asegúrese de ampliar la potencia de proceso en las réplicas si hace lo propio en el grupo principal.

La réplica no hereda reglas de firewall ni valores de parámetros del servidor principal, ni cuando se crea ni con posterioridad.

Replicación entre regiones

Las réplicas de lectura se pueden crear en la región del clúster principal o en cualquier otra región compatible con Azure Cosmos DB for PostgreSQL. El límite de cinco réplicas por clúster cuenta para todas las regiones, lo que significa cinco en total, no cinco por región.

Pasos siguientes