Este es el comando pg_receivexlog que se puede ejecutar en el proveedor de alojamiento gratuito de OnWorks utilizando una de nuestras múltiples estaciones de trabajo en línea gratuitas, como Ubuntu Online, Fedora Online, emulador en línea de Windows o emulador en línea de MAC OS.
PROGRAMA:
NOMBRE
pg_receivexlog: transmite registros de transacciones desde un servidor PostgreSQL
SINOPSIS
pg_receivexlog [opción...]
DESCRIPCIÓN
pg_receivexlog se utiliza para transmitir el registro de transacciones desde un clúster de PostgreSQL en ejecución.
El registro de transacciones se transmite mediante el protocolo de replicación de transmisión y se escribe
a un directorio local de archivos. Este directorio se puede utilizar como ubicación de archivo para
realizar una restauración mediante la recuperación en un momento determinado (consulte la Sección 24.3, “Archivado continuo y
Point-in-Time Recovery (PITR) ”, en la documentación).
pg_receivexlog transmite el registro de transacciones en tiempo real a medida que se genera en el
servidor, y no espera a que los segmentos se completen como lo hace archive_command. Para esto
razón, no es necesario establecer archive_timeout cuando se usa pg_receivexlog.
A diferencia del receptor WAL de un servidor en espera de PostgreSQL, pg_receivexlog se descarga de forma predeterminada
Datos WAL solo cuando se cierra un archivo WAL. La opción --sincrónico debe especificarse para
vaciar los datos de WAL en tiempo real.
El registro de transacciones se transmite a través de una conexión PostgreSQL normal y utiliza la
protocolo de replicación. La conexión debe realizarse con un superusuario o un usuario que tenga
Permisos de REPLICACIÓN (consulte la Sección 20.2, “Atributos de rol”, en la documentación), y
pg_hba.conf debe permitir la conexión de replicación. El servidor también debe estar configurado
con max_wal_senders establecido lo suficientemente alto como para dejar al menos una sesión disponible para el
arroyo.
Si se pierde la conexión, o si no se puede establecer inicialmente, con una
error, pg_receivexlog reintentará la conexión indefinidamente y restablecerá la transmisión como
tan pronto como sea posible. Para evitar este comportamiento, utilice el parámetro -n.
OPCIONES
-D directorio
--directory =directorio
Directorio en el que escribir la salida.
Este parámetro es obligatorio.
--si-no-existe
No se equivoque cuando --crear-ranura se especifica y una ranura con el especificado
Nombre ya existe.
-n
- sin bucle
No repita los errores de conexión. En su lugar, salga de inmediato con un error.
-s intervalo
--status-interval =intervalo
Especifica el número de segundos entre los paquetes de estado enviados de vuelta al servidor. Esta
permite un seguimiento más sencillo del progreso desde el servidor. Un valor de cero desactiva la
actualizaciones de estado periódicas por completo, aunque se enviará una actualización cuando
solicitado por el servidor, para evitar desconexión por tiempo de espera. El valor predeterminado es 10 segundos.
-S nombre de ranura
--slot =nombre de ranura
Requerir que pg_receivexlog use una ranura de replicación existente (consulte la Sección 25.2.6,
“Replication Slots”, en la documentación). Cuando se usa esta opción, pg_receivexlog
informará una posición enrasada al servidor, indicando cuando cada segmento ha sido
sincronizado con el disco para que el servidor pueda eliminar ese segmento si no es de otra manera
necesario.
Cuando el cliente de replicación de pg_receivexlog está configurado en el servidor como
espera síncrona, luego el uso de una ranura de replicación informará la posición de descarga a
servidor, pero solo cuando se cierra un archivo WAL. Por lo tanto, esa configuración
hacer que las transacciones en el primario esperen mucho tiempo y efectivamente no funcionen
satisfactoriamente. La opción --synchronous (ver más abajo) debe especificarse además de
hacer que esto funcione correctamente.
--sincrónico
Vacíe los datos de WAL en el disco inmediatamente después de que se hayan recibido. También envía un estado
paquete de vuelta al servidor inmediatamente después del vaciado, independientemente de --status-interval.
Esta opción debe especificarse si el cliente de replicación de pg_receivexlog es
configurado en el servidor como un modo de espera síncrono, para garantizar que la retroalimentación oportuna sea
enviado al servidor.
-v
--verboso
Habilita el modo detallado.
Las siguientes opciones de la línea de comandos controlan los parámetros de conexión de la base de datos.
-d control
--dbname =control
Especifica los parámetros utilizados para conectarse al servidor, como una cadena de conexión. Ver
Sección 31.1.1, “Cadenas de conexión”, en la documentación para obtener más información.
La opción se llama --dbname para mantener la coherencia con otras aplicaciones cliente, pero
porque pg_receivexlog no se conecta a ninguna base de datos en particular en el clúster,
Se ignorará el nombre de la base de datos en la cadena de conexión.
-h fortaleza
--host =fortaleza
Especifica el nombre de host de la máquina en la que se ejecuta el servidor. Si el valor
comienza con una barra, se utiliza como directorio para el socket de dominio Unix. los
por defecto se toma de la PHOST variable de entorno, si se establece, de lo contrario, un dominio Unix
Se intenta la conexión del enchufe.
-p Puerto
--port =Puerto
Especifica el puerto TCP o la extensión del archivo de socket de dominio Unix local en el que el servidor
está escuchando conexiones. Por defecto es PUERTOPG variable de entorno, si se establece, o
un valor predeterminado compilado.
-U nombre de usuario
--username =nombre de usuario
Nombre de usuario para conectarse como.
-w
--Sin contraseña
Nunca emita una solicitud de contraseña. Si el servidor requiere autenticación de contraseña y una
La contraseña no está disponible por otros medios, como un archivo .pgpass, la conexión
el intento fallará. Esta opción puede ser útil en trabajos por lotes y scripts donde ningún usuario
está presente para ingresar una contraseña.
-W
--contraseña
Obligar a pg_receivexlog a solicitar una contraseña antes de conectarse a una base de datos.
Esta opción nunca es esencial, ya que pg_receivexlog solicitará automáticamente una
contraseña si el servidor exige autenticación de contraseña. Sin embargo, pg_receivexlog
desperdiciar un intento de conexión descubriendo que el servidor quiere una contraseña. En algunos casos
vale la pena escribir -W para evitar el intento de conexión adicional.
pg_receivexlog puede realizar una de las dos acciones siguientes para controlar los
ranuras de replicación:
--crear-ranura
Cree una nueva ranura de replicación física con el nombre especificado en --espacio, luego sal.
- ranura de caída
Suelta la ranura de replicación con el nombre especificado en --espacio, luego sal.
También hay otras opciones disponibles:
-V
--versión
Imprima la versión pg_receivexlog y salga.
-?
--ayuda
Muestre ayuda sobre los argumentos de la línea de comando pg_receivexlog y salga.
MEDIO AMBIENTE
Esta utilidad, como la mayoría de las otras utilidades de PostgreSQL, usa las variables de entorno
compatible con libpq (consulte la Sección 31.14, “Variables de entorno”, en la documentación).
NOTAS
Cuando se utiliza pg_receivexlog en lugar de archive_command como método principal de copia de seguridad de WAL, es
Se recomienda encarecidamente utilizar ranuras de replicación. De lo contrario, el servidor puede reciclar o
eliminar los archivos de registro de transacciones antes de realizar una copia de seguridad, porque no tiene ningún
información, ya sea de archive_command o de las ranuras de replicación, sobre qué tan lejos el WAL
Se ha archivado la transmisión. Sin embargo, tenga en cuenta que una ranura de replicación llenará el espacio del servidor.
espacio en disco si el receptor no se mantiene al día con la obtención de los datos WAL.
EJEMPLOS
Para transmitir el registro de transacciones desde el servidor en mydbserver y almacenarlo en el local
directorio / usr / local / pgsql / archive:
$ pg_receivexlog -h midbserver -D / usr / local / pgsql / archive
Use pg_receivexlog en línea usando los servicios de onworks.net
