Compartir vía

Réplicas de lectura en Azure Database for PostgreSQL: servidor flexible

  • Artículo

SE APLICA A: Azure Database for PostgreSQL con servidor flexible

La característica de réplica de lectura permite replicar datos de una instancia de servidor flexible de Azure Database for PostgreSQL en una réplica de solo lectura. Las réplicas se actualizan de manera asincrónica con la tecnología de replicación física nativa del motor de PostgreSQL. El modo de funcionamiento predeterminado es la transmisión de la replicación mediante espacios de replicación. Cuando sea necesario, se utiliza el trasvase de registros basado en archivos para actualizarse. Puede crear hasta cinco réplicas desde el servidor principal.

Las réplicas son servidores nuevos que se administran de forma similar a las instancias de servidor flexible de Azure Database for PostgreSQL normales. En cada réplica de lectura, se le cobra por el proceso aprovisionado en núcleos virtuales y el almacenamiento aprovisionado en GB/mes.

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. Las réplicas de lectura también se pueden implementar en una región diferente y se pueden promover a un servidor de lectura y escritura si se necesita recuperación ante desastres.

Un escenario habitual es que las cargas de trabajo de análisis e inteligencia empresarial (BI) 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

Las réplicas de lectura están diseñadas principalmente para escenarios en los que la descarga de consultas es beneficiosa y se puede administrar un ligero retraso. Están optimizados para proporcionar actualizaciones casi en tiempo real de la principal para la mayoría de las cargas de trabajo, lo que las convierte en una solución excelente para escenarios de lectura intensiva. Sin embargo, es importante tener en cuenta que no están diseñados para escenarios de replicación sincrónica que requieren una precisión de datos de hasta el minuto. Aunque los datos de la réplica finalmente se vuelven coherentes con la principal, podría haber un retraso, que normalmente oscila entre unos segundos y minutos, y en algunos escenarios de carga de trabajo pesada o latencia alta, este retraso podría extenderse a horas. Normalmente, las réplicas de lectura de la misma región que el servidor principal tienen menos retraso que las réplicas geográficas, ya que estas últimas suelen tratar con la latencia derivada de la distancia geográfica. Si desea más referencias sobre las implicaciones de la replicación geográfica para el rendimiento, consulte el artículo Replicación geográfica. 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.

Nota:

Con la mayoría de las cargas de trabajo, las réplicas de lectura ofrecen actualizaciones casi en tiempo real desde el servidor principal. Sin embargo, con cargas de trabajo principales continuas con numerosas operaciones de escritura, el retraso en la replicación puede seguir creciendo y podría mantenerse al día solamente con la réplica principal. Esto también puede aumentar el uso de almacenamiento en la réplica principal, ya que los archivos WAL solo se eliminan una vez recibidos en la réplica. Si esta situación persiste, al eliminar y volver a crear la réplica de lectura una vez completadas las cargas de trabajo con un uso intensivo de escritura, puede devolver la réplica a un buen estado para el retraso. Las réplicas de lectura asincrónicas no son adecuadas para esas cargas de trabajo con tantas operaciones de escritura. Al evaluar las réplicas de lectura de la aplicación, supervise el retraso en la réplica durante un ciclo completo de carga de trabajo de la aplicación en sus horas punta y fuera de las horas punta para determinar el posible retraso y el RTO/RPO esperado en diversos puntos del ciclo de carga de trabajo.

Creación de una réplica

Un servidor principal para Azure Database for PostgreSQL con servidor flexible se puede implementar en cualquier región que admita el servicio. Puede crear réplicas del servidor principal dentro de la misma región o en diferentes regiones globales de Azure en las que Azure Database for PostgreSQL con servidor flexible está disponible. La capacidad de crear réplicas ahora se extiende a algunas regiones de Azure especiales. Consulte el artículo Replicación geográfica para obtener una lista de regiones especiales en las que puede crear réplicas.

Al iniciar el flujo de trabajo de creación de réplica, se crea una instancia de servidor flexible de Azure Database for PostgreSQL en blanco. El nuevo servidor se rellena con los datos del servidor principal. Para la creación de réplicas en la misma región, se usa un enfoque de instantánea. Por lo tanto, el tiempo de creación es independiente del tamaño de los datos. Las réplicas geográficas se crean utilizando la copia de seguridad de base de la instancia principal, que luego se transmite a través de la red, por lo que el tiempo que dura la creación puede oscilar entre minutos y varias horas, en función del tamaño de la instancia principal.

La réplica solo se considera creada correctamente cuando se cumplen dos condiciones: toda la copia de seguridad de la instancia principal debe copiarse en la réplica y los registros de transacciones deben sincronizarse con más de un retraso de 1 GB.

Para lograr una operación de creación correcta, evite realizar réplicas durante los tiempos de carga transaccional elevada. Por ejemplo, debe evitar la creación de réplicas al migrar desde otros orígenes al servidor flexible de Azure Database for PostgreSQL o durante operaciones de carga masiva pesadas. Si va a migrar datos o cargar grandes cantidades de datos en ese momento, es mejor esperar primero a que finalice esa tarea. Cuando concluya, puede empezar a configurar las réplicas. Una vez finalizada la operación de migración o carga masiva, compruebe si el tamaño del registro de transacciones ha vuelto a su tamaño normal. Normalmente, el tamaño del registro de transacciones debe estar cerca del valor definido en el parámetro de servidor max_wal_size para su instancia. Puede realizar un seguimiento de la superficie de almacenamiento del registro de transacciones mediante la métrica Almacenamiento del registro de transacciones usado, que proporciona información sobre la cantidad de almacenamiento que usa el registro de transacciones. Al supervisar esta métrica, puede asegurarse de que el tamaño del registro de transacciones se encuentre dentro del intervalo esperado y de que se pueda iniciar el proceso de creación de réplicas.

Importante

Las réplicas de lectura se admiten actualmente para los niveles de proceso de servidor de uso general y optimizado para memoria. No se admite el nivel de proceso de servidor ampliable.

Importante

Al realizar operaciones de creación, eliminación y promoción de réplicas, el servidor principal escribirá un estado de actualización. Durante este tiempo, las operaciones de administración del servidor, como modificar parámetros del servidor, cambiar las opciones de alta disponibilidad o agregar o quitar firewalls no estarán disponibles. Es importante señalar que la actualización del estado solo afecta a las operaciones de administración del servidor y no repercute sobre las operaciones del plano de datos. Esto significa que el servidor de bases de datos seguirá siendo totalmente funcional y podrá aceptar conexiones, así como proporcionar tráfico de lectura y escritura.

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

Administración de configuración

Al configurar réplicas de lectura para Azure Database for PostgreSQL: servidor flexible, es esencial conocer las configuraciones de servidor que se pueden ajustar, las heredadas de la instancia principal y las limitaciones relacionadas.

Configuraciones heredadas

Cuando se crea una réplica de lectura, hereda configuraciones de servidor específicas del servidor principal. Estas configuraciones se pueden cambiar durante la creación de la réplica o después de configurarla. Sin embargo, la configuración específica, como la copia de seguridad geográfica, no se replicará en la réplica de lectura.

Configuraciones durante la creación de réplicas

  • Nivel, tamaño de almacenamiento: para la operación "promover al servidor principal", debe ser igual que la configuración de la instancia principal. Para la operación "promover al servidor independiente y quitar de la replicación", puede ser igual o superior a la configuración de la instancia principal.
  • Nivel de rendimiento (IOPS): ajustable.
  • Cifrado de datos: ajustable, incluye pasar de claves administradas por el servicio a claves administradas por el cliente.

Configuraciones posteriores a la creación

  • Reglas de firewall: se pueden agregar, eliminar o modificar.
  • Nivel, tamaño de almacenamiento: para la operación "promover al servidor principal", debe ser igual que la configuración de la instancia principal. Para la operación "promover al servidor independiente y quitar de la replicación", puede ser igual o superior a la configuración de la instancia principal.
  • Nivel de rendimiento (IOPS): ajustable.
  • Método de autenticación: ajustable, las opciones incluyen cambiar de la autenticación de PostgreSQL a Microsoft Entra.
  • Parámetros del servidor: la mayoría son ajustables. Sin embargo, los que afectan al tamaño de memoria compartido deben alinearse con los escenarios de la instancia principal, especialmente para posibles escenarios de "promoción al servidor principal". Para la operación "promover al servidor independiente y quitar de la replicación", estos parámetros deben ser los mismos o superar los del servidor principal.
  • Programación de mantenimiento: ajustable.

Características no admitidas en réplicas de lectura

Algunas funcionalidades están restringidas a los servidores principales y no se pueden configurar en réplicas de lectura. Entre ellas se incluyen las siguientes:

  • Copias de seguridad, incluidas las copias de seguridad geográficas.
  • Alta disponibilidad (HA)

Si la instancia de servidor flexible de Azure Database for PostgreSQL de origen está cifrada con claves administradas por el cliente, vea la documentación para conocer otras consideraciones.

Conexión a una réplica

Al crear una réplica, hereda las reglas de firewall o el punto de conexión de servicio de red virtual del servidor principal. Estas reglas pueden cambiarse durante la creación de réplicas y en cualquier momento posterior.

La réplica hereda su cuenta de administrador del servidor principal. Todas las cuentas de usuario existentes en el servidor principal se replican en las réplicas de lectura. Solo puede conectarse a una réplica de lectura mediante las cuentas de usuario disponibles en el servidor principal.

Hay dos métodos para conectarse a la réplica:

  • Conexión directa a la instancia de réplica: puede conectarse a la réplica mediante su nombre de host y una cuenta de usuario válida, como lo haría en un servidor normal de servidor flexible de Azure Database for PostgreSQL. En un servidor denominado myreplica con el nombre de usuario de administrador myadmin, puede conectarse a la réplica mediante psql:
psql -h myreplica.postgres.database.azure.com -U myadmin postgres

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

Además, para facilitar el proceso de conexión, Azure Portal proporciona cadenas de conexión listas para usar. Las puede encontrar en la página de Conexión. Abarcan tanto variables de libpq como cadenas de conexión adaptadas para las consolas de bash.

  • A través de puntos de conexión virtuales: hay un método de conexión alternativo mediante puntos de conexión virtuales, como se detalla en el artículo Puntos de conexión virtuales. Mediante el uso de puntos de conexión virtuales, puede configurar el punto de conexión de solo lectura para que apunte de forma coherente a la réplica, independientemente del servidor que tenga actualmente el rol de réplica.

Supervisión de la replicación

La característica de réplica de lectura en Azure Database for PostgreSQL (servidor flexible) se basa en el mecanismo de ranuras de replicación. La principal ventaja de las ranuras de replicación es que ajustan automáticamente el número de registros de transacciones (segmentos WAL) requeridos por todos los servidores de réplica. Esto ayuda a evitar que las réplicas no se sincronicen porque evita eliminar segmentos WAL en el principal antes de enviarlos a las réplicas. La desventaja que conlleva este enfoque es el riesgo de quedarse sin espacio en el servidor principal en caso de que la ranura de replicación permanezca inactiva durante un período de tiempo prolongado. En tales situaciones, el servidor principal acumulará archivos WAL que provocarán el aumento incremental del uso del almacenamiento. Cuando el uso del almacenamiento alcanza el 95 % o si la capacidad disponible es inferior a 5 GiB, el servidor cambia automáticamente al modo de solo lectura para evitar los errores asociados con las situaciones de disco lleno.
Por lo tanto, supervisar el retardo de replicación y el estado de las ranuras de replicación es fundamental para las réplicas de lectura.

Se recomienda establecer reglas de alertas para el almacenamiento usado o el porcentaje de almacenamiento, así como para los retrasos de replicación, que detecten cuando se superen determinados umbrales para que usted pueda actuar de forma proactiva, aumentar el tamaño del almacenamiento y eliminar las réplicas de lectura retrasadas. Por ejemplo, puede establecer una alerta si el porcentaje de almacenamiento supera el 80 % de uso y si el retraso de réplica es superior a 5 minutos. La métrica Espacio de registro de transacciones usado muestra si la acumulación de archivos WAL es la razón principal del exceso de uso del almacenamiento.

Azure Database for PostgreSQL: servidor flexible proporciona dos métricas para supervisar la replicación. Las dos métricas son Retraso máximo de replicación física y Retraso de réplica de lectura. Para obtener información sobre cómo ver estas métricas, consulte la sección Supervisión de una réplica del artículo de procedimientos de réplica de lectura.

La métrica Retraso máximo de replicación física muestra el retardo en bytes entre el servidor principal y la réplica con mayor retardo. Esta métrica solo se aplica y está disponible en el servidor principal, y estará disponible únicamente en el caso de que al menos una de las réplicas de lectura esté conectada al servidor principal. La información de retraso también está presente cuando la réplica está en proceso de ponerse al día con el servidor principal, durante la creación de la réplica o cuando la replicación se vuelve inactiva.

La métrica Retraso de réplica de lectura muestra el tiempo transcurrido desde la última transacción reproducida. Por ejemplo, si no se producen transacciones en el servidor principal y la última transacción se reprodujo hace 5 segundos, el retraso de la réplica de lectura mostrará 5 segundos de retraso. Esta métrica solo se aplica y está disponible en las réplicas.

Establezca una alerta que le informe cuando el retardo de la réplica alcance un valor que no sea aceptable para la carga de trabajo.

Para obtener más información, consulte directamente el servidor principal para obtener el retraso de replicación en todas las réplicas.

Nota:

Si se reinicia un servidor principal o una réplica de lectura, el tiempo que tarda en reiniciarse y ponerse al día se reflejará en la métrica de retardo de la réplica.

Estado de replicación

Para supervisar el progreso y el estado de la replicación y la operación de promoción, consulte la columna Estado de replicación en Azure Portal. Esta columna se encuentra en la página de replicación y muestra varios estados que proporcionan información sobre la condición actual de las réplicas de lectura y su vínculo a la instancia principal. Para los usuarios que dependen de la API de Azure Resource Manager, al invocar la API de GetReplica, el estado aparece como ReplicationState en el contenedor de propiedades replica.

Estos son los valores posibles:

Estado de replicación Descripción Orden de promoción Orden de creación de réplica de lectura
Reconfigurando Esperando el inicio del vínculo réplica-principal. Este estado puede prolongarse si la réplica o su región no están disponibles, por ejemplo, debido a un desastre. 1 N/D
Aprovisionamiento La réplica de lectura se está aprovisionando y la replicación entre los dos servidores aún no se ha iniciado. Hasta que se complete el aprovisionamiento, no se puede conectar a la réplica de lectura. N/D 1
Actualizando La configuración del servidor está en preparación después de una acción desencadenada, como la promoción o la creación de réplicas de lectura. 2 2
Puesta al día Se están aplicando los archivos WAL en la réplica. La duración de esta fase durante la promoción depende de la opción de sincronización de datos elegida: planeada o forzada. 3 3
Activo: Estado correcto, que indica que la réplica de lectura se ha conectado correctamente al servidor principal. Si los servidores se detienen pero se han conectado correctamente antes, el estado permanece como activo. 4 4
Interrumpido Estado incorrecto, que indica que se podría haber producido un error en la operación de promoción o que la réplica no se puede conectar al servidor principal por algún motivo. Quite la réplica y vuelva a crearla para resolverlo". N/D N/D

Aprenda a supervisar la replicación.

Consideraciones

En esta sección se resumen las consideraciones sobre la característica de réplica de lectura. Hay que tener en cuenta lo siguiente.

  • Operaciones de encendido y apagado: las operaciones de encendido y apagado, como una acción de inicio y detención, se pueden aplicar al servidor principal y a sus servidores de réplica. Sin embargo, para conservar la integridad del sistema, se debe seguir una secuencia específica. Antes de detener las réplicas de lectura, asegúrese de que el servidor principal se detenga primero. Al iniciar las operaciones de inicio, inicie la acción de inicio en los servidores de réplica antes de iniciar el servidor principal.
  • Si el servidor tiene réplicas de lectura, las réplicas de lectura se deben eliminar primero antes de eliminar el servidor principal.
  • La actualización de la versión principal local en el servidor flexible de Azure Database for PostgreSQL requiere quitar las réplicas de lectura que estén habilitadas actualmente en el servidor. Una vez eliminadas las réplicas, el servidor principal se puede actualizar a la versión principal deseada. Una vez completada la actualización, puede volver a crear las réplicas para reanudar el proceso de replicación.
  • SSD prémium v2: la versión actual no admite la creación de réplicas de lectura para los servidores principales que usen el almacenamiento SSD prémium v2.
  • Restablecimiento de la contraseña de administrador: el restablecimiento de la contraseña de administrador en el servidor de réplica no es compatible actualmente. Además, tampoco se admite la actualización de la contraseña de administrador junto con operación de promoción de réplica en la misma solicitud. Si desea hacerlo, primero debe promover el servidor de réplica y, a continuación, actualizar la contraseña en el servidor recién promocionado por separado.

Nuevas réplicas

Se crea una réplica de lectura como una nueva instancia de servidor flexible de Azure Database for PostgreSQL. Un servidor no puede volver a convertirse en una réplica. No se puede crear una réplica de otra réplica de lectura, es decir, no se admite la replicación en cascada.

Movimiento de recurso

Los usuarios pueden crear réplicas de lectura en un grupo de recursos diferente al principal. Sin embargo, no se admite el traslado de réplicas de lectura a otro grupo de recursos después de su creación. Además, mover réplicas a otra suscripción y mover la réplica principal que tiene réplicas de lectura a otro grupo de recursos o suscripción, no se admite.

Crecimiento automático del almacenamiento

Al configurar réplicas de lectura para una instancia de servidor flexible de Azure Database for PostgreSQL, es esencial asegurarse de que la configuración de crecimiento automático del almacenamiento en las réplicas coincide con la del servidor principal. La característica de crecimiento automático del almacenamiento permite que el almacenamiento de base de datos aumente automáticamente para evitar que se agote el espacio, lo que podría provocar interrupciones en las bases de datos. Aquí se muestra cómo administrar la configuración de crecimiento automático del almacenamiento de forma eficaz:

  • Puede tener habilitado el crecimiento automático del almacenamiento en cualquier réplica, independientemente de la configuración del servidor principal.
  • Si el crecimiento automático del almacenamiento está habilitado en el servidor principal, también debe habilitarse en las réplicas para garantizar la coherencia en los comportamientos de escalado de almacenamiento.
  • Para habilitar el crecimiento automático del almacenamiento en la réplica principal, primero debe habilitarlo en las réplicas. Este orden de operaciones es fundamental para mantener la integridad de la replicación.
  • Por el contrario, si desea deshabilitar el crecimiento automático del almacenamiento, empiece por deshabilitarlo en el servidor principal antes de que las réplicas eviten complicaciones de replicación.

Copia de seguridad y restauración

Al administrar copias de seguridad y restauraciones para la instancia de servidor flexible de Azure Database for PostgreSQL, es esencial tener en cuenta los roles actual y anterior del servidor en diferentes escenarios de promoción. Estos son los puntos clave para recordar:

Promover al servidor principal

  1. No se toman copias de seguridad de réplicas de lectura: nunca se toman copias de seguridad de los servidores de réplica de lectura, independientemente de cuál haya sido su rol anterior.

  2. Conservación de las copias de seguridad anteriores: si un servidor fue anteriormente principal y tiene copias de seguridad realizadas durante ese período, esas copias de seguridad se conservan. Se conservarán hasta el período de retención definido por el usuario.

  3. Restricciones de operación de restauración: aunque existan copias de seguridad anteriores para un servidor que ha pasado a ser una réplica de lectura, las operaciones de restauración están restringidas. Tan solo se puede iniciar una operación de restauración cuando el servidor se promocione de nuevo al rol principal.

Para mayor claridad, la siguiente tabla ilustra estos puntos:

Rol del servidor Copia de seguridad realizada Restauración permitida
Principal Sí Sí
Réplica de lectura No No
Réplica de lectura promocionada a servidor principal Sí Sí

Promover a un servidor independiente y quitar de la replicación

Aunque el servidor es una réplica de lectura, no se realizan copias de seguridad. Sin embargo, una vez que se promueve a un servidor independiente, tanto el servidor promocionado como el servidor principal tienen copias de seguridad realizadas y se permiten restauraciones en ambos.

Redes

Las réplicas de lectura admiten todas las opciones de red compatibles con el servidor flexible de Azure Database for PostgreSQL.

Importante

La comunicación bidireccional entre el servidor principal y las réplicas de lectura es fundamental para la configuración de Azure Database for PostgreSQL: servidor flexible. Debe haber un aprovisionamiento para enviar y recibir tráfico en el puerto de destino 5432 dentro de la subred de la red virtual de Azure.

El requisito anterior no solo facilita el proceso de sincronización, sino que también garantiza el correcto funcionamiento del mecanismo de promoción en el que es posible que las réplicas necesiten comunicarse en orden inverso (desde la réplica al servidor principal), especialmente durante las operaciones de promoción a servidor principal. Además, se deben permitir las conexiones a la cuenta de almacenamiento de Azure que almacena los archivos de registro de escritura anticipada (WAL), para mantener la durabilidad de los datos y permitir procesos de recuperación eficaces.

Para más información sobre cómo configurar el acceso privado (integración de red virtual) para las réplicas de lectura y conocer las implicaciones de la replicación entre regiones de Azure y redes virtuales dentro de un contexto de red privado, consulte la página sobre replicación entre regiones de Azure y redes virtuales con redes privadas.

Mitigación de problemas de ranura de replicación

En ocasiones infrecuentes, un retraso elevado causado por las ranuras de replicación puede provocar un mayor uso de almacenamiento en el servidor principal debido a la acumulación de archivos WAL. Si el uso del almacenamiento alcanza el 95 % o la capacidad disponible cae por debajo de 5 GiB, el servidor cambia automáticamente al modo de solo lectura para evitar errores completos del disco.

Dado que mantener el estado y la funcionalidad del servidor principal es una prioridad, en tales casos límite, se puede quitar la ranura de replicación para asegurarse de que el servidor principal permanece operativo para el tráfico de lectura y escritura. Por lo tanto, la replicación cambia al modo de trasvase de registros basado en archivos, lo que podría dar lugar a un retraso de replicación mayor.

Es esencial supervisar de cerca el uso del almacenamiento y el retraso en la replicación, y tomar las medidas necesarias para mitigar los posibles problemas antes de que se agraven.

Parámetros del servidor

Cuando se crea una réplica de lectura, hereda los parámetros del servidor principal. Esto es para garantizar un punto de partida coherente y confiable. Sin embargo, los cambios que se realicen en los parámetros del servidor principal después de la creación de la réplica de lectura no se replicarán automáticamente. Este comportamiento ofrece la ventaja de que permite ajustar individualmente la réplica de lectura, por ejemplo para mejorar su rendimiento para las operaciones de lectura intensiva, pero sin modificar los parámetros del servidor principal. Aunque esto proporciona flexibilidad y opciones de personalización, también requiere una administración cuidadosa y manual para mantener la coherencia entre la réplica principal y su réplica cuando se requiere la uniformidad de los parámetros del servidor.

Los administradores pueden cambiar los parámetros del servidor en el servidor de réplica de lectura y establecer valores diferentes a los del servidor principal. La única excepción la constituyen los parámetros que podrían afectar a la recuperación de la réplica, mencionada también en la siguiente sección "Escalado": max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes. Para asegurarse de que la recuperación de la réplica de lectura es perfecta y no encuentra limitaciones de memoria compartida, estos parámetros concretos siempre deben establecerse en valores equivalentes o mayores que los configurados en el servidor principal.

Escala

Puede escalar y reducir el proceso de cálculo (núcleos virtuales), cambiar el nivel de servicio de De uso General a Optimizado para memoria (o viceversa), así como escalar el almacenamiento, pero se aplican las siguientes advertencias.

Para el escalado de proceso:

  • El servidor flexible de Azure Database for PostgreSQL requiere que varios parámetros en las réplicas sean mayores o iguales que la configuración del servidor principal para asegurarse de que la réplica no agote la memoria compartida durante la recuperación. Estos son los parámetros afectados: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes.

  • Escalado: En primer lugar, escale el proceso de una réplica y, a continuación, escale la principal.

  • Reducción vertical: En primer lugar, reduzca verticalmente el proceso principal y, a continuación, reduzca verticalmente la réplica.

  • El proceso en la réplica principal siempre debe ser igual o menor que el proceso en la réplica más pequeña.

Para el escalado de almacenamiento:

  • Escalado: Escala primero el almacenamiento de una réplica y luego escala el principal.

  • El tamaño de almacenamiento en la réplica principal debe ser siempre igual o menor que el tamaño de almacenamiento en la réplica más pequeña.

Contenido relacionado