slon - Online en la nube

PROGRAMA:

NOMBRE

slon - demonio Slony-I

SINOPSIS

slon [opción] ... [nombre del clúster] [conninfo]

DESCRIPCIÓN

slon es la aplicación demonio que 'ejecuta' la replicación Slony-I. Una instancia de slon debe ser
ejecutar para cada nodo en un clúster Slony-I.

OPCIONES

-d nivel de registro
La sección nivel de registro especifica qué niveles de mensajes de depuración debe mostrar slon cuando
registrando su actividad.

Los nueve niveles de registro son:

· Mortal

· Error

· Advertir

· Configuración

· Información

· Depuración1

· Depuración2

· Depuración3

· Depuración4

Los primeros cinco niveles de registro sin depuración (de Fatal a Info) son muestra en el
registros. En las primeras versiones de Slony-I, el 'sugerido' nivel de registro el valor era 2, lo que
lista de salida en todos los niveles hasta el nivel de depuración 2. En Slony-I versión 2, es
recomendado para configurar nivel de registro a 0; la mayor parte de la información de registro de interés constante es
generado en niveles superiores a eso.

-s SYNC check intervalo
La sección intervalo de sincronización, medido en milisegundos, indica la frecuencia con la que slon debe verificar
para ver si un SYNC debe ser introducido. El valor predeterminado es 2000 ms. El bucle principal en
sync_Thread_main () duerme por intervalos de intervalo de sincronización milisegundos entre
iteraciones.

Los intervalos cortos de verificación de sincronización mantienen el origen en una 'correa corta', actualizando su
suscriptores con mayor frecuencia. Si ha replicado secuencias que son frecuentemente
actualizado sin hay tablas que se ven afectadas, esto evita que haya
momentos en los que solo se actualizan las secuencias y, por lo tanto, no las sincronizaciones tienen lugar

Si el nodo no es un origen para ningún conjunto de replicación, por lo que no se recibirán actualizaciones,
Es algo inútil que este valor sea mucho menor sincronización_intervalo_tiempo de espera
.

-t SYNC intervalo tiempo de espera
Al final de cada sincronización_intervalo_tiempo de espera período de tiempo de espera, un SYNC será generado
en el nodo 'local' incluso si no se han actualizado datos replicables que
han causado un SYNC que se generará.

Si la actividad de la aplicación cesa, ya sea porque la aplicación está cerrada o
debido a que los usuarios humanos se han ido a casa y han dejado de introducir actualizaciones, el slon(1)
iterará lejos, despertando cada intervalo de sincronización milisegundos y, como no hay actualizaciones
se están haciendo, no SYNC se generarían eventos. Sin este parámetro de tiempo de espera,
no SYNC se generarían eventos, y parecería que la replicación estaba cayendo
detrás.

La sección sincronización_intervalo_tiempo de espera valor conducirá a generar eventualmente un SYNC, Incluso
aunque no hubo trabajo de replicación real por hacer. Cuanto menor sea este parámetro
está configurado, con más frecuencia slon(1) generará SYNC eventos cuando la aplicación
no genera actividad replicable; esto tendrá dos efectos:

· El sistema hará más trabajo de replicación.

(Por supuesto, dado que no hay carga de aplicaciones en la base de datos y no hay datos para
replicar, esta carga será muy fácil de manejar.

· La replicación parecerá mantenerse más "actualizada".

(Por supuesto, dado que no hay actividad replicable, estar 'más a la altura
cita 'es una especie de espejismo).

El valor predeterminado es 10000 ms y el máximo es 120000 ms. De forma predeterminada, puede esperar que cada nodo
'informar en' con un SYNC cada 10 segundos.

Tenga en cuenta que SYNC Los eventos también se generan en los nodos de abonado. Dado que en realidad no son
generando cualquier dato para replicarlo en otros nodos, estos SYNC los eventos no son terriblemente
mucho valor.

-g grupo de XNUMX tamaño
Esto controla el máximo SYNC tamaño del grupo, sync_group_maxsize; por defecto es 6. Por lo tanto,
si un nodo en particular está atrasado en 200 SYNCs, intentará agruparlos
en grupos de un tamaño máximo de sync_group_maxsize. Se puede esperar que esto reduzca
sobrecarga de transacción debido a tener menos transacciones para COMETER.

El valor predeterminado de 6 probablemente sea adecuado para sistemas pequeños que solo pueden dedicar muy
bits limitados de memoria para slon. Si tienes mucha memoria, sería
razonable aumentar esto, ya que aumentará la cantidad de trabajo realizado en cada
transacción, y permitirá a un suscriptor que está muy atrasado ponerse al día más
con rapidez.

Los procesos de Slon suelen ser bastante pequeños; incluso con un gran valor para esta opción,
Se esperaría que slon solo creciera hasta unos pocos MB de tamaño.

La gran ventaja de aumentar este parámetro proviene de reducir el
número de transacción COMETERs; pasar de 1 a 2 proporcionará una considerable
beneficio, pero los beneficios disminuirán progresivamente una vez que las transacciones se
procesados ​​llegan a ser razonablemente grandes. No es probable que haya un material
diferencia de rendimiento entre 80 y 90; en ese punto, si 'más grande es
mejor 'dependerá de si el conjunto más grande de SYNCs hace el LOG comportamiento del cursor
mal debido a que consume más memoria y requiere más tiempo para clasificar.

En Slony-I versión 1.0, slon siempre intentará agrupar SYNCs juntos a esto
máximo, que no se ser ideal si la replicacin ha sido algo desestabilizada por
hay actualizaciones muy grandesp.ej. - una sola transacción que actualiza cientos
de miles de filas) o por SYNCs se interrumpe en un nodo de origen con el resultado
que hay unos pocos SYNCs que son muy grandes. Podrías encontrarte con el problema que
agrupando algunos muy grandes SYNCs derriba un proceso slon. Cuando escoge
de nuevo, intentará procesar el mismo conjunto grande agrupado de SYNCs, y choca contra
el mismo problema una y otra vez hasta que un administrador interrumpe esto y cambia
el -g valor para romper este 'punto muerto'.

En Slony-I versión 1.1 y versiones posteriores, el slon, en cambio, se 'acelera' adaptativamente
de hacer 1 SYNC a la vez hacia el tamaño máximo del grupo. Como resultado, si hay
son un par de SYNCs que causan problemas, el slon lo hará (con cualquier
asistencia del perro guardián) siempre podrá llegar al punto en el que procesa el
molesto SYNCs uno por uno, con suerte haciendo innecesaria la asistencia del operador.

-o deseado sincronizar time
Un tiempo 'máximo' planeado para grupos SYNCs.

Si la replicación se está retrasando, slon aumentará gradualmente el número de SYNCs
agrupados, apuntando a eso (basado en el tiempo necesario para la pasado grupo de
SYNCs) no deben tomar más de lo especificado deseada_sync_time .

El valor predeterminado para deseada_sync_time es 60000ms, igual a un minuto.

De esa manera, puede esperar (¡o al menos esperar!) Que obtendrá un COMETER aproximadamente una vez
por minuto.

No es totalmente predecible, ya que es completamente posible que alguien solicite una
muy large actualización, todo como una sola transacción, que puede "hacer estallar" la longitud del
resultante SYNC ser casi arbitrariamente largo. En tal caso, la voluntad heurística
retrocede por el Next grupo.

El efecto general es mejorar la capacidad de Slony-I para hacer frente a variaciones en
tráfico. Comenzando con 1 SYNCy pasar gradualmente a más, incluso si hay
resultan ser variaciones lo suficientemente grandes como para hacer que los backends de PostgreSQL se bloqueen, Slony-I
retrocederá para comenzar con una sincronización a la vez, si es necesario, de modo que si es
posible para que la replicación progrese, lo hará.

-c limpieza de ciclos
El valor frecuencia_vac indica con qué frecuencia VACÍO en ciclos de limpieza.

Ajústelo a cero para deshabilitar la aspiración iniciada por slon. Si estas usando algo
como pg_autovacuum para iniciar vacíos, es posible que no necesite que slon inicie
se aspira. Si no es así, hay algunas tablas que usa Slony-I que recopilan un
montón de tuplas muertas que deben aspirarse con frecuencia, especialmente pg_listener.

En Slony-I versión 1.1, esto cambia un poco; las pistas del hilo de limpieza, desde
iteración a iteración, el ID de transacción más antiguo aún activo en el sistema. Si
esto no cambia, de una iteración a la siguiente, entonces una transacción anterior es
todavía activo, y por lo tanto un VACÍO no servirá de nada. El hilo de limpieza en su lugar
simplemente hace un ANALIZAR en estas tablas para actualizar las estadísticas en pg_estadísticas.

-p PID nombre de archivo
archivo_pid contiene el nombre de archivo en el que se almacena el PID (ID de proceso) del slon.

Esto puede facilitar la construcción de scripts para monitorear múltiples procesos slon.
ejecutándose en un solo host.

-f config presentar
Archivo desde el que leer la configuración de slon.

Esta configuración se analiza con más detalle en Slon Run-time Configuration ["Run-time
Configuración ”[no disponible como página de manual]]. Si va a haber un conjunto complejo de
parámetros de configuración, o si hay parámetros que no desea que sean visibles
en las variables de entorno del proceso (como contraseñas), puede ser conveniente
dibujar muchos o todos los parámetros de un archivo de configuración. Podrías poner en común
parámetros para todos los procesos slon en un archivo de configuración de uso común, lo que permite
la línea de comando para especificar poco más que la información de conexión. Alternativamente,
puede crear un archivo de configuración para cada nodo.

-a Archivo directorio
dir_archivo indica un directorio en el que colocar una secuencia de SYNC Archivo
archivos para su uso en el trasvase de registros ["Trasvase de registros - Slony-I con archivos" [no disponible
como una página de manual]] modo.

-x comando a puedes seguir on log Archivo
comando_en_archivo_de_registro indica un comando que se ejecutará cada vez que se ejecute un archivo SYNC
generado con éxito.

Ver más detalles sobre "slon_conf_command_on_log_archive" [no disponible como hombre
página].

-q renuncia basado on SYNC proveedor
quit_sync_provider indica en qué hilo de trabajo del proveedor se debe vigilar
para terminar después de un evento determinado. Debe utilizarse junto con el
-r opción a continuación ...

Esto le permite hacer que un slon deje de replicarse después de cierto punto.

-r renuncia at evento número
quit_sync_finalsync indica el número de evento después del cual el hilo de trabajo remoto
para el proveedor anterior debe terminar. Debe utilizarse junto con el
-q opción anterior ...

-l retraso intervalo
intervalo_lag indica un valor de intervalo como 3 minutos or 4 horas or 2 días
que indica que este nodo va a retrasar a sus proveedores en el intervalo especificado de
hora. Esto provoca que los eventos se ignoren hasta que alcancen la edad correspondiente a
el intervalo.
advertencia

Hay una desventaja concomitante de este retraso; eventos que requieren que todos los nodos
sincronizar, como suele ocurrir con SLONIK FALLO(7) y SLONIK MOVIMIENTO SET(7)
tendrá que esperar a este nodo rezagado.

Puede que ese no sea el comportamiento ideal en el momento de la conmutación por error o en el momento en que desee
puedes seguir SLONIK EJECUTAR GUIÓN(7).

SALIR ESTADO

slon devuelve 0 al shell si terminó normalmente. Vuelve vía salir (-1) (que lo hará
probablemente proporcione un valor de retorno de 127 o 255, dependiendo de su sistema) si
encuentra cualquier error fatal.

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