pg_standby: en línea en la nube

PROGRAMA:

NOMBRE

pg_standby: admite la creación de un servidor de espera en caliente PostgreSQL

SINOPSIS

pg_en espera [opción...] ubicación de archivo siguientewalfile rutaarchivoxlog [reiniciar el archivo]

DESCRIPCIÓN

pg_standby admite la creación de un servidor de base de datos "en espera en caliente". Está diseñado para ser un
programa listo para producción, así como una plantilla personalizable en caso de que necesite
cambios.

pg_standby está diseñado para ser una espera restaurar_comando, que se necesita para convertir un estándar
Recuperación de archivos en una operación de espera en caliente. También se requiere otra configuración,
todo lo cual se describe en el manual del servidor principal (consulte la Sección 25.2, “Envío de registros
Standby Servers ”, en la documentación).

Para configurar un servidor en espera para usar pg_standby, colóquelo en su recovery.conf
archivo de configuración:

restore_command = 'pg_standby directorioarchivo % f% p% r '

dónde directorioarchivo es el directorio desde el que se deben restaurar los archivos de segmento WAL.

If reiniciar el archivo se especifica, normalmente utilizando la macro% r, luego todos los archivos WAL
lógicamente que precede a este archivo se eliminará de ubicación de archivo. Esto minimiza el
cantidad de archivos que deben conservarse, al tiempo que se conserva la capacidad de reinicio por fallas. Usar
de este parámetro es apropiado si el ubicación de archivo es un área de preparación transitoria para
este servidor en espera en particular, pero No cuando ubicación de archivo está pensado como un
Área de archivo WAL a largo plazo.

pg_standby asume que ubicación de archivo es un directorio que puede leer el usuario propietario del servidor.
If reiniciar el archivo (o -k), el ubicación de archivo el directorio debe tener permisos de escritura


Hay dos formas de conmutar por error a un servidor de base de datos "en espera en caliente" cuando el servidor maestro
falla:

Conmutación por error inteligente
En la conmutación por error inteligente, el servidor se activa después de aplicar todos los archivos WAL disponibles en
el archivo. Esto da como resultado una pérdida de datos cero, incluso si el servidor en espera se ha caído
detrás, pero si hay mucho WAL sin aplicar, puede pasar mucho tiempo antes de que
el servidor en espera está listo. Para activar una conmutación por error inteligente, cree un archivo de activación
que contiene la palabra inteligente, o simplemente créelo y déjelo vacío.

Conmutación por error rápida
En la conmutación por error rápida, el servidor se activa inmediatamente. Cualquier archivo WAL en el archivo
que aún no se hayan aplicado se ignorarán y todas las transacciones en esos archivos
Esta perdido. Para activar una conmutación por error rápida, cree un archivo de activación y escriba la palabra rápido
en ello. pg_standby también se puede configurar para ejecutar una conmutación por error rápida automáticamente
si no aparece un nuevo archivo WAL dentro de un intervalo definido.

OPCIONES

pg_standby acepta los siguientes argumentos de la línea de comandos:

-c
Utilice el comando cp o copy para restaurar los archivos WAL del archivo. Este es el único compatible
comportamiento por lo que esta opción es inútil.

-d
Imprima muchos resultados de registro de depuración en stderr.

-k
Quitar archivos de ubicación de archivo de modo que no más de esta cantidad de archivos WAL antes de la
el actual se guarda en el archivo. Cero (el valor predeterminado) significa no eliminar ningún archivo
Desde ubicación de archivo. Este parámetro se ignorará silenciosamente si reiniciar el archivo is
especificado, ya que ese método de especificación es más preciso para determinar la
punto de corte de archivo. El uso de este parámetro es a partir de PostgreSQL 8.3; está
más seguro y más eficiente para especificar un reiniciar el archivo parámetro. Un escenario demasiado pequeño
podría resultar en la eliminación de archivos que aún son necesarios para reiniciar el modo de espera
servidor, mientras que una configuración demasiado grande desperdicia espacio de archivo.

-r intentos máximos
Establezca el número máximo de veces para reintentar el comando de copia si falla (predeterminado 3).
Después de cada falla, esperamos hora de dormir * num_intentos para que el tiempo de espera
aumenta progresivamente. Entonces, de forma predeterminada, esperaremos 5 segundos, 10 segundos y luego 15 segundos.
antes de informar de la falla al servidor en espera. Esto se interpretará como
finaliza la recuperación y, como resultado, el modo de espera se activará por completo.

-s hora de dormir
Configure el número de segundos (hasta 60, predeterminado 5) para dormir entre pruebas para ver si el
El archivo WAL que se va a restaurar aún está disponible en el archivo. La configuración predeterminada no es
necesariamente recomendado; consulte la Sección 25.2, “Servidores en espera de envío de registros”, en el
documentación para discusión.

-t Triggerfile
Especifique un archivo desencadenante cuya presencia debería provocar la conmutación por error. Se recomienda que
utiliza un nombre de archivo estructurado para evitar confusiones en cuanto a qué servidor se
se activa cuando existen varios servidores en el mismo sistema; por ejemplo
/tmp/pgsql.trigger.5432.

-V
--versión
Imprima la versión pg_standby y salga.

-w tiempo de espera máximo
Establezca el número máximo de segundos para esperar el siguiente archivo WAL, después de lo cual
Se realizará la conmutación por error. Un ajuste de cero (el predeterminado) significa esperar para siempre. los
la configuración predeterminada no se recomienda necesariamente; consulte la Sección 25.2, “Envío de troncos
Standby Servers ”, en la documentación para discusión.

-?
--ayuda
Muestre ayuda sobre los argumentos de la línea de comando pg_standby y salga.

NOTAS

pg_standby está diseñado para funcionar con PostgreSQL 8.2 y versiones posteriores.

PostgreSQL 8.3 proporciona la macro% r, que está diseñada para que pg_standby sepa lo último
archivo que necesita conservar. Con PostgreSQL 8.2, se debe usar la opción -k si la limpieza del archivo
es requerido. Esta opción permanece disponible en 8.3, pero su uso está obsoleto.

PostgreSQL 8.4 proporciona la comando_fin_recuperación opción. Sin esta opción un sobrante
El archivo activador puede ser peligroso.

pg_standby está escrito en C y tiene un código fuente fácil de modificar, específicamente
secciones designadas para modificar según sus propias necesidades

EJEMPLOS

En sistemas Linux o Unix, puede usar:

comando_archivo = 'cp% p ... / archivo /% f'

restore_command = 'pg_standby -d -s 2 -t /tmp/pgsql.trigger.5442 ... / archive% f% p% r 2 >> standby.log'

recovery_end_command = 'rm -f /tmp/pgsql.trigger.5442'

donde el directorio de archivo se encuentra físicamente en el servidor en espera, de modo que el
comando_archivo está accediendo a él a través de NFS, pero los archivos son locales en el modo de espera
(que permite el uso de ln). Esta voluntad:

· Producir salida de depuración en standby.log

· Dormir durante 2 segundos entre comprobaciones para la próxima disponibilidad del archivo WAL

· Dejar de esperar solo cuando aparezca un archivo de activación llamado /tmp/pgsql.trigger.5442, y
realizar la conmutación por error de acuerdo con su contenido

· Eliminar el archivo de activación cuando finaliza la recuperación

· Eliminar los archivos que ya no se necesitan del directorio de archivos

En Windows, puede usar:

archive_command = 'copiar% p ... \\ archivo \\% f'

restore_command = 'pg_standby -d -s 5 -t C: \ pgsql.trigger.5442 ... \ archive% f% p% r 2 >> standby.log'

recovery_end_command = 'del C: \ pgsql.trigger.5442'

Tenga en cuenta que las barras invertidas deben duplicarse en el comando_archivo, pero No en la sección de
restaurar_comando or comando_fin_recuperación. Esta voluntad:

· Use el comando de copia para restaurar archivos WAL del archivo

· Producir salida de depuración en standby.log

· Dormir durante 5 segundos entre comprobaciones para la próxima disponibilidad del archivo WAL

· Dejar de esperar solo cuando aparezca un archivo de activación llamado C: \ pgsql.trigger.5442, y
realizar la conmutación por error de acuerdo con su contenido

· Eliminar el archivo de activación cuando finaliza la recuperación

· Eliminar los archivos que ya no se necesitan del directorio de archivos

El comando de copia en Windows establece el tamaño del archivo final antes de que el archivo se copie por completo,
lo que normalmente confundiría a pg_standby. Por lo tanto, pg_standby espera dormir segundos
una vez que ve el tamaño de archivo adecuado. El cp de GNUWin32 establece el tamaño del archivo solo después del archivo
la copia está completa.

Dado que el ejemplo de Windows usa copia en ambos extremos, uno o ambos servidores pueden ser
acceder al directorio de archivos a través de la red.

Use pg_standby en línea usando los servicios de onworks.net