Alta disponibilidad para postgresql

Soy nuevo en la base de datos PostgreSQL. Recientemente, nuestro desarrollador necesitaba hacer algunas actualizaciones en nuestros sistemas.

Debido a eso, estamos planeando implementar algún método para implementar la conmutación por error de la base de datos.

Basado en mi lectura del postgresql wiki aquí , estamos tratando de implementar ya sea en espera activa o en espera activa. Entonces mis preguntas son:

1. ¿Cuáles son las principales diferencias entre ellos?
2. ¿Cuál es mejor?
3. ¿Hay algún otro método que podamos tener en cuenta para lograr una alta disponibilidad en nuestras bases de datos de Postgres?

1a. El modo de espera en caliente es una copia de seguridad incremental "en vivo" alimentada con bloques completos de cambios (segmentos wal) de 16 mb cada uno, que se envían al nodo en espera una vez que se completan. No puede consultar un nodo de espera en caliente. 16 mb de cambios (por defecto) pueden significar muchas transacciones, si el maestro falla, se perderán.

1b. Hot Standby . (también una copia de seguridad incremental "en vivo"). Se envían pequeños cambios al esclavo (registros wal, que son pequeñas partes de un segmento wal). Puede consultar (solo lectura) el nodo de espera activa. La ventana para transacciones perdidas en caso de que falle el maestro es muy pequeña. Hay nodos síncronos y asíncronos de espera activa, un nodo síncrono obligará al maestro a esperar que confirme la aplicación de los cambios y luego el maestro confirmará la transacción. En la replicación asincrónica, el maestro envía los registros wal y no espera la confirmación . El primero requiere un enlace muy confiable y rápido entre el maestro y el esclavo, también agrega sobrecarga al maestro pero no garantiza la pérdida de datos.

Con respecto a las copias de seguridad incrementales: 1. Toma una copia base de toda la instalación de la base de datos. 2. Envíalo al esclavo. 3. Configúrelo para ponerse al día con los cambios.

Streaming Replication (hot standby) es el ganador aquí. Personalmente, prefiero la replicación asincrónica, ya que no impone una carga considerable al maestro y el retraso de replicación es muy pequeño (un par de segundos en muchos casos)

Un complemento de esta configuración es pg-pool. Actúa como un proxy entre la aplicación y los servidores que participan en una configuración de replicación como la descrita anteriormente, tiene capacidades de equilibrio de carga y consultas paralelas. También puede proporcionar conmutación por error automática. http://www.pgpool.net/pgpool-web/contrib_docs/simple_sr_setting/index.html

La respuesta que ya ha recibido es útil pero un poco confusa aquí. Todas las soluciones de replicación incorporadas utilizan el mismo mecanismo básico: copiar datos de registro de escritura anticipada en un servidor en espera.

Puede mover los datos de WAL para la replicación, ya sea un archivo de 16 MB a la vez, utilizando la función archive_command o utilizando Streaming Replication (SR). Si usa SR, también debería configurar el archivado, y el servidor cambiará entre ellos según corresponda.

Puede tener un servidor en espera cálido, que no puede responder consultas. O puede tener un servidor en espera activo, que puede responder a los de solo lectura. Esto no está relacionado con la forma en que los datos llegan al modo de espera.

Cada una de estas dos opciones se combina con cada una de las otras, y puede tener las cuatro combinaciones. Puede tener un Hot Standby respondiendo consultas mientras se alimenta con archivos WAL a la vez. Puede tener un servidor de replicación de transmisión que no tenga Hot Standby habilitado, por lo que no responderá consultas. Es solo que el caso más común, hoy en día, es tanto Streaming Replication más Hot Standby. Ese es el conjunto completo de características. Nuevamente, no ignore el antiguo mecanismo archive_command solo porque es posible evitarlo ahora. Todavía puede salvarlo de fallas de transmisión que de otro modo serían difíciles de recuperar.