Professional Documents
Culture Documents
Cada uno tiene sus propias fortalezas y debilidades, cada uno se analiza a su vez en las siguientes secciones.
Como puede ver, pg_dump escribe su resultado a la salida estndar. Veremos a continuacin cmo esto puede ser til. pg_dump es un habitual PostgreSQL aplicacin cliente (si bien de manera especialmente inteligente). Esto significa que usted puede realizar este procedimiento de copia de seguridad de cualquier host remoto que tenga acceso a la base de datos. Pero recuerde que pg_dump no funciona con permisos especiales. En particular, se debe tener acceso de lectura a todas las tablas que desee hacer copia de seguridad, por lo que en la prctica casi siempre tiene que ejecutarlo como superusuario base de datos. Para especificar el servidor de base de datos pg_dump debe comunicarse, utilice la lnea de comando opciones lo que su
PGHOST variable de entorno especifica. Del mismo modo, el puerto por defecto es PGPORT variable de entorno o, en su defecto, por el compilados por
indicado por el
defecto.(Convenientemente, el servidor normalmente tendr el mismo defecto compilados en el.) Al igual que cualquier otro PostgreSQL aplicacin cliente, pg_dump de forma predeterminada conectarse con el nombre de usuario de base de datos que es igual al nombre de usuario del sistema operativo actual. Para anular este, especifique el entorno
autenticacin de clientes normales (que se describe en el Captulo 19 ). Una ventaja importante de pg_dump ms de los otros mtodos de copia de seguridad se describe ms adelante es que pg_dump de salida 's general, se puede volver a cargar en las nuevas versiones de PostgreSQL , mientras que las copias de seguridad de nivel de archivo y continuas de archivado son ambos extremadamente servidor-especfica de la versin.pg_dump es tambin el nico mtodo que funciona para transferir una base de datos a una arquitectura de mquina diferente, como ir de una de 32 bits en un servidor de 64 bits. Vuelca creados por pg_dump son internamente consistentes, es decir, el vertedero representa una instantnea de la base de datos en el momento pg_dump comenz a correr. pg_dumpno bloquea otras operaciones en la base de datos mientras se est trabajando. (Las excepciones son aquellas operaciones que necesitan para operar con un bloqueo exclusivo, como la mayora de las formas de
ALTER TABLE .)
Importante: Si el esquema de base de datos se basa en la OID (por ejemplo, como claves externas) debe instruir a pg_dump para volcar los OID tambin. Para ello, utilice el de lnea de comandos.
-ola opcin
donde
infile es el archivo de salida por el pg_dump comandos. La base de datos dbname no template0 antes de createdb-T template0 dbname ). psql soporta opciones
se crear por este comando, por lo que debe crear usted mismo de ejecutar psql (por ejemplo, con
similares a pg_dump para especificar el servidor de base de datos para conectarse y el usuario nombrar a utilizar. Ver el psql pgina de referencia para obtener ms informacin. Antes de restaurar un volcado SQL, todos los usuarios que poseen los objetos o se conceden permisos en los objetos en la base de datos objeto de dumping ya deben existir. Si no lo hacen, la restauracin no podrn volver a crear los objetos con la propiedad original y / o permisos. (A veces esto es lo que quieres, pero por lo general no lo es.) Por defecto, el psql guin seguir ejecutando despus de que se ha detectado un error de SQL. Es posible que desee ejecutar psql con la
modificar ese comportamiento y tienen psql salida con un cdigo de salida de 3 si se produce un error SQL:
De cualquier manera, slo tendr una base de datos parcialmente restaurada. Como alternativa, se puede especificar que todo el vertedero debe ser restaurada como una sola transaccin, por lo que la restauracin se haya completado ya sea total o deshace. Este modo se puede especificar al pasar el
depsql . Cuando se utiliza este modo, tenga en cuenta que incluso un pequeo error puede deshacer una restauracin que ya ha estado funcionando durante muchas horas. Sin embargo,
que an podra ser preferible a la limpieza manualmente una compleja base de datos despus de un volcado parcialmente restaurado. La capacidad de pg_dump y psql para escribir o leer de las tuberas permite volcar una base de datos directamente desde un servidor a otro, por ejemplo:
pg_dump-h host1
dbname
Importante: Los depsitos producidos por pg_dump son relativas a significa que los lenguajes, procedimientos, etc aaden travs
template0 . Esto
abandonado por pg_dump . Como resultado, cuando la restauracin, si usted est utilizando una medida
anterior. Despus de restaurar una copia de seguridad, es aconsejable ejecutar ANALYZE en cada base de datos para que el optimizador de consultas tiene estadsticas tiles, vase la Seccin 23.1.3 y la Seccin 23.1.5 para ms informacin. Para obtener ms consejos sobre cmo cargar grandes cantidades de datos en PostgreSQL eficiente, consulte la Seccin 14.4 .
pg_dumpall> archivosalida
(En realidad, se puede especificar un nombre de base de datos existente a partir, pero si va a cargar en un clster vaco, entonces
necesario tener acceso de superusuario al restaurar una base de datos pg_dumpall volcado, como lo que se requiere para restaurar la funcin y la informacin de tablas. Si utiliza espacios de tabla, asegrese de que los caminos de tablas en el vertedero son apropiadas para la nueva instalacin. pg_dumpall funciona por comandos emisores para volver a crear los roles, espacios de tablas y bases de datos vacas, entonces invocar pg_dump para cada base de datos. Esto significa que mientras que cada base de datos ser internamente consistente, las instantneas de diferentes bases de datos podran no ser exactamente en sincrona.
Actualizar con:
o:
Utilice
pequeos que son aceptables en el tamao del sistema de archivos subyacente. Por ejemplo, para hacer trozos de 1 megabyte:
Actualizar con:
Utilice pg_dump formato de volcado custom 's. Si PostgreSQL fue construido en un sistema con el zlib biblioteca de compresin instalada, el formato de volcado personalizado comprimir datos a medida que escribe en el archivo de salida. Esto producir tamao de los archivos de volcado similares a usando
restaurar selectivamente. El comando siguiente vuelca una base de datos utilizando el formato de volcado de encargo:
Un volcado con formato personalizado no es un guin de psql , sino que debe ser restaurado con pg_restore , por ejemplo:
pg_restore-d dbname
nombre
Ver el pg_dump y pg_restore pginas de referencia para obtener ms informacin. Para bases de datos muy grandes, es posible que tenga que combinar los otros dos enfoques.
Una estrategia de copia de seguridad alternativa es copiar directamente los archivos que PostgreSQL utiliza para almacenar los datos en la base de datos; Seccin 17.2 explica dnde se encuentran estos archivos. Usted puede utilizar cualquier mtodo que prefiera para hacer copias de seguridad del sistema de archivos, por ejemplo:
Hay dos restricciones, sin embargo, que hacen que este mtodo no sea prctico, o por lo menos inferior a la pg_dump mtodo: 1. El servidor de base de datos debe ser cerrada con el fin de obtener una copia de seguridad utilizable. Medidas a medio camino, como no permitir que todas las conexiones se nofunciona (en parte debido a
toman una instantnea atmica del estado del sistema de archivos, pero tambin a causa de bfer interno en el servidor). Informacin acerca de detener el servidor se encuentra en la Seccin 17.5 . Ni que decir tiene, tambin es necesario apagar el servidor antes de restaurar los datos. 2. Si usted ha excavado en los detalles de la estructura de archivos de la base de datos, es posible que se sienta tentado a intentar realizar una copia de seguridad o restaurar slo algunas mesas individuales o bases de datos de sus respectivos archivos o directorios. Esto no funciona porque la informacin contenida en estos archivos no se puede utilizar sin los archivos de registro de las confirmaciones,
pg_clog / * , que
contiene el estado de compromiso de todas las transacciones. Un archivo de la tabla slo se puede usar con esta informacin. Por supuesto, tambin es posible restaurar slo una mesa y los asociados
pg_clog datos porque eso sera hacer todas las otras tablas en el
cluster de base de datos intiles. As que las copias de seguridad del sistema de archivos slo funcionan para una completa copia de seguridad y restauracin de un clster de base de datos completa. Un enfoque alternativo de copia de seguridad del sistema de archivos es hacer una "instantnea coherente" del directorio de datos, si el sistema de archivos admite esa funcionalidad (y que est dispuesto a confiar en que se lleva a cabo correctamente). El procedimiento tpico es hacer una "instantnea congelada" del volumen que contiene la base de datos y, a continuacin, copiar el directorio de datos entera (no slo las piezas, vase ms arriba) de la instantnea en un dispositivo de copia de seguridad, a continuacin, suelte la instantnea congelada. Esto funciona
incluso cuando el servidor de base de datos se est ejecutando. Sin embargo, una copia de seguridad creada de esta manera guarda los archivos de base de datos en un estado como si el servidor de base de datos no se apaga correctamente, por lo tanto, cuando se inicia el servidor de base de datos en los datos de la copia de seguridad, que va a pensar la instancia de servidor anterior se estrell y se volver a reproducir el registro de WAL. Esto no es un problema, acaba de ser conscientes de ello (y asegrese de incluir los archivos WAL en la copia de seguridad). Puede realizar un el tiempo de recuperacin. Si su base de datos se extiende a travs de varios sistemas de archivos, puede que no haya ninguna manera de obtener instantneas congeladas exactamente simultneas de todos los volmenes. Por ejemplo, si los archivos de datos y registro de WAL estn en discos diferentes, o si los espacios de tablas estn en diferentes sistemas de archivos, puede que no sea posible utilizar copias de seguridad de instantneas porque las instantneas deben ser simultneos. Lea la documentacin de su sistema de archivos con mucho cuidado antes de confiar en la tcnica consistente a la instantnea en tales situaciones. Si instantneas simultneas no son posibles, una opcin es apagar el servidor de base de datos suficiente para establecer todas las instantneas congeladas. Otra opcin es realizar una copia de seguridad de base de archivo continuo ( Seccin 24.3.2 ), ya que dichas copias de seguridad son inmunes a presentar cambios en el sistema durante la copia de seguridad. Para ello es necesario habilitar el archivado continuo solo durante el proceso de copia de seguridad, restauracin se realiza mediante la recuperacin de archivo continuo ( Seccin 24.3.3 ). Otra opcin es usar rsync para realizar una copia de seguridad del sistema de archivos. Esto se hace primero corriendo rsync mientras el servidor de bases de datos est en marcha, apagar el servidor de base de datos slo el tiempo suficiente para hacer un segundo rsync . El segundo rsync ser mucho ms rpido que el primero, ya que tiene relativamente pocos datos para transferir, y el resultado final ser consistente porque el servidor estaba abajo. Este mtodo permite una copia de seguridad del sistema de archivos que se realiza con mnimo tiempo de inactividad. Tenga en cuenta que una copia de seguridad del sistema de archivos ser tpicamente ms grande que un volcado SQL. ( pg_dump no necesita volcar el contenido de los ndices, por ejemplo, slo los comandos que volver a crearlos.) Sin embargo, teniendo una copia de seguridad del sistema de archivos puede ser ms rpido.
pg_xlog
/ subdirectorio del directorio de datos del clster. El registro registra cada cambio realizado en
los archivos de datos de la base de datos. Este registro existe principalmente para fines de choque de seguridad: si el sistema se bloquea, la base de datos se puede restaurar a la consistencia de "reproducir" las entradas del registro realizado desde el ltimo punto de control. Sin embargo, la existencia del registro hace que sea posible el uso de una tercera estrategia de copias de seguridad de bases de datos: podemos combinar una copia de seguridad del sistema de archivos de nivel de seguridad de los archivos WAL. Si la recuperacin es necesaria, restauramos la copia de seguridad del sistema de archivos y, despus, volver a los archivos WAL copia de seguridad para llevar el sistema a un estado actual. Este enfoque es ms complejo de administrar que cualquiera de los enfoques anteriores, pero tiene algunas ventajas importantes:
No necesitamos una copia de seguridad del sistema de archivos perfectamente consistente como punto de partida. Cualquier inconsistencia interna en la copia de seguridad se puede corregir mediante la reproduccin del registro (no es significativamente diferente de lo que ocurre durante la recuperacin del accidente). As que no necesitamos una capacidad de sistema de archivos de instantnea, simplemente tar o una herramienta de archivo similar.
Dado que podemos combinar un indefinidamente larga secuencia de archivos WAL para reproduccin, copia de seguridad continua puede lograrse simplemente mediante la continuacin de archivar los archivos WAL. Esto es particularmente til para grandes bases de datos, que podra no ser conveniente tomar una copia de seguridad con frecuencia.
No es necesario para volver a reproducir la entradas WAL todo el camino hasta el final. Podramos detener la reproduccin en cualquier momento y tienen una visin consistente de la base de datos, ya que era en ese momento. Por lo tanto, esta tcnica apoya la recuperacin de punto en el tiempo : es posible restaurar la base de datos a su estado en cualquier momento desde su copia de seguridad de base fue tomada.
Si continuamente nos alimentamos de la serie de archivos WAL a otro equipo que se ha cargado con el mismo archivo de copia de seguridad base, tenemos una reserva en caliente del sistema: en cualquier momento se puede abrir la segunda mquina y va a tener una copia casi de corriente de la base de datos.
Nota: pg_dump y pg_dumpall no producen copias de seguridad del sistema de archivos de nivel y no se pueden utilizar como parte de una solucin continua-archivo. Estos vertederos son lgicas y no contienen suficiente informacin para ser utilizada por WAL replay. Al igual que con la tcnica del sistema de archivos, copia de seguridad simple, este mtodo slo puede apoyar la restauracin de un clster de base de datos completa, no un subgrupo.Asimismo, se requiere una gran cantidad de almacenamiento de archivos: la copia de seguridad de base puede ser voluminoso y un sistema ocupado generar muchos megabytes de trfico WAL que tienen que ser archivada. Sin embargo, es la tcnica preferida de copia de seguridad en muchas situaciones donde es necesaria una alta fiabilidad. Para recuperar con xito utilizando el archivo continuo (tambin llamado "copia de seguridad en lnea" por muchos proveedores de bases de datos), se necesita una secuencia continua de archivos WAL archivados que se remonta por lo menos hasta la hora de inicio de la copia de seguridad. As que para empezar, se deben establecer y probar el procedimiento para archivar los archivos WAL antes de tomar su primera copia de seguridad de base. En consecuencia, primero discutimos los mecanismos de archivar los archivos WAL.
reciclado para su reutilizacin. Dependiendo de la aplicacin y el hardware disponible, podra haber muchas maneras de "guardar los datos en alguna parte" : podramos copiar los archivos del segmento a un directorio NFS montado en otra mquina, escribir en una unidad de cinta (asegurando que usted tiene una forma de identificar el nombre original de cada archivo), o por lotes juntos y grabarlas en CD, o algo completamente distinto. Para proporcionar al administrador de base de datos con la flexibilidad, PostgreSQL trata de no hacer ninguna suposicin acerca de cmo se realizar el archivado. En su lugar, PostgreSQL permite al administrador especificar un comando shell se ejecute para copiar un archivo segmento completo a donde tiene que ir. El comando podra ser tan simple como shell script complejo - es todo depende de ti. Para habilitar el archivado WAL, establezca el wal_level parmetro de configuracin de
cp , o podra invocar un
archivo (o hot_standby ), archive_mode a el , y especifique el comando shell para postgresql.conf archivo. En archive_command , % p se sustituye por el % f se sustituye por el nombre de archivo. (El
nombre de la ruta es relativa al directorio de trabajo actual, es decir, el directorio de datos de la agrupacin.) Utilice
prueba archive_command = '! -F / mnt / server / archivedir /% && cp f% p / mnt / server / archivedir /% f '# Unix archive_command = "copy"% p "" C: \ \ servidor \ \ archivedir \ \% f "'# para Windows
/ mnt / server /
El comando archive ser ejecutado bajo la propiedad del mismo usuario que el PostgreSQL servidor se ejecuta como. Dado que la serie de archivos WAL est archivada contiene todo lo efectiva en su base de datos, usted quiere estar seguro de que los datos archivados se protege de las miradas indiscretas, por ejemplo, archivos en un directorio que no tiene grupo o del mundo acceso de lectura. Es importante que el comando de retorno de estado de salida cero archive si y slo si tiene xito. Al conseguir un resultado cero, PostgreSQL asumir que el archivo se ha archivado con xito, y eliminar o reciclar. Sin embargo, un estado distinto de cero indica PostgreSQL que el archivo no ha sido archivada, sino que peridicamente vuelve a intentarlo hasta que lo consiga. El comando archive general debe estar diseado para negarse a sobrescribir cualquier archivo de almacenamiento pre-existente. Se trata de una importante medida de seguridad para preservar la integridad de su archivo en caso de error de administrador (por ejemplo, el envo de la salida de dos servidores diferentes en el mismo directorio de archivo). Es recomendable analizar su comando archive propuesta para garantizar que, efectivamente, no sobrescribe un archivo existente, y que devuelve el estado distinto de cero en este caso .El comando de ejemplo anterior para Unix asegura esto incluyendo un independiente
de
pruebas paso. En algunas plataformas Unix, cp tiene interruptores como -i que se pueden
utilizar para hacer la misma cosa menos ms detallados, pero que no debera confiar en ellos sin verificar que se devuelve el estado de salida de la derecha. (En particular, GNU cero cuando el estado
cp volver a
comportamiento deseado.) Si bien el diseo de su archivo de configuracin, tenga en cuenta lo que ocurrir si el comando archive falla repetidamente por algn aspecto requiere la intervencin del operador o el archivo se queda sin espacio. Por ejemplo, esto podra ocurrir si se escribe en cinta sin cambiador automtico, cuando la cinta se llena, nada ms puede ser archivado hasta que se cambia la cinta. Debe asegurarse de que cualquier condicin de error o solicitar a un operador humano se informa adecuadamente de modo que la situacin se puede resolver razonablemente rpido. El
pg_xlog / directorio seguir llenando con los archivos WAL segmento hasta que se pg_xlog
/ llena, PostgreSQL har una parada de pnico. No hay transacciones confirmadas se pierden,
pero la base de datos permanecer desconectado hasta que libere algo de espacio.)
La velocidad del comando de archivado no es importante, siempre y cuando pueda mantenerse al da con la tasa media a la que el servidor genera WAL datos. El funcionamiento normal contina incluso si el proceso de archivo se queda un poco atrs. Si el archivo se cae muy por detrs, esto aumentar la cantidad de datos que se perdera en caso de un desastre.Tambin significa que el
an no archivados, lo que eventualmente podra exceder el espacio disponible en disco. Se recomienda vigilar el proceso de archivo para asegurarse de que est funcionando como deseaba. Al escribir el comando archive, se debe asumir que los nombres de archivo del expediente pueden ser de hasta 64 caracteres de longitud y puede contener cualquier combinacin de letras ASCII, dgitos y puntos. No es necesario para preservar la ruta relativa original de ( es necesario para preservar el nombre del archivo (
% p ), pero
% F ).
Tenga en cuenta que aunque WAL archiving le permitir restaurar las modificaciones realizadas en los datos de su PostgreSQL base de datos, no restaurar los cambios realizados en los archivos de configuracin (es decir,
editado manualmente en lugar de a travs de las operaciones de SQL. Es posible que desee guardar los archivos de configuracin en un lugar que ser respaldada por los procedimientos de copia de seguridad del sistema de archivos regulares. Ver la seccin 18.2 para la forma de reubicar a los archivos de configuracin. El comando archive slo se invoca en cumplimentados segmentos WAL. Por lo tanto, si el servidor genera slo poco trfico WAL (o tiene perodos de inactividad que lo hace), no puede haber una larga demora entre la finalizacin de una transaccin y el seguro registro de almacenamiento de archivos. Para poner un lmite en cuanto pueden ser viejos datos sin archivar, puede establecer archive_timeout para forzar al servidor para cambiar a un nuevo archivo de segmentos WAL al menos tan a menudo. Tenga en cuenta que los archivos comprimidos que se archivan antes de tiempo debido a un cambio forzado siguen siendo la misma longitud que los archivos completamente llenos. Por tanto, es aconsejable establecer un tiempo muy cortoarchive_timeout - que inflar el almacenamiento de archivos.
quiere asegurarse de que una transaccin que acaba de concluir se archiva tan pronto como sea
posible. Otras funciones de utilidad relacionadas con la gestin WAL se enumeran en la Tabla 956 . Cuando
wal_level es mnimo algunos comandos SQL se optimizan para evitar WAL registro,
como se describe en la Seccin 14.4.7 . Si la replicacin archivo o streaming se enciende durante la ejecucin de una de estas declaraciones, WAL no contienen informacin suficiente para la recuperacin de archivos. (Recuperacin de golpes no se ve afectada.) Por esta razn,wal_level slo puede ser cambiado en el arranque del servidor. Sin embargo,
archive_command se puede cambiar con un archivo de configuracin de archive_command la cadena vaca ( '' ). Esto har que los archivos WAL se pg_xlog / hasta que un trabajoarchive_command se restablece.
acumulen en
donde
la etiqueta es cualquier cadena que desea utilizar para identificar la pg_start_backup crea backup_label , en el
operacin de copia de seguridad. (Una buena prctica es usar la ruta completa donde va a poner el archivo de volcado de copia de seguridad.)
directorio del clster con informacin acerca de la copia de seguridad, incluyendo la hora de inicio y la cadena de la etiqueta. No importa qu base de datos dentro de la agrupacin que se conecte a emitir este comando. Puede pasar por alto el resultado devuelto por la funcin, pero si se informa de un error, se ocupan de que antes de proceder. De forma predeterminada,
puesto de control se extender a lo largo de un perodo significativo de tiempo, de forma predeterminada la mitad de su intervalo inter-puesto de control (ver el parmetro de configuracincheckpoint_completion_target ). Esto suele ser lo que quieras, ya que minimiza el impacto en el procesamiento de consultas. Si desea iniciar la copia de seguridad tan pronto como sea posible, utilice:
Esto obliga al punto de control para hacer lo ms rpidamente posible. 4. Realizar la copia de seguridad, utilizando cualquier herramienta conveniente del sistema de archivos, copia de seguridad, tales como el alquitrn o cpio (no pg_dump o pg_dumpall ).No es ni necesario ni deseable que detenga el funcionamiento normal de la base de datos mientras lo hace. 5. Una vez ms conectarse a la base de datos como superusuario y ejecute el comando:
Esto termina el modo de copia de seguridad y realiza el cambio automtico al siguiente segmento WAL. La razn para el cambio es el de organizar para el ltimo segmento de archivo WAL escrita durante el intervalo de copia de seguridad para estar listo para archivar. 7. Una vez que los archivos segmento WAL activos durante la copia de seguridad se archivan, ya est. El archivo identificado por
ltimo segmento que se requiere para formar un conjunto completo de archivos de copia de seguridad. Si
que el ltimo segmento se ha archivado. Archivo de estos archivos sucede automticamente, puesto que ya ha configurado
de los casos esto sucede rpidamente, pero se recomienda para monitorear su sistema de archivo para garantizar que no haya retrasos. Si el proceso de archivo se ha retrasado debido a fallas del comando archive, que se mantendr hasta que el volver a intentar archivar correctamente y la copia de seguridad. Si usted desea poner un lmite
statement_timeout valor.
Tambin puede utilizar el pg_basebackup herramienta para tomar la copia de seguridad, en lugar de copiar los archivos manualmente. Esta herramienta va a hacer el equivalente depg_start_backup
transfiere la copia de seguridad ms de un habitual PostgreSQL conexin utilizando el protocolo de replicacin, en lugar de requerir acceso a nivel de sistema de archivos.
interfiere con las copias de seguridad de nivel de sistema de archivos tomadas conpg_start_backup
() / pg_stop_backup () .
Algunas herramientas de copia de seguridad del sistema de archivos emiten advertencias o errores si los archivos que estn tratando de copiar el cambio, mientras que los ingresos de la copia. Al tomar una copia de seguridad de base de datos activa, esta situacin es normal y no un error. Sin embargo, es necesario asegurarse de que puede distinguir las denuncias de este tipo de errores reales. Por ejemplo, algunas versiones de rsync devolver un cdigo de salida distinto de "archivos de origen desaparecidos" , y se puede escribir una secuencia de comandos de controlador para aceptar este cdigo de salida como un caso de no error. Adems, algunas versiones de GNU tar devuelven un cdigo de error indistinguible de un error fatal si un archivo se ha truncado, mientras que el alquitrn se copien. Afortunadamente, GNU tar versiones 1.16 y luego salen con 1 si un archivo ha cambiado durante la copia de seguridad, y 2 para otros errores. No es necesario preocuparse por la cantidad de tiempo transcurrido entre
copia de seguridad ypg_stop_backup , a pocos minutos de retraso no va a doler nada. (Sin embargo, si usted normalmente ejecuta el servidor con posible que note una disminucin en el rendimiento entre
efectivamente durante el modo de copia de seguridad.) Debe asegurarse de que se llevan a cabo estos pasos en orden, sin ningn posible solapamiento, para que no invalida la copia de seguridad. Asegrese de que el volcado de copia de seguridad incluye todos los archivos en el directorio del clster de base de datos (por ejemplo,
utilizando los espacios de tabla que no residen debajo de este directorio, tenga cuidado para
incluirlos tambin (y asegrese de que la copia de seguridad de volcado de archivos de los vnculos simblicos como enlaces, si la restauracin se daar sus espacios de tablas). Puede, sin embargo, omitir en el vertedero de copia de seguridad de los archivos dentro del cmulo
pg_xlog / subdirectorio. Este ligero ajuste es que vale la pena, ya que reduce el pg_xlog / es un enlace simblico
que apunta a algn lugar fuera del directorio de clster, que es una configuracin comn de todos modos por razones de rendimiento. Es posible que tambin desee excluir
funcionamiento del administrador de correo, no se trata del jefe de correos que eventualmente utilizar esta copia de seguridad. (Estos archivos pueden confundir pg_ctl .) Para hacer uso de la copia de seguridad, tendr que guardar todos los archivos de segmentos WAL generados durante y despus de la copia de seguridad del sistema de archivos. Para ayudarle a hacer esto, el
seguridad que se almacena inmediatamente en el rea de archivo WAL. Este archivo es el nombre del primer archivo de segmentos WAL que usted necesita para la copia de seguridad del sistema de archivos. Por ejemplo, si el archivo WAL partida es
0000000100001234000055CD el archivo histrico de copia de seguridad se llamar algo 0000000100001234000055CD.007C9330.backup . (La segunda parte del
as como
nombre del archivo representa una posicin exacta dentro del archivo WAL, y normalmente puede ser ignorada.) Una vez que se ha archivado con seguridad la copia de seguridad del sistema de archivos y los archivos de segmentos WAL utilizada durante la copia de seguridad (como se especifica en la historia de copia de seguridad archivo), todos los segmentos WAL archivados con nombres numricamente menos ya no son necesarios para recuperar la copia de seguridad del sistema de archivos y se pueden eliminar. Sin embargo, usted debe considerar mantener varios conjuntos de copia de seguridad para estar absolutamente seguro de que usted puede recuperar sus datos. El archivo histrico de copia de seguridad es slo un pequeo archivo de texto. Contiene la cadena de la etiqueta que le diste a
finalizacin y segmentos WAL de la copia de seguridad. Si ha utilizado la etiqueta para identificar el archivo de volcado asociada, el archivo histrico archivado es suficiente para decir que descarga archivos que desea restaurar.
Puesto que usted tiene que mantener alrededor de todos los archivos WAL archivados de nuevo a la copia de seguridad de base anterior, el intervalo entre las copias de seguridad de base por lo general debe ser elegido sobre la base de la cantidad de almacenamiento que desea gastar en los archivos WAL archivados. Tambin debe considerar el tiempo que est dispuesto a gastar en recuperacin, si fuese necesario la recuperacin - el sistema tendr que jugar de nuevo todos esos segmentos WAL, y que podra tomar un tiempo si ha pasado mucho tiempo desde la ltima copia de seguridad de base. Es tambin digno de mencin que el llamado por
pg_stop_backup .Este archivo, por supuesto, se archivar como parte de su archivo de pg_start_backup , as como el momento en
volcado de copia de seguridad. El archivo de copia de seguridad de la etiqueta incluye la cadena de la etiqueta que le diste a que
confusin por lo que es posible mirar dentro de un archivo de volcado de copia de seguridad y determinar exactamente qu sesin de copia de seguridad del archivo de volcado de vino. Tambin es posible hacer un volcado de copia de seguridad, mientras que el servidor est detenido. En este caso, es obvio que no se puede utilizar
recursos para realizar un seguimiento de los que descarga copia de seguridad es cul y cun atrs los archivos WAL asociados van. En general, es mejor seguir el procedimiento de archivo continuo por encima.
agrupacin
archivadas antes de que el sistema se puso. 3. Elimine todos los archivos y subdirectorios existentes en el directorio de datos de clster y en los directorios raz de los espacios de tablas que utiliza. 4. Restaurar los archivos de base de datos desde la copia de seguridad del sistema de archivos. Asegrese de que se restauran con el derecho de propiedad (el usuario del sistema de base de datos, no
utilizando los espacios de tabla, debe verificar que los enlaces simblicos en
de seguridad del sistema de archivos y por lo tanto probablemente obsoleto y no actual. Si no lo hizo archivo
adecuados, teniendo cuidado de asegurarse de que se vuelva a establecerlo como un enlace simblico si tuviera que establecer de esa manera antes. 6. Si ha desarchivar archivos segmentos WAL que guard en el paso 2, copiarlos en
archivos no modificados si se produce un problema y hay que empezar de nuevo.) 7. Crear una orden de recuperacin de archivos
recovery.conf en el directorio de
datos de cluster (ver Captulo 26 ). Es posible que tambin desee modificar temporalmentepg_hba.conf para evitar que usuarios ordinarios de la conexin hasta que est seguro que la recuperacin se ha realizado correctamente. 8. Inicie el servidor. El servidor se pondr en modo de recuperacin y proceda a leer a travs de los archivos WAL archivados que necesita. Si la recuperacin se termin debido a un error externo, el servidor slo se puede reiniciar y continuar la recuperacin. Una vez finalizado el proceso de recuperacin, el servidor se cambie el nombre
volver a entrar accidentalmente ms adelante) y luego comenzar las operaciones normales de la base de datos.
9. Inspeccione el contenido de la base de datos para asegurarse de que se haya recuperado el estado deseado. Si no es as, vuelva al paso 1. Si todo est bien, permitir que los usuarios se conecten mediante la restauracin de
pg_hba.conf a la normalidad.
La parte clave de todo esto es la creacin de un archivo de configuracin de recuperacin que describe cmo desea recuperar y en qu medida la recuperacin debe ejecutarse. Usted puede utilizar
recovery.confes la restore_command , que narra PostgreSQL cmo recuperar archive_command , esto es una % f , que se sustituye por el nombre del archivo de
segmentos de archivo WAL archivados. Al igual que el cadena de comandos shell. Puede contener registro deseado y
p% , que se reemplaza por el nombre de la ruta para copiar el archivo de %% si necesita integrar un verdadero % personaje en el
registro. (El nombre de la ruta es relativa al directorio de trabajo actual, es decir, el directorio de datos de la agrupacin.) Escriba
/ mnt / server /
archivedir . Por supuesto, usted puede utilizar algo mucho ms complicado, tal vez incluso
un script de shell que solicita al operador que monte una cinta apropiada. Es importante que el comando devuelve el cdigo de salida distinto de cero en caso de fallo. El comando se puede llamar solicitando los archivos que no estn presentes en el archivo, debe devolver cero si le fuera solicitada. Esto no es una condicin de error. No todos los archivos solicitados sern los archivos WAL segmento, tambin se debe esperar que las peticiones de archivos con un sufijo de
copia de seguridad. o historia. . Tambin tenga en cuenta p% ruta ser diferente de % f , no espere que sean
pg_xlog / , lo que
permite el uso de segmentos sin archivados recientes. Sin embargo, los segmentos que estn disponibles en el archivo sern utilizados en preferencia a los archivos en sistema no sobrescribe el contenido existente de archivados.
pg_xlog / . El
Normalmente, la recuperacin se proceder a travs de todos los segmentos WAL disponibles, restaurando as la base de datos para el punto actual en el tiempo (o tan cerca como sea posible dados los segmentos WAL disponibles). Por lo tanto, una recuperacin normal terminar con un "archivo no encontrado" mensaje, el texto exacto del mensaje de error, dependiendo de su eleccin de
restore_command . Tambin puede aparecer un mensaje de error en el inicio de 00000001.history . Esto tambin es
normal y no indica un problema en situaciones de recuperacin simples, vase la seccin 24.3.4 para el debate. Si desea recuperar a un punto anterior en el tiempo (por ejemplo, justo antes de la DBA Junior dej la mesa principal de la transaccin), basta con especificar el punto final deseado enrecovery.conf . Puede especificar el punto de detencin, conocido como el "objetivo de recuperacin" , ya sea por fecha / hora, el nombre de punto de restauracin o terminacin de un ID de transaccin especfica. Al escribir estas lneas slo la fecha / hora y el nombre restaurar opciones de punto son muy tiles, ya que no existen herramientas para ayudar a identificar con precisin qu transaccin ID de usar. Nota: El punto de parada debe ser despus de la hora de finalizacin de la copia de seguridad de base, es decir, la hora de finalizacin de
de seguridad de base de recuperar a una poca en que la copia de seguridad est en curso. (Para recuperar a tal hora, debe volver a la copia de seguridad de base anterior y avanzar desde all.) Si la recuperacin se encuentra daado WAL datos, la recuperacin se detendr en ese punto y el servidor no se iniciar. En tal caso, el proceso de recuperacin se puede volver a ejecutar desde el principio, la especificacin de un "objetivo de recuperacin" antes de que el punto de la corrupcin por lo que la recuperacin puede completar normalmente. Si la recuperacin falla por una razn externa, tal como un fallo del sistema o si el archivo WAL se ha convertido en inaccesible, a continuacin, la recuperacin puede simplemente ser reiniciado y se reiniciar casi desde donde ha fallado. Reinicio de recuperacin funciona como puntos de control durante el funcionamiento normal: el servidor obliga peridicamente todo el estado en el disco, y luego actualiza el
pg_control archivo para indicar que los datos ya WAL-procesados no tienen que
grandes). Usted puede, si lo desea, agregar comentarios a un archivo histrico para grabar tus propias notas acerca de cmo y por qu esta lnea de tiempo en particular fue creado. Dichos comentarios sern especialmente valiosas cuando se tiene una espesura de diferentes lneas de tiempo, como resultado de la experimentacin. El comportamiento predeterminado de la recuperacin es la recuperacin a lo largo de la misma lnea de tiempo que estaba vigente cuando se realiz la copia de seguridad base. Si desea recuperar en alguna lnea de tiempo menor (es decir, desea volver a un estado que era a su vez generan despus de un intento de recuperacin), es necesario especificar el ID de la lnea de tiempo de destino en
wal_level de archivo (o hot_standby ), archive_mode a el , y archive_command que realiza el archivado slo cuando un archivo de
establecer un
prueba archive_command = '! -F / var / lib / pgsql / backup_in_progress | | (prueba!-F / var / lib / pgsql / archive /% && cp f% p / var / lib / pgsql / archive /% f) '
Con esta preparacin, una copia de seguridad se pueden tomar utilizando un script como el siguiente:
touch / var / lib / pgsql / backup_in_progress psql-c "select pg_start_backup ('hot_backup');" tar-cf / var / lib / pgsql / backup.tar / var / lib / pgsql / data / psql-c "select pg_stop_backup ();" rm / var / lib / pgsql / backup_in_progress tar-rf / var / lib / pgsql / backup.tar / var / lib / pgsql / archivo /
El archivo de cambio de
por primera vez, lo que permite el archivado de ficheros WAL terminados que se produzca. Despus de la copia de seguridad se elimina el archivo de cambio. Archivos WAL archivados se aaden a continuacin a la copia de seguridad de manera que tanto copia de seguridad base y todos los archivos WAL requeridos son parte de la misma alquitrn de archivo. Por favor recuerde agregar el control de errores de secuencias de comandos de copia de seguridad.
archive_command Scripts
El uso de un archivo de script independiente se recomienda cada vez que quiera usar ms de un comando en el proceso de archivo. Esto permite que todas complejidad a ser gestionado en el guin, que se puede escribir en un lenguaje de scripting populares como fiesta o perl . Ejemplos de requisitos que pueden ser resueltos dentro de un script son:
Copia de datos para garantizar el almacenamiento de datos fuera del sitio Procesamiento por lotes archivos WAL para que se transfieren cada tres horas, en lugar de una a la vez
Interfaz con otro software de respaldo y recuperacin Interfaz con software de monitoreo para informar de errores
permitirlogging_collector . Los mensajes escritos en stderr desde el guin y luego aparecer en el registro del servidor de base de datos, lo que permite configuraciones complejas para ser diagnosticados fcilmente si fallan.
24.3.6. Advertencias
En este escrito, hay varias limitaciones de la tcnica archivado continua. Estos probablemente fijarse en futuras versiones:
Operaciones en ndices hash no son actualmente WAL-registran, por lo replay no se actualizarn estos ndices. Esto significa que las nuevas inserciones sern ignorados por
el ndice, las filas actualizadas aparentemente desaparecer y registros borrados todava retendrn punteros. En otras palabras, si se modifica una tabla con un ndice hash en l por lo que recibir los resultados de consultas incorrectos en el servidor en espera. Cuando se complete la recuperacin, se recomienda que usted manualmente indexar cada uno de estos ndices despus de completar una operacin de recuperacin.
Si un CREATE DATABASE se ejecuta el comando mientras se realiza una copia de seguridad de base, y luego la base de datos de plantilla que el
CREATE
CREATE TABLESPACE comandos se WAL-registrados con la ruta absoluta literal, y por lo tanto se reproducirn de la creacin de espacios de tablas con la misma ruta absoluta. Esto puede ser indeseable si el registro se est reproduciendo en un equipo diferente. Puede ser peligroso incluso si el registro se est reproduciendo en el mismo equipo, pero en un directorio de datos nueva: la repeticin todava sobrescribir el contenido del espacio de tablas originales. Para evitar posibles trampas de este tipo, lo mejor es tomar una nueva copia de seguridad base despus de crear o quitar espacios de tabla.
Tambin hay que sealar que el valor predeterminado WAL formato es bastante voluminoso, ya que incluye muchas pginas instantneas de disco. Estas instantneas pginas estn diseadas para apoyar la recuperacin del accidente, ya que puede ser que necesite para arreglar pginas de disco parcialmente escrito. Dependiendo de su hardware y software del sistema, el riesgo de parcial escribe podra ser lo suficientemente pequeo como para pasar por alto, en cuyo caso se puede reducir significativamente el volumen total de registros archivados apagando instantneas de pgina utilizando el full_page_writes parmetro. (Lea las notas y avisos en el captulo 29 antes de hacerlo.) Desactivar Pgina instantneas no impide el uso de los registros de operaciones Pitr. Un espacio para el desarrollo futuro es el de comprimir los datos WAL archivados mediante la eliminacin de pginas copias innecesarias, incluso cuando
desear reducir el nmero de pgina instantneas incluidas en WAL mediante el aumento de los parmetros de intervalo de punto de control tanto como sea posible.
de todos los casos de uso, hay varias soluciones. Cada solucin aborda este problema de una manera diferente, y reduce al mnimo su impacto para una carga de trabajo especfica. Algunas de las soluciones frente a la sincronizacin, permitiendo slo un servidor para modificar los datos. Los servidores que pueden modificar los datos se denominan de lectura / escritura, maestros o primarios servidores. Los servidores que rastrean cambios en el master se llaman en espera o esclavo servidores. Un servidor de reserva que no se puede conectar a hasta que se promueve a un servidor maestro se llama espera activa del servidor, y que puede aceptar conexiones y atiende consultas de slo lectura que se llama una espera activaservidor. Algunas soluciones son sncronas, lo que significa que una transaccin de datos de modificacin no se considera cometido hasta que todos los servidores se han comprometido la transaccin. Esto garantiza que la conmutacin por error no se perdern los datos y de que todos los servidores de carga equilibrada que proporcione resultados consistentes sin importar que se consulta servidor. Por el contrario, las soluciones asncronas permiten un cierto retraso entre el momento de la confirmacin y su propagacin al resto de servidores, abriendo la posibilidad de que algunas transacciones se pueden perder en el cambio a un servidor de copia de seguridad, y que los servidores de equilibrio de carga podran devolver resultados ligeramente rancio. La comunicacin asncrona se utiliza cuando sncrono sera demasiado lento. Las soluciones tambin se pueden clasificar por su granularidad. Algunas soluciones pueden tratar slo con un servidor de base de datos completa, mientras que otros permiten el control a nivel per-mesa o por base de datos. Rendimiento debe ser considerado en cualquier eleccin. Normalmente hay un equilibrio entre la funcionalidad y el rendimiento. Por ejemplo, una solucin totalmente sincronizada en una red lenta podra reducir el rendimiento en ms de la mitad, mientras que un asncrono uno podra tener un impacto mnimo en el rendimiento. El resto de esta seccin se describen varios de conmutacin por error, la replicacin y soluciones de equilibrio de carga. Un glosario tambin est disponible.
compartida por varios servidores. Si el servidor de base de datos principal falla, el servidor de reserva es capaz de montar e iniciar la base de datos como si estuviera recuperando de un accidente de base de datos. Esto permite una rpida recuperacin de fallos sin prdida de datos. Funcionalidad de hardware compartido es comn en los dispositivos de almacenamiento en red. El uso de un sistema de archivos de red tambin es posible, aunque se debe tener cuidado de que el sistema de archivos tiene plena POSIX comportamiento (ver seccin 17.2.1 ). Una limitacin significativa de este mtodo es que si la matriz de disco compartido falla o se corrompe, los servidores primarios y de reserva son tanto no funcional. Otro problema es que el servidor de reserva no debe acceder al almacenamiento compartido, mientras que el servidor principal se est ejecutando. Sistema de replicacin de archivos (Block-Device) Una versin modificada de la funcionalidad del hardware compartido es la replicacin del sistema de archivos, donde todos los cambios en un sistema de archivos se reflejan en un sistema de archivos que residen en otro equipo. La nica restriccin es que la duplicacin se debe hacer de una manera que asegura el servidor de reserva tiene una copia consistente del sistema de archivos -. Especficamente, escribe a la espera de que se debe hacer en el mismo orden que las del maestro DRBD es un popular solucin de replicacin del sistema de archivos de Linux. Standby Uso Recovery Point-In-Time clido y caliente ( PITR ) Servidores de reserva templadas y calientes pueden estar al da mediante la lectura de una secuencia de registro write-ahead ( WAL registros). Si el servidor principal falla, el modo de espera contiene casi la totalidad de los datos del servidor principal, y puede ser rpidamente hizo el nuevo servidor de base de datos maestra. Esta es asncrono y slo se puede hacer para todo el servidor de base de datos. Un servidor de reserva PITR puede ser implementado usando el envo basado en archivos de registro ( Seccin 25.2 ) o la replicacin de secuencias (ver Seccin 25.2.5 ), o una combinacin de ambos. Para obtener informacin sobre Hot Standby, consulte la Seccin 25.5 . Gatillo Replicacin basada en Maestro de espera
Una configuracin de replicacin maestro-standby enva todas las peticiones de modificacin de datos en el servidor maestro. El servidor maestro enva de forma asincrnica cambios de datos al servidor de reserva. La espera puede responder a consultas de slo lectura, mientras que el servidor maestro est en ejecucin. El servidor de reserva es ideal para las consultas de almacenamiento de datos. SlonyI es un ejemplo de este tipo de replicacin, con granularidad para cada tabla, y soporte para mltiples servidores de reserva. Porque se actualiza el servidor en espera de forma asncrona (por lotes), no es posible la prdida de datos durante la conmutacin por error. Middleware replicacin Declaracin basada en Con la declaracin basada en middleware de replicacin, intercepta un programa cada consulta SQL y enva a uno o todos los servidores. Cada servidor funciona de forma independiente. Leer-escribir las consultas deben ser enviadas a todos los servidores, por lo que cada servidor recibe cualquier cambio. Pero consultas de slo lectura pueden ser enviados a un solo servidor, lo que permite la carga de trabajo de lectura se distribuye entre ellos. Si las consultas son simplemente transmiten sin modificaciones, funciona como
valores diferentes en diferentes servidores. Esto es debido a que cada servidor funciona de forma independiente, y porque las consultas SQL se emiten (y no filas modificadas reales). Si esto no es aceptable, ya sea del middleware o de la aplicacin deben consultar estos valores de un nico servidor y luego utilizar esos valores en las consultas de escritura. Otra opcin es utilizar esta opcin de replicacin con una configuracin maestro-standby tradicional, es decir, las consultas de modificacin de datos slo se envan al maestro y se propagan a los servidores de reserva a travs de la replicacin maestro-espera, no por el middleware de replicacin. Tambin se debe procurar que todas las transacciones ya sea confirmar o anular en todos los servidores, tal vez utilizando dos fases ( PREPARE TRANSACCIN y COMMIT PREPARADO . pgPoolII y tungsteno Continuent son ejemplos de este tipo de replicacin. Replicacin asncrona multimaestro Para los servidores que no estn conectados habitualmente, como ordenadores porttiles o servidores remotos, manteniendo los datos consistentes entre servidores es un
reto.Mediante la replicacin asncrona multimaestro, cada servidor funciona de forma independiente, y se comunica peridicamente con el resto de servidores para identificar transacciones conflictivas. Los conflictos pueden ser resueltos por los usuarios o las reglas de resolucin de conflictos. Bucardo es un ejemplo de este tipo de replicacin. Synchronous replicacin Multimaster En la replicacin de varios sncrono, cada servidor puede aceptar solicitudes de escritura, y los datos modificados se transmiten desde el servidor original para cada servidor antes de que acabe la transaccin. Actividad de escritura en exceso puede producir un bloqueo excesivo, lo que lleva a un mal desempeo. De hecho, el rendimiento de escritura es a menudo peor que la de un solo servidor. Leer solicitudes pueden enviarse a cualquier servidor. Algunas implementaciones usan disco compartido para reducir la sobrecarga de comunicacin.Replicacin sncrona multimaestro es mejor para las cargas de trabajo sobre todo leer, aunque su gran ventaja es que cualquier servidor puede aceptar solicitudes de escritura - no hay necesidad de cargas de trabajo de particin entre el maestro y servidores de reserva, y debido a que los cambios en los datos se envan desde un servidor a otro, existe hay ningn problema con funciones no deterministas como
aleatorio () .
PostgreSQL no ofrece este tipo de replicacin, aunque PostgreSQL en dos fases ( PREPARE TRANSACCIN y COMMIT PREPARADA ) se puede utilizar para implementar esto en cdigo de aplicacin o middleware. Soluciones Comerciales Debido a PostgreSQL es de cdigo abierto y ampliar fcilmente, una serie de empresas han tomado PostgreSQL y ha creado soluciones de cdigo cerrado comerciales con conmutacin por error nico, replicacin y capacidades de balanceo de carga. Tabla 25-1 resume las capacidades de las distintas soluciones mencionadas anteriormente. Tabla 25-1. Alta disponibilidad, balanceo de carga y la matriz de funciones de replicacin
Calie Gatillo Middlew Conmutac nte / Replicac are Synchron Replicac Replicaci in por calien in replicaci ous in del n Caracters error de te basada n replicaci sistema asncrona tica disco PITR en Declarac n de multimae compartid Uso Maestro in Multimas archivos stro o Stand de basada ter by espera en
La aplicacin ms comn
NAS
DRBD
PITR
Slony
pgpool-II
Bucardo
WAL
filas de la tabla
SQL
filas de la tabla
Calie Gatillo Middlew Conmutac nte / Replicac are Synchron Replicac Replicaci in por calien in replicaci ous in del n Caracters error de te basada n replicaci sistema asncrona tica disco PITR en Declarac n de multimae compartid Uso Maestro in Multimas archivos stro o Stand de basada ter by espera en
Calien te slo
Hay algunas soluciones que no encajan en las categoras anteriores: Particin de datos Particin de datos divide las tablas en los conjuntos de datos. Cada conjunto puede ser modificado por un solo servidor. Por ejemplo, los datos pueden ser divididos por las oficinas, por ejemplo, Londres y Pars, con un servidor en cada oficina. Si las consultas
que combinan datos de Londres y Pars son necesarias, una aplicacin puede consultar los servidores, o maestro / rplica de espera se puede utilizar para guardar una copia de slo lectura de los datos de la otra oficina en cada servidor. Ejecucin de consultas en paralelo de mltiples servidores Muchas de las soluciones anteriores permiten varios servidores para manejar mltiples consultas, pero no permiten que una sola consulta de utilizar varios servidores para terminar ms rpido. Esta solucin permite que varios servidores funcionen simultneamente en una sola consulta. Por lo general, se lleva a cabo mediante el fraccionamiento de los datos entre los servidores y que tiene cada servidor de ejecutar su parte de la consulta y devolver los resultados a un servidor central en el que se combinan y se devuelven al usuario.pgPool-II tiene esta capacidad. Adems, esto puede ser implementado utilizando el PL / Proxy conjunto de herramientas.
del servidor principal. El trasvase de registros basados en registros es ms granular y arroyos WAL cambia gradualmente en una conexin de red (consulte la seccin 25.2.5 ). Cabe sealar que el trasvase de registros es asncrona, es decir, los registros WAL se envan despus de confirmacin de la transaccin. Como resultado, hay una ventana para la prdida de datos si el servidor principal sufrir un fallo catastrfico; transacciones an no enviados se perdern. El tamao de la ventana de la prdida de datos en el envo de registro basado en archivos puede ser limitada mediante el uso de la
puede ajustar tan bajo como unos pocos segundos. Sin embargo, un tal ambiente de bajos aumentar sustancialmente el ancho de banda necesario para el envo de archivos. Transmisin de replicacin (ver Seccin 25.2.5 ) permite una ventana ms pequea de prdida de datos. Rendimiento de recuperacin es lo suficientemente bueno que la espera ser tpicamente a pocos minutos de la plena disponibilidad una vez que ha sido activado. Como resultado, esto se llama una configuracin en espera activa, que ofrece una alta disponibilidad. Restauracin de un servidor desde una copia de seguridad de base de archivado y recuperacin en avance tomar mucho ms tiempo, por lo que la tcnica slo ofrece una solucin para la recuperacin de desastres, no de alta disponibilidad. Un servidor de reserva tambin puede ser utilizado para consultas de slo lectura, en cuyo caso se denomina un servidor de Hot Standby. Ver la Seccin 25.5 para ms informacin.
25.2.1. Planificacin
Por lo general, es aconsejable para crear los servidores primarios y de reserva de modo que sean tan similares como sea posible, al menos desde el punto de vista del servidor de base de datos. En particular, se pasarn los nombres de las rutas asociadas a travs de espacios de tabla sin modificar, por lo que los dos servidores primario y de reserva deben tener las mismas rutas de acceso para los espacios de tabla, si se utiliza esta funcin. Tenga en cuenta que si CREATE TABLESPACE se ejecuta en la primaria, cualquier nuevo punto de montaje necesarios para ello se debe crear en el primario y todos los servidores en espera antes de ejecutar el comando. Hardware no necesita ser exactamente la misma, pero la experiencia demuestra que el mantenimiento de dos sistemas idnticos es ms fcil que el mantenimiento de los dos diferentes durante la vida til de la aplicacin y del sistema. En cualquier caso, la arquitectura de hardware debe ser el mismo - el envo de, por ejemplo, de 32 bits en un sistema de 64 bits no funcionar.
En general, el trasvase de registros entre servidores que ejecutan diferentes grandes PostgreSQL niveles de liberacin no es posible. Es poltica del Grupo Global de Desarrollo de PostgreSQL no hacer cambios a los formatos de disco durante las actualizaciones de versin menor, por lo que es probable que la ejecucin de los diferentes niveles de liberacin de menores en los servidores principal y de reserva funcionar correctamente. Sin embargo, no se ofrece soporte formal para ello y se aconseja mantener los servidores principal y de reserva, al mismo nivel de release tanto como sea posible. Al actualizar a una nueva versin de menor importancia, la poltica ms segura es actualizar los servidores en espera primero - es ms probable que sea capaz de leer archivos WAL de una versin secundaria anterior a la inversa una nueva versin menor.
pg_xlogdirectorio. Esto normalmente ocurre despus de reiniciar el servidor, cuando pg_xlog en cualquier
las repeticiones en espera de nuevo WAL que se transmiten desde el maestro antes de la reanudacin, pero tambin se puede copiar manualmente los archivos de momento para que ellos reproducen. En el inicio, la espera comienza restaurando todas WAL disponible en la ubicacin del archivo, llamando
pg_xlog directorio. Si eso no funciona, y la reproduccin de streaming se ha configurado, el pg_xlog . Si eso no funciona o replicacin de
modo en espera intenta conectar con el servidor principal y empezar a transmitir WAL desde el ltimo registro vlido encontrado en el archivo o
streaming no est configurado, o si la conexin se desconecta despus, la espera se remonta al paso 1 e intenta restaurar el archivo desde el archivo de nuevo. Este bucle de reintentos del archivo,
servidor o la conmutacin por error es provocado por un archivo de activacin. El modo de espera se sale y el servidor cambia a la operacin normal cuando
pg_ctl
pg_xlog ser restaurado, pero no se hace ningn intento de conectar con el maestro.
en un valor lo suficientemente grande en el archivo de configuracin del servidor principal. Lleve una copia de seguridad de base como se describe en la Seccin 24.3.2 para arrancar el servidor en espera.
Standby_mode . Establecer restore_command a un simple comando para copiar recovery_target_timeline a ms tardar , para que
archivos desde el archivo WAL. Si usted planea tener mltiples servidores en espera para fines de alta disponibilidad, configure
el servidor en espera siga el cambio que se produce en la lnea de tiempo de conmutacin por error a otro modo de espera. Nota: No utilice herramientas pg_standby o similar con la incorporada en el modo de espera descrito aqu.
servidor volver a intentar el comando de nuevo si es necesario. Consulte la Seccin 25.4 para el uso de herramientas como pg_standby.
conexin libpq, incluyendo el nombre de host (o direccin IP) y cualquier informacin adicional necesaria para conectar con el servidor primario. Si el principal necesita una contrasea para la autenticacin, la contrasea se debe especificar en
primary_conninfo tambin.
Si est configurando el servidor de reserva para fines de alta disponibilidad, configure WAL archiving, las conexiones y la autenticacin como el servidor principal, ya que el servidor de reserva funcionar como servidor primario despus de la conmutacin por error. Si utiliza un archivo WAL, su tamao puede ser minimizado mediante el archive_cleanup_command parmetro para eliminar archivos que ya no son requeridos por el servidor en espera. Elpg_archivecleanup utilidad est diseada especficamente para ser utilizado con
consulte pg_archivecleanup .Tenga en cuenta sin embargo, que si usted est utilizando el archivo como copia de seguridad, es necesario mantener los archivos necesarios para recuperarse de, al menos, la ltima copia de seguridad de base, incluso si ya no son necesarios por la espera. Un ejemplo sencillo de un
recovery.conf es:
Standby_mode = "on" primary_conninfo = 'host = 192.168.1.50 port = 5432 user = password = foo foopass' restore_command = 'cp / ruta / al / archivo /% f% p' archive_cleanup_command = 'pg_archivecleanup / ruta / al / archivo% r'
Puede tener cualquier nmero de servidores de reserva, pero si se utiliza la replicacin de streaming, asegrese de que establece
principal, que corrientes de registros WAL a la espera a medida que se generan, sin esperar a que el archivo WAL para ser llenado. Transmisin de replicacin es asncrona de forma predeterminada (ver seccin 25.2.6 ), en cuyo caso hay un pequeo retraso entre confirmar una transaccin en la primaria y los cambios a ser visible en el modo de espera. Este retraso es sin embargo mucho menor que con archivo basado en el trasvase de registros, por lo general menos de un segundo asumiendo la espera es lo suficientemente potente como para mantenerse al da con la carga. Gracias a la transmisin de replicacin,
Si utiliza la replicacin de streaming sin basados en archivos continuos archivo, usted tiene que fijar
garantizar que los viejos segmentos WAL no se reciclan antes de tiempo, mientras que la espera podra todava necesita ponerse al da. Si la reserva se retrasa demasiado, tiene que ser reinstaladas de una nueva copia de seguridad base. Si configura un archivo WAL que se puede acceder desde el modo de espera,
siempre se puede utilizar el archivo para ponerse al da. Para usar la replicacin streaming, configurar un servidor de reserva trasvase de registros basados en archivos como se describe en la Seccin 25.2 . El paso que convierte a un modo de espera trasvase de registros basada en archivos en streaming de espera de replicacin est estableciendo
25.2.5.1 ). En los sistemas que apoyan la opcin de socket keepalive, estableciendo tcp_keepalives_idle , tcp_keepalives_interval y tcp_keepalives_count ayuda a la primaria notan rpidamente una conexin rota. Establecer el nmero mximo de conexiones simultneas de los servidores en espera (vase max_wal_senders para ms detalles). Cuando se inicia el modo de espera y
espera se conectar a la primaria despus de reproducir todos los archivos WAL disponibles en el
archivo. Si la conexin se establece con xito, usted ver un proceso walreceiver en el modo de espera, y un proceso walsender correspondiente en la primaria.
25.2.5.1. Autenticacin
Es muy importante que los privilegios de acceso para la replicacin pueden configurar para que slo los usuarios de confianza pueden leer la corriente de WAL, ya que es fcil de extraer informacin confidencial de la misma. Servidores de reserva deben autenticarse en el principal como una cuenta que tenga el losREPLICACIN y
Nota: Se recomienda que una cuenta de usuario dedicada se usa para la replicacin.Mientras que el
REPLICACION se concede el privilegio de cuentas de superusuario de forma REPLICACION privilegio otorga permisos muy altos, que no permite al usuario SUPERUSUARIO privilegio hace. pg_hba.conf registro
la replicacin en la base de datos de campo. Por ejemplo, si la espera 192.168.1.100 y el nombre de cuenta para la replicacin
primario:
# Permitir que el usuario "foo" desde el host 192.168.1.100 para conectarse a la primaria # Como espera la replicacin si la contrasea del usuario se suministra correctamente. # # TIPO DE BASE DE DATOS DE USUARIO MTODO DIRECCIN host de replicacin foo 192.168.1.100/32 md5
El nombre de host y nmero de puerto del, nombre de usuario de la conexin principal, y la contrasea se especifican en el configurar en el
foo , y la contrasea es foopass , el administrador puede aadir la siguiente lnea a recovery.conf archivo en el modo de espera:
# La espera se conecta al primario que est ejecutando en el host 192.168.1.50 # Y el puerto 5432 como el usuario "foo", cuya contrasea es "foopass". primary_conninfo = 'host = 192.168.1.50 port = 5432 user = password = foo foopass'
25.2.5.2. Monitoreo
Un indicador importante de la salud de la reproduccin de streaming es la cantidad de registros WAL generado en la primaria, pero an no se aplica en el modo de espera. Se puede calcular este retraso comparando la posicin actual de escritura WAL en la primaria con la ltima ubicacin WAL recibida por la espera. Ellos pueden ser recuperados utilizandopg_current_xlog_location en la primaria y la
Tabla 9-56 y Tabla 9-57 para ms detalles). La ltima WAL ubicacin de recepcin en el modo de espera tambin se muestra en el estado de proceso del proceso receptor WAL, aparece con el
Usted puede obtener una lista de los procesos WAL remitente a travs del
pg_stat_replication vista. Las grandes diferencias pg_current_xlog_location y sent_location campo podran indicar que el sent_location y pg_last_xlog_receive_location en el modo de espera
entre
servidor maestro tiene mucha carga, mientras que las diferencias entre
podran indicar retraso de la red, o que la espera est bajo carga pesada.
Replicacin sncrona ofrece la posibilidad de confirmar que todos los cambios realizados por la transaccin han sido transferidos a un servidor en espera sncrona. Esto ampla el nivel estndar de durabilidad que ofrece una confirmacin de transaccin. Este nivel de proteccin se conoce como replicacin de 2-seguro en la teora de la informtica. Al solicitar la replicacin sincrnica, cada confirmacin de una transaccin de escritura va a esperar hasta que se recibe la confirmacin de que el compromiso se ha escrito en el registro de transacciones en el disco tanto el servidor primario y standby. La nica posibilidad de que los datos se pueden perder si es tanto el primario y el modo de espera sufren choques al mismo tiempo. Esto puede proporcionar un nivel mucho ms alto de durabilidad, aunque slo si el administrador de sistemas es cauteloso acerca de la ubicacin y la gestin de los dos servidores.Esperando confirmacin aumenta la confianza del usuario que los cambios no se perdern en caso de cada del servidor pero tambin necesariamente aumenta el tiempo de respuesta de la transaccin solicitante. El tiempo mnimo de espera es el tiempo de ida y vuelta entre el primario al standby. Leer slo las transacciones y revierte transacciones no tienen que esperar para las respuestas de los servidores de reserva. Subtransaccin compromete no espere a que las respuestas de los servidores en espera, slo de nivel superior comete. Acciones de larga ejecucin, como la carga de datos o edificio ndice no esperan a que el mensaje de confirmacin muy final.Todas las acciones de ejecucin en dos fases requieren commit espera, tanto preparar y cometer.
hay cambios. Esta configuracin har que cada comprometerse a esperar la confirmacin de que la espera ha escrito el registro de confirmacin de almacenamiento duradero, incluso si eso lleva mucho tiempo.
lo que se pueden configurar en el archivo de configuracin, para determinadas usuarios o bases de datos, o dinmicamente las aplicaciones, con el fin de controlar la garanta de durabilidad en una base por transaccin. Despus de un registro de confirmacin se ha escrito en el disco en el primario, el registro WAL se enva a la espera. La espera enva mensajes de respuesta cada vez que un nuevo lote de WAL
en el modo de espera. Si la reserva es el primer juego de espera, como se especifica ensynchronous_standby_names en la primaria, los mensajes de respuesta de esa espera se utilizarn para despertar los usuarios en espera de la confirmacin de que el registro de confirmacin se ha recibido. Estos parmetros permiten al administrador especificar qu servidores de reserva deben ser standbys sncronas. Tenga en cuenta que la configuracin de la replicacin sncrona es principalmente en el maestro. Los usuarios podrn dejar de esperar si se solicita un cierre rpido. Sin embargo, como cuando se utiliza la replicacin asincrnica, el servidor no apaga completamente hasta que todos los registros WAL pendientes se transfieren a los servidores de reserva conectados actualmente.
Debe tener en cuenta que el ancho de banda de la red debe ser superior a la tasa de generacin de datos de WAL.
de espera de sincronizacin responde. La respuesta no puede ocurrir si el ltimo o nico de espera debe bloquearse. La mejor solucin para evitar la prdida de datos es asegurarse de que no pierda su ltimo reposo sincronizacin restante. Esto se puede lograr por nombrar mltiples potenciales recursos seguros sincrnicas utilizando
espera se puede utilizar como el modo de espera sncrono. Standbys enumeran en la siguiente se har cargo de la funcin de espera sncrono si el primero falla. Cuando una reserva primero se une a la primaria, no va a ser an adecuadamente sincronizado. Esto se describe como
primaria llega a cero por primera vez nos trasladamos a tiempo real de
el
streaming estado.
Si se reinicia primarios mientras cometa, est a la espera de confirmacin de las transacciones de espera sern marcados plenamente comprometidos una vez que la base de datos principal se recupere. No hay manera de estar seguro de que todas las cartas de crdito se han recibido todos los datos de WAL en circulacin al momento de la cada de las primarias.Algunas operaciones pueden no mostrar tan comprometido en el modo de espera, a pesar de que muestran tan comprometido en la primaria. La garanta que ofrecemos es que la aplicacin no recibir reconocimiento explcito de la confirmacin exitosa de una transaccin hasta que se conozca los datos WAL para ser recibido con seguridad por la espera. Si usted realmente pierde su ltimo servidor de reserva, entonces debera desactivar
el servidor principal.
Si el principal est aislado del resto de servidores de reserva que debe conmutar por error a los mejores candidatos de los otros servidores de reserva restantes. Si tiene que volver a crear un servidor de reserva, mientras que las transacciones estn a la espera, asegrese de que los comandos se ejecuten pg_start_backup () y pg_stop_backup () se ejecutan en una sesin con
25.3. Failover
Si el servidor principal falla, entonces el servidor de reserva debe comenzar procedimientos de conmutacin por error. Si el servidor de reserva falla, entonces no necesita tener lugar la conmutacin por error. Si el servidor en espera se puede reiniciar, incluso algn tiempo despus, a continuacin, el proceso de recuperacin tambin puede ser reiniciado de inmediato, aprovechando la recuperacin reiniciable. Si el servidor de reserva no se puede reiniciar, entonces se debe crear una instancia de servidor de reserva nuevos completa. Si el servidor principal falla y el servidor en espera se convierte en el nuevo principal, y luego los viejos reinicia primarias, debe tener un mecanismo para informar a la edad primaria que ya no es el principal. Esto a veces se conoce como STONITH (Dispara el otro nodo en la cabeza), la cual es necesaria para evitar situaciones en las que ambos sistemas se creen las primarias, lo que conducir a la confusin y en ltima instancia, la prdida de datos. Muchos sistemas de conmutacin por error de utilizar slo dos sistemas, el principal y el de reserva, conectadas por algn tipo de mecanismo de heartbeat para verificar continuamente la conectividad entre los dos y la viabilidad de la primaria. Tambin es posible utilizar un tercer sistema (llamado un servidor testigo) para prevenir algunos casos de conmutacin por error apropiado, pero la complejidad adicional puede que no sea la pena a menos que se configura con suficiente cuidado y pruebas rigurosas. PostgreSQL no proporciona el software necesario para identificar una falla en el primario y notificar al servidor de base de datos standby. Muchas de esas herramientas y estn bien integrados con los servicios del sistema operativo necesarias para el xito de conmutacin por error, como la migracin de direcciones IP.
Una vez que se produce la conmutacin por error a la espera, slo hay un nico servidor en funcionamiento. Esto se conoce como un estado degenerado. El primero de espera es ahora el principal, pero la primera primaria se ha reducido y podra quedarse abajo. Para volver al funcionamiento normal, un servidor de reserva debe volver a crear, ya sea en el antiguo sistema de primaria cuando aparece, o en un tercero, posiblemente nuevo sistema. Una vez completa, la principal y en espera se puede considerar que se han cambiado los papeles. Algunas personas optan por utilizar un tercer servidor para proporcionar respaldo para la nueva primaria hasta que se vuelve a crear el nuevo servidor de reserva, aunque es evidente que esto complica la configuracin del sistema y de los procesos operativos. Por lo tanto, el cambio de primaria a servidor de reserva puede ser rpido, pero requiere un poco de tiempo para volver a preparar el clster de conmutacin por error. Cambio regular de primaria a standby es til, ya que permite que el tiempo de inactividad regular en cada sistema para su mantenimiento. Esto tambin sirve como una prueba del mecanismo de conmutacin por error para asegurarse de que realmente funciona cuando lo necesite. Se aconseja a los procedimientos de administracin por escrito. Para activar la conmutacin por error de un servidor de reserva trasvase de registros, ejecute
pg_ctl promover o crear un archivo de activacin con el nombre de archivo y la trigger_file puesta en recovery.conf . Si usted est pg_ctl promover la conmutacin por error, trigger_file no es
necesario. Si est configurando los servidores de informes que slo se utilizan para descargar consultas de slo lectura de la primaria, no para fines de alta disponibilidad, que no es necesario para su promocin.
restore_command que sondea la ubicacin del archivo. Esta fue la nica opcin disponible Standby_mode off, porque va
a implementar la votacin requerida para la operacin de espera a ti mismo. Ver el pg_standbymdulo para una implementacin de referencia de este. Tenga en cuenta que en este modo, el servidor se aplicar WAL un archivo a la vez, por lo que si se utiliza el servidor en espera para las consultas (vase Hot Standby), se produce un retraso
entre la accin en el maestro y cuando la accin se hace visible en el el modo en espera, el tiempo correspondiente que se tarda en llenar el archivo WAL.
utilizado para hacer que el retraso ms corto. Tambin tenga en cuenta que no se puede combinar la reproduccin de streaming con este mtodo. Las operaciones que se producen en los servidores primarios y de reserva son archivado continuo normal y tareas de recuperacin. El nico punto de contacto entre los dos servidores de bases de datos es el archivo de los archivos WAL que ambos comparten: la escritura primaria al archivo, lectura de espera desde el archivo. Se debe tener cuidado para asegurar que WAL archivos de los servidores primarios separados no se mezclen entre s o confundido. El archivo no tiene que ser grande si slo se requiere para la operacin de espera. La magia que hace que los dos servidores dbilmente acoplados trabajar juntos es simplemente una
restore_command utilizado en la reserva de que, cuando se le pregunt por el archivo restore_command se recovery.conf archivo en el servidor de reserva. El proceso de recuperacin
normal pedira un archivo desde el archivo WAL, informando fracaso si el archivo no estaba disponible. Para el proceso de espera es normal que el archivo WAL junto a estar disponible, por lo que la espera debe esperar a que aparezca. Para los archivos que terminan en
personalizado que se repite despus del sondeo para la existencia del archivo WAL siguiente. Tambin debe haber alguna forma de activar la conmutacin por error, que debe interrumpir el
encontrado en el servidor de reserva. Esto termina la recuperacin y la espera ser entonces ven como un servidor normal. Pseudocdigo para un adecuado
restore_command es:
activado = false; while (! NextWALFileReady () &&! disparan) { sueo (100000L); / * esperar ~ 0.1 seg * / if (CheckForExternalTrigger ()) activado = true;
restore_command se proporciona en
el pg_standby mdulo. Se debe utilizar como una referencia en la forma de aplicar correctamente la lgica descrita anteriormente. Tambin se puede extender, segn sea necesario para apoyar configuraciones y entornos especficos. El mtodo para la activacin de conmutacin por error es una parte importante de la planificacin y diseo. Una posible opcin es la
muere para cada archivo, lo que no hay proceso de demonio o servidor, y las seales o un manejador de la seal no se puede utilizar. Por lo tanto, la
adecuado para desencadenar la conmutacin por error. Es posible utilizar un tiempo de espera de instalacin sencilla, especialmente si se usa en conjuncin con un conocido
errores, ya que un problema de red o servidor ocupado primaria podra ser suficiente para iniciar la conmutacin por error. Un mecanismo de notificacin, tales como la creacin explcita de un archivo de disparo es ideal, si esto se puede arreglar.
25.4.1. Implementacin
El procedimiento corto para la configuracin de un servidor en espera utilizando este mtodo alternativo es el siguiente. Para ms detalles sobre cada paso, consulte las secciones anteriores como se ha indicado. 1. Establecer sistemas principal y de reserva como casi idnticas como sea posible, incluyendo dos copias idnticas de PostgreSQL al mismo nivel de release. 2. Configure el archivo permanente de la primaria a un directorio de archivado WAL en el servidor de reserva. Asegrese de que archive_mode , archive_command y archive_timeout se ajustan adecuadamente en el primario (vase la seccin 24.3.1 ).
3. Haga una copia de seguridad de base del servidor primario (vase la seccin 24.3.2 ), y cargar estos datos en el modo de espera. 4. Comience la recuperacin en el servidor de espera desde el archivo local WAL, utilizando un
describe anteriormente (vase la Seccin 24.3.3 ). Recuperacin trata el archivo WAL como de slo lectura, por lo que una vez que un archivo WAL ha sido copiado al sistema de reserva que se puede copiar en cinta al mismo tiempo que est siendo ledo por el servidor de base de datos standby. Por lo tanto, se ejecuta un servidor de reserva para la alta disponibilidad se puede realizar al mismo tiempo que los archivos se almacenan con fines de recuperacin de desastres a ms largo plazo. Para propsitos de prueba, es posible ejecutar servidores primarios y de reserva en el mismo sistema. Esto no proporciona ninguna mejora vale la pena en la robustez del servidor, ni sera descrito como HA.
Seccin 9.24 ) para averiguar el nombre del archivo y el byte exacta desplazamiento dentro de l, del extremo actual de WAL. A continuacin, se puede acceder al archivo WAL directamente y copiar los datos de la ltima final conocida de WAL a travs del extremo de corriente a los servidores de reserva. Con este enfoque, la ventana para la prdida de datos es el tiempo de ciclo de sondeo del programa de copia, que puede ser muy pequea, y no hay ancho de banda desperdiciado de obligar a los archivos de segmentos parcialmente utilizados para ser archivados. Tenga en cuenta que los servidores en espera '
restore_command secuencias de
comandos slo pueden tratar con archivos WAL enteros, lo que los datos incrementalmente copiada no est normalmente pone a disposicin de los servidores de reserva. Se trata de usar slo cuando las matrices primarias - a continuacin, el ltimo archivo WAL parcial se alimenta a la espera antes de permitir que suba. La aplicacin correcta de este proceso requiere de la cooperacin del
A partir de PostgreSQL versin 9.0, puede utilizar la replicacin de secuencias (vase la seccin 25.2.5 ) para lograr los mismos beneficios con menos esfuerzo.
Acceso de consulta -
SELECT , copia a
o o o
EMPEZAR , END , ABORTO , iniciar la transaccin SAVEPOINT , RELEASE , ROLLBACK TO SAVEPOINT EXCEPCIN bloques y otros subtransacciones internos
compartir el acceso , ROW SHARE o EXCLUSIVE FILA . PREPARE , EXECUTE , DEALLOCATE , DESCARTAR CARGA
Planes y recursos -
Plugins y extensiones -
Las operaciones iniciadas durante la espera caliente nunca se le asignar un ID de transaccin y no puede escribir en el sistema de escritura anticipada de registrar. Por lo tanto, las siguientes acciones se producen mensajes de error:
restriccin se aplica incluso a las tablas temporales, ya que la realizacin de estas operaciones requerir la actualizacin de las tablas de catlogo del sistema.
Normas sobre
LOCK que pida explcitamente un modo superior FILA MODO EXCLUSIVO . LOCK en forma predeterminada corto, ya que solicita acceder al modo EXCLUSIVO .
o o
COMENZAR READ WRITE , iniciar la transaccin READ WRITE Conjunto de transacciones READ WRITE , SET caractersticas de la sesin como una transaccin READ WRITE
Cambios de secuencia -
nextval () , setval ()
restricciones poco estrictas que de slo lectura sesiones ordinarias. Es posible que algunas de estas restricciones podran aflojarse en una futura versin. Durante la espera activa, el parmetro
puede cambiar. Pero siempre y cuando no se realiza ningn intento de modificar la base de datos, las conexiones durante la espera activa actuarn como cualquier otro tipo de conexin de base de datos. Si se produce recuperacin de fallos o una conmutacin, la base de datos se cambia a modo de proceso normal. Sesiones permanecern conectados durante el modo de cambio de servidor. Acabados de espera Una vez caliente, ser posible iniciar las operaciones de lectura y escritura (incluso desde una sesin iniciada en hot standby).
Los usuarios sern capaces de decir si la sesin es de slo lectura mediante la emisin
9-57 ) permite a los usuarios acceder a la informacin sobre el servidor en espera. Estas te permiten escribir programas que son conscientes de la situacin actual de la base de datos. Estos pueden ser usados para controlar el progreso de la recuperacin, o para que pueda escribir programas complejos que restaurar la base de los estados particulares.
LOCK comandos y varias DDL acciones, los conflictos con los accesos de tabla
de consultas en espera.
Dejar caer un espacio de tabla en los principales conflictos con las preguntas de reserva que utilizan ese espacio de tabla para archivos de trabajo temporales.
Quitar una base de datos sobre los principales conflictos con sesiones conectadas a la base de datos en el modo de espera.
La aplicacin de un registro de limpieza de vaco de conflictos WAL con las transacciones de reserva cuya instantneas todava puede "ver" a cualquiera de las filas que se eliminen.
La aplicacin de un registro de limpieza de vaco de conflictos WAL con consultas con el acceso a la pgina de destino en el modo de espera, si los datos que se eliminen es visible.
En el servidor principal, estos casos slo dan lugar a la espera, y el usuario puede optar por cancelar cualquiera de las acciones conflictivas. Sin embargo, en el modo de espera no hay otra opcin: el WAL-conectado accin ya ha ocurrido en el primario por lo que el modo de espera no debe dejar de aplicarla. Adems, permite la aplicacin WAL esperar indefinidamente puede ser muy deseable, ya que el estado de la reserva ser cada vez ms lejos de la principal de. Por lo tanto, se proporciona un mecanismo para cancelar la fuerza consultas de reserva que entran en conflicto con los registros WAL-a-ser aplicada. Un ejemplo de la situacin del problema es un administrador en el servidor principal se ejecuta
DROP TABLE en una tabla en la que actualmente se est consultando en el servidor de DROP TABLE se aplica DROP TABLE esperara
reserva. Es evidente que la consulta de espera no puede continuar si el en el modo de espera. Si esta situacin se produjo en la primaria, el hasta la otra consulta haba terminado. Pero cuando
principal no tiene informacin sobre lo que las consultas se ejecutan en el modo de espera, por lo que no esperar a que dichas consultas en espera. Los registros de cambios WAL vienen a travs de la espera mientras espera la consulta est an en marcha, causando un conflicto. El servidor de reserva debe o bien retrasar la aplicacin de los registros WAL (y todo despus de ellos, tambin) o bien cancelar la consulta en conflicto para que el aplicar. Cuando una consulta conflicto es corto, es normalmente deseable permitir que se complete al retrasar la aplicacin WAL por un rato, pero un retraso en la aplicacin de WAL generalmente no es deseable. Por lo tanto el mecanismo de cancelacin tiene parmetros, max_standby_archive_delay y max_standby_streaming_delay , que definen el retardo mximo permitido en la solicitud de WAL. Consultas conflictivos sern cancelados una vez que se ha tomado ms tiempo que el retardo correspondiente ajuste para aplicar los datos de WAL recin recibidos. Hay dos parmetros, de manera que los diferentes valores de retardo se pueden especificar para el caso de la lectura de datos WAL de un archivo (es decir, la recuperacin inicial de una copia de seguridad base o "alcanzar" un servidor de reserva que se ha quedado muy por detrs) frente a la lectura de datos a travs de WAL streaming de replicacin.
En un servidor de reserva que existe principalmente para la alta disponibilidad, lo mejor es establecer los parmetros de retardo relativamente corto, por lo que el servidor no puede caer muy por detrs de la primaria debido a los retrasos causados por las consultas en espera. Sin embargo, si el servidor de reserva es para ejecutar consultas de larga duracin, a continuacin, un valor alto o incluso infinita demora puede ser preferible. Tenga en cuenta sin embargo que una consulta de larga ejecucin puede causar otras sesiones en el servidor de reserva para no ver los cambios recientes en la primaria, si aplaza la aplicacin de registros WAL. Una vez que el retardo especificado por
superado, se cancelarn las consultas en conflicto. Esto por lo general se traduce simplemente en un error de anulacin, si bien en el caso de volver a jugar un
terminado toda la sesin en conflicto. Adems, si el conflicto ha llegado a un bloqueo que tiene una transaccin de inactividad, la sesin de conflicto se termina (este comportamiento puede cambiar en el futuro). Consultas cancelados pueden ser juzgados inmediatamente (despus de comenzar una nueva transaccin, por supuesto). Desde cancelacin de consulta depende de la naturaleza de los registros WAL siendo reproducido, una consulta que fue cancelada bien puede tener xito si se ejecuta de nuevo. Tenga en cuenta que los parmetros de retardo se comparan con el tiempo transcurrido desde que los datos WAL fue recibida por el servidor en espera. Por lo tanto, el perodo de gracia permitido para cualquier consulta en el modo de espera es nunca ms que el parmetro de retardo, y podra ser considerablemente menor si el modo de espera ya se ha quedado atrs como resultado de la espera para las consultas anteriores para completar, o como resultado de estar incapaz de mantenerse al da con una carga pesada actualizacin. La razn ms comn para el conflicto entre las consultas de reserva y WAL repeticin es "limpieza temprana" . Normalmente, PostgreSQL permite la limpieza de las viejas versiones de fila cuando no hay transacciones que tienen que ver con garantizar la correcta visibilidad de los datos de acuerdo con las normas MVCC. Sin embargo, esta regla slo se puede aplicar a las transacciones se ejecutan en el maestro. Por lo tanto, es posible que la limpieza en el maestro eliminar las versiones de fila que son todava visibles a una transaccin en el modo de espera. Los usuarios experimentados deben tener en cuenta que tanto la versin de la limpieza de fila y fila de la versin de congelacin sern potencialmente entrar en conflicto con las consultas en
en las mesas sin filas actualizadas o eliminadas. Los usuarios deben tener claro que las tablas que se actualizan peridicamente y en gran medida en el servidor primario har que rpidamente cancelacin de ya la ejecucin de consultas en el modo de espera. En tales casos, el ajuste de un valor finito para
Remediacin posibilidades existen si no se encuentra el nmero de cancelaciones de esperaconsulta es inaceptable. La primera opcin es establecer el parmetro
muertos y as los conflictos de limpieza, no se producen. Si usted hace esto, usted debe tener en cuenta que esto retrasar la limpieza de lneas muertas en la primaria, lo cual puede resultar en hinchazn mesa indeseable. Sin embargo, la situacin de la limpieza no ser peor que si las consultas de reserva corran directamente en el servidor principal, y usted todava est recibiendo el beneficio de ejecucin fuera de la carga en el modo de espera.
retras WAL archivos ya podran contener entradas que entran en conflicto con las consultas de reserva deseados. Otra opcin es aumentar vacuum_defer_cleanup_age en el servidor principal, por lo que las filas de cadveres no pueden limpiar tan pronto como se hara normalmente. Esto permitir ms tiempo para las consultas que se ejecutan antes de que se cancelan en el modo de espera, sin necesidad de configurar un alto
garantizar cualquier ventana especfica de ejecucin en tiempo con este enfoque, ya que
pg_stat_database_conflicts vista del sistema en el servidor de pg_stat_database vista del sistema tambin contiene informacin de resumen.
reserva. El
hot_standby est activado en en postgresql.conf y hay recovery.conf presente expediente, el servidor se ejecuta en modo Hot Standby. Sin
una
embargo, puede tomar algn tiempo para las conexiones Hot Standby que se le permita, ya que el servidor no aceptar conexiones hasta que se haya completado la recuperacin suficiente para proporcionar un estado coherente contra las consultas que se pueden ejecutar. Durante este perodo, los clientes que intentan conectarse sern rechazados con un mensaje de error. Para confirmar que el servidor ha presentado, ya sea loop intentar conectar desde la aplicacin, o buscar estos mensajes en los registros del servidor:
LOG: estado de recuperacin consistentes alcanz LOG: sistema de base de datos est listo para aceptar conexiones de slo lectura
Informacin consistencia se registra una vez por puesto de control en el primario. No es posible activar la espera activa al leer WAL escrito durante un perodo en que estableci en
wal_level no se
Si est ejecutando el trasvase de registros basada en archivo ("espera activa"), es posible que tenga que esperar hasta que llegue el archivo WAL siguiente, que podra ser tan larga como la
La configuracin de algunos parmetros en el modo de espera tendr reconfiguracin si se han cambiado en el primario. Para estos parmetros, el valor en el modo de espera debe ser igual o mayor que el valor en el primario. Si estos parmetros no se ajustan lo suficientemente alto, la espera no arrancar. Los valores ms altos pueden ser suministrados y reiniciar el servidor para iniciar la recuperacin de nuevo. Estos parmetros son:
Es importante que el administrador de seleccionar los ajustes apropiados para max_standby_archive_delay y max_standby_streaming_delay . Las mejores opciones varan en funcin de las prioridades del negocio. Por ejemplo, si el servidor se encarga principalmente como un servidor de alta disponibilidad, entonces usted tendr que ajustes de retardo bajo, tal vez incluso a cero, sin embargo, que es un entorno muy agresivo. Si el servidor de reserva tiene la tarea como un servidor adicional para las consultas de apoyo a las decisiones, entonces puede ser aceptable para establecer los valores mximos de demora a muchas horas, o incluso -1 lo que significa esperar por siempre para las consultas en completarse. Situacin de la operacin "bits toque", escrito en la primaria no son WAL-conectado, por lo que los datos de la reserva probable volver a escribir las notas de nuevo en el modo de espera.Por lo tanto, el servidor de reserva seguir realizando escrituras en disco a pesar de todos los usuarios son de slo lectura, no se producen cambios en los valores propios datos. Los usuarios an podrn escribir archivos temporales grandes clasificar y volver a generar archivos de informacin relcache, por lo que no forman parte de la base de datos es realmente de slo lectura durante el modo de espera activa. Tenga en cuenta tambin que escribe a bases de datos remotas utilizando dblink mdulo, y otras operaciones fuera de la base de datos utilizando las funciones PL seguir siendo posible, a pesar de que la transaccin es de slo lectura a nivel local. Los siguientes tipos de comandos de administracin no son aceptados en el modo de recuperacin:
CREATE INDEX
Comandos de mantenimiento -
Una vez ms, tenga en cuenta que algunos de estos comandos son en realidad permiti en "slo lectura" transacciones modo en el primario.
Como resultado, no se puede crear ndices adicionales que existen nicamente en el modo standby, ni estadsticas que existen nicamente en el modo de espera. Si se necesitan estos comandos de administracin, deben ser ejecutados en el primario, y, finalmente, los cambios se propagarn a la espera.
pg_prepared_xacts est siempre vaco durante la recuperacin. Si desea pg_prepared_xacts de los comandos
resolver en duda las transacciones preparadas, ver principales y dirigir a resolver operaciones all.
arranque que posee todosAccessExclusiveLocks en poder de las transacciones est reproduciendo la recuperacin. Tenga en cuenta que el proceso de arranque no adquiere bloqueos para hacer los cambios de base de datos, y por lo tanto bloquea distinto
arranque, no son ms que presume de ser. El Nagios Plugin check_pgsql funcionar, ya que la informacin simple que comprueba que existe. El check_postgres script de monitoreo tambin trabajar, aunque algunos valores reportados podran dar resultados diferentes o confusa. Por ejemplo, no se mantendr ltima vez vaco, ya que no se produce vaco en el modo de espera. Aspiradoras ejecutan en la primaria no siguen enviando sus cambios en el modo de espera. Comandos de control de archivos WAL no funcionarn durante la recuperacin, por ejemplo
Cerraduras de asesoramiento trabajan normalmente en la recuperacin, incluyendo la deteccin de punto muerto. Tenga en cuenta que las cerraduras de asesoramiento son nunca WAL registran, por lo que es imposible para un bloqueo de asesoramiento ya sea en el primario o el modo de espera en conflicto con WAL replay. Tampoco es posible adquirir un bloqueo de asesoramiento en la primaria y tienen que iniciar un bloqueo de asesoramiento similar en el
modo de espera. Cerraduras de asesoramiento se refieren slo al servidor en el que se hayan adquirido. Sistemas de replicacin basada en activadores como Slony , londiste y Bucardo no se ejecutar en el modo de espera en absoluto, a pesar de que se ejecutar felizmente en el servidor principal, siempre y cuando los cambios no se envan a los servidores de reserva que han de aplicarse. WAL replay no est basada en activadores por lo que no puede transmitir desde el modo de espera para cualquier sistema que requiera base de datos adicional escribe o se basa en el uso de los factores desencadenantes. Nuevos OID no se pueden asignar, aunque algunos UUID generadores pueden seguir trabajando, siempre y cuando no se basan en la escritura de nuevo estatuto de la base de datos. Actualmente, no se permite la creacin de tablas temporal durante las operaciones de lectura solamente, por lo que en algunos casos las secuencias existentes no funcionar correctamente. Esta restriccin puede estar relajado en una versin posterior. Esto es tanto una cuestin de cumplimiento estndar SQL y una cuestin tcnica.
DROP TABLESPACE slo puede tener xito si el espacio de tablas est vaca. Algunos usuarios
de espera pueden ser activamente utilizando el espacio de tablas a travs de sutemp_tablespaces parmetro. Si hay archivos temporales en el espacio de tablas, todas las consultas activas se cancelan para asegurarse de que los archivos temporales se eliminan, por lo que el espacio de tablas se puede quitar y WAL repeticin puede continuar. Correr
generar una entrada de WAL que har que todos los usuarios conectados a la base de datos en el modo de espera para ser desconectados a la fuerza. Esta accin se produce de inmediato, independientemente de la configuracin de cuenta que
max_standby_streaming_delay . Tenga en
casos pasa desapercibido, aunque en algunos casos podra provocar una confusin programa si depende de alguna manera a nombre de la base. En (sin recuperacin) modo normal, si emite
capacidad de conexin, mientras que el usuario est conectado, entonces nada sucede al usuario conectado - permanecen conectados. El usuario no puede conectarse sin embargo. Este comportamiento se aplica tambin en la recuperacin, por lo que un no desconecta el usuario en el modo de espera.
El recolector de estadsticas est activo durante la recuperacin. Todas las exploraciones, lee, bloques, uso de ndices, etc, sern registrados normalmente en el modo de espera. Acciones reproducidos no duplicar sus efectos en la primaria, por lo que jugar de nuevo un inserto no incrementar la columna de la Insertos de pg_stat_user_tables. El archivo de estadsticas se borra en el inicio de la recuperacin, por lo que las estadsticas de primaria y de reserva sern diferentes, lo que se considera una caracterstica, no un error. Autovacuum no est activo durante la recuperacin. Se iniciar normalmente al final de la recuperacin. El escritor de fondo es activa durante la recuperacin y realizar restartpoints (similares a los puestos de control en las primarias) y las actividades de limpieza de bloques normales. Esto puede incluir actualizaciones de la informacin de bit pista almacenada en el servidor de reserva. El
25.5.5. Advertencias
Existen varias limitaciones de Hot Standby. Estos pueden y probablemente se fijar en futuras versiones:
Operaciones en ndices hash no son actualmente WAL-registran, por lo replay no se actualizarn estos ndices.
Se requiere conocimiento completo de las transacciones en ejecucin antes se pueden tomar instantneas. Las transacciones que utilizan un gran nmero de subtransacciones (actualmente superior a 64) se demora el inicio de slo lectura conceptos hasta la finalizacin de la transaccin de escritura de ms larga duracin. Si se produce esta situacin, los mensajes explicativos sern enviados al registro del servidor.
Puntos de partida vlidos para las consultas de reserva se generan en cada punto de control en el maestro. Si la reserva se apaga mientras el maestro est en un estado de cierre, tal vez no sea posible volver a entrar en modo de espera caliente hasta que el principal se pone en marcha, por lo que genera an ms puntos de partida en los registros WAL. Esta situacin no es un problema en las situaciones ms comunes en las que podra suceder. Generalmente, si el principal est apagado y no estar disponible, es probable que se deba a un fallo grave que requiere la espera de ser convertidos para funcionar como la nueva primaria de todos modos. Y en situaciones en las primarias se est tomando intencionadamente hacia abajo, la coordinacin para asegurar que la espera se convierte en el nuevo principal problemas es tambin un procedimiento estndar.
Al final de la recuperacin,
preparadas requerir el doble del nmero normal de las entradas de la tabla de bloqueo. Si planea ejecutar o bien un gran nmero de transacciones preparadas concurrentes que normalmente toman
el doble del valor de el parmetro en el servidor principal. Es necesario no considerar en absoluto si su configuracin de
El nivel de aislamiento serializable an no est disponible en modo de espera caliente. (Ver Seccin 13.2.3 y la Seccin 13.4.1 para ms detalles.) intent establecer una transaccin con el nivel de aislamiento serializable en el modo de espera activa, generar un error.
26.3. Configuracin del servidor en espera En este captulo se describe la configuracin disponible en el
poner a cero para cualquier recuperacin posterior que desea realizar. No se puede cambiar una vez que la recuperacin ha comenzado.
Ajustes en
como un comentario.Para insertar una comilla simple en un valor de parmetro, escriba dos comillas (
share / directorio.
nombre de la ruta de destino de copia en el servidor. (El nombre de la ruta es relativa al directorio de trabajo actual, es decir, el directorio de datos de la agrupacin.) Cualquier
arranque vlido. Ese es el primer archivo que debe mantenerse para permitir una restauracin reiniciable ser, por lo que esta informacin puede ser utilizada para truncar el archivo de slo el mnimo necesario para apoyar el reinicio de la restauracin actual.
Es importante para que el comando devuelve un cdigo de salida de cero slo si tiene xito. El comando se pedir los nombres de archivos que no estn presentes en el archivo, debe devolver cero si le fuera solicitada. Ejemplos:
restore_command = 'cp / mnt / server / archivedir /% f "% p"' restore_command = "copy" C: \ \ servidor \ \ archivedir \ \% f ""% p "'# para Windows archive_cleanup_command ( string )
Este parmetro opcional especifica un comando de shell que se ejecuta en cada restartpoint. El propsito de
archive_cleanup_command es proporcionar un
mecanismo para la limpieza de viejos archivos WAL archivados que ya no son necesarios
contiene el ltimo punto de arranque vlido. Ese es el primer archivo que se deben mantener para permitir una restauracin reiniciable ser, y as todos los archivos antes de
para truncar el archivo de slo el mnimo requerido para soportar reiniciar desde la restauracin actual. El pg_archivecleanup mdulo se utiliza a menudo en
por ejemplo:
Si el comando devuelve un estado de salida distinto de cero, entonces un mensaje de registro ADVERTENCIA ser escrito. recovery_end_command ( string ) Este parmetro especifica un comando de shell que se ejecutar slo una vez al final de la recuperacin. Este parmetro es opcional. El propsito de la
recovery_end_command es proporcionar un mecanismo para la limpieza despus % r se sustituye por el nombre del archivo
Si el comando devuelve un estado de salida distinto de cero, entonces un mensaje de registro ADVERTENCIA ser escrito y la base de datos se proceder a la puesta en marcha de todos modos. Una excepcin es que si el comando se ha cancelado por una seal, la base de datos no proceder con el inicio.
sumo uno
especificar. El valor predeterminado es recuperar al final del registro de WAL. recovery_target_time ( fecha y hora ) Este parmetro especifica el tiempo de sello hasta que la recuperacin va a continuar. A lo sumo uno de
punto de parada precisa tambin est influenciada por recovery_target_inclusive . recovery_target_xid ( string ) Este parmetro especifica el ID de la transaccin hasta que la recuperacin va a continuar. Tenga en cuenta que mientras que los identificadores de transaccin se asignan en secuencia al inicio de transacciones, las transacciones se pueden realizar en un orden numrico diferente. Las operaciones que se pueden recuperar son los que cometi antes (y que incluye opcionalmente) de la especificada. A lo sumo uno de
punto de parada precisa tambin est influenciada por recovery_target_inclusive . recovery_target_inclusive ( booleano ) Especifica si nos detenemos justo despus del objetivo de recuperacin especificada (
arecovery_target_time y recovery_target_xid , el que se ha especificado para esta recuperacin. Esto indica si las transacciones que tienen exactamente el nivel se comprometen tiempo o ID, respectivamente, se incluirn en la recuperacin. El valor
tiempo que se encuentra en el archivo, que es til en un servidor en espera. Aparte de eso slo tiene que ajustar este parmetro en situaciones de re-recuperacin complejos, en los que usted necesita para volver a un estado que s se alcanz despus de una
recuperacin de punto en el tiempo. Consulte la Seccin 24.3.4 para el debate. pause_at_recovery_target ( booleano ) Especifica si se debe hacer una pausa de recuperacin cuando se alcanza el objetivo de recuperacin. El valor predeterminado es true. Este est destinado a permitir consultas a ser ejecutadas en la base de datos para comprobar si este objetivo de recuperacin es el punto ms conveniente para la recuperacin. El estado de pausa se puede reanudar
mediante el uso de
la recuperacin a fin. Si este objetivo de recuperacin no es el punto de parada deseada, luego apagar el servidor, cambie la configuracin de destino de recuperacin a un objetivo ms tarde y reiniciar para continuar la recuperacin.
Este ajuste no tiene efecto si hot_standby no est habilitado, o si no se establece ningn objetivo de recuperacin.
en el servidor no se detendr la recuperacin cuando se alcanza el final de restore_command y / o mediante la conexin al primary_conninfo ajuste .
archivado WAL, pero seguir tratando de continuar la recuperacin por ir a buscar nuevos segmentos de WAL usando
Especifica una cadena de conexin que se utilizar para el servidor en espera para conectar con el primario. Esta cadena tiene el formato aceptado por la libpq
especifica en esta cadena, entonces la variable de entorno correspondiente (vase la seccin 31.13 se comprueba). Si la variable de entorno no se ajusta bien, se utilizan valores por defecto.
La cadena de conexin debe especificar el nombre de host (o direccin) del servidor principal, as como el nmero de puerto si no es el mismo que por defecto del servidor de reserva.Tambin debe especificar un nombre de usuario que corresponde a una funcin que tiene las
Seccin 25.2.5.1 ). Una contrasea debe proporcionarse tambin, si la demanda primaria de autenticacin de contrasea. Puede estar previsto en el
primary_conninfo cadena, o en un archivo ~ /. pgpassarchivo en el servidor la replicacin como el nombre de base de datos). No primary_conninfo cadena. off .
de reserva (utilice
Especifica un archivo de activacin, cuya presencia termina la recuperacin en el modo de espera. Incluso si este valor no est establecido, puede promover el modo de espera utilizando si
Standby_mode es off .
se ha identificado una consulta de bajo rendimiento, podra ser necesaria una mayor investigacin utilizando PostgreSQL 's EXPLICAR comando. Seccin 14.1 discute
consulta individual.
$ Ps auxww | grep ^ postgres postgres 960 0,0 1,1 6104 1480 pts / 1 SN 13:17 0:00 postgres-i postgres 963 0,0 1,1 7084 1472 pts / 1 SN 13:17 0:00 postgres: Proceso de escritor postgres 965 0,0 1,1 6152 1512 pts / 1 SN 13:17 0:00 postgres: Proceso colector estadsticas postgres 998 0,0 2,3 6532 2992 pts / 1 SN 13:18 0:00 postgres: TGL runbug 127.0.0.1 inactividad
postgres 1003 0,0 2,4 6532 3128 pts / 1 SN 13:19 0:00 postgres: regresin TGL [local] en espera postgres 1016 0,1 2,4 6532 3080 pts / 1 SN 13:19 0:00 postgres: regresin TGL [locales] ociosa en las transacciones
se muestra. Este ejemplo es de un sistema reciente de Linux.) El primer proceso mencionadas anteriormente, es el proceso del servidor maestro. Los argumentos de comandos que se muestran porque son los mismos que utiliza en su lanzamiento. Los siguientes dos procesos son procesos de trabajo en segundo plano inicia automticamente el proceso maestro. (El "stats colector" proceso no estar presente si se ha configurado el sistema para no iniciar el recolector de estadsticas.) Cada uno de los restantes procesos es un proceso de servidor de manejo de una conexin de cliente. Cada uno de estos procesos se define la visualizacin de la lnea de comando en el formulario
postgres: usuarios
de bases de datos
de acogida
actividad
El usuario, base de datos, y (cliente) los elementos de host siguen siendo los mismos para la vida de la conexin de cliente, pero los cambios en el indicador de actividad. La actividad puede ser
inactivo (es decir, a la espera de un comando de cliente), inactivo en la la espera se agregar si el proceso del servidor se
/ usr / ucb / ps , en
/ bin / ps . Tambin debe utilizar dos w banderas, no slo uno. Adems, su postgres comando debe tener un corto ps pantalla de estado que la
proporcionada por cada proceso de servidor. Si usted no puede hacer las tres cosas, elps de salida para cada proceso de servidor ser el original
postgresql.conf . (Vea el
Captulo 18 para obtener ms informacin sobre la configuracin de los parmetros de configuracin.) El parmetro track_counts controla si las estadsticas se recopilan sobre la tabla y accesos de ndices. Los parmetros track_functions permite el seguimiento del uso de las funciones definidas por el usuario. Los parmetros track_activities permite el seguimiento del comando actual en ejecucin por cualquier proceso de servidor. Normalmente estos parmetros se configuran en
todos los procesos del servidor, pero es posible convertirlos encendido o apagado en sesiones individuales con el SET de comandos. (Para evitar que los usuarios normales de ocultar su actividad por parte del administrador, slo los superusuarios pueden cambiar estos parmetros con
SET .)
El recolector de estadsticas transmite la informacin recopilada para backends (incluyendo autovacuum) a travs de los archivos temporales. Estos archivos se almacenan en la
pg_stat_tmpsubdirectorio. Cuando el jefe de correos se apaga, se almacena una copia mundial subdirectorio. Para un mayor
rendimiento, el parmetrostats_temp_directory puede sealar a un sistema de archivos basado en RAM, la disminucin de los requisitos de E / S fsicas.
menos alteradas mientras que la construccin del servidor). As que la informacin que aparece por detrs actividad real. Sin embargo, la informacin actual-query recogida por
Otro punto importante es que cuando se le pide un proceso de servidor para mostrar cualquiera de estas estadsticas, se obtiene primero el ms reciente informe emitido por el proceso de colector y luego contina utilizando esta instantnea para todas las vistas y funciones estadsticas hasta el final de la transaccin actual . As que las estadsticas mostrarn informacin esttica, siempre y cuando contine la transaccin actual. Del mismo modo, la informacin sobre las consultas actuales de todas las sesiones se recopila cuando dicha informacin se solicit por primera vez en una transaccin, y la misma informacin se mostrar en toda la transaccin. Esta es una caracterstica, no es un error, ya que le permite realizar varias consultas en las estadsticas y correlacionar los resultados sin tener que preocuparse de que los nmeros estn cambiando por debajo de usted. Pero si usted quiere ver nuevos resultados con cada consulta, asegrese de hacer las consultas fuera de cualquier bloque de transaccin. Alternativamente, puede invocar
descartar la transaccin actual estadsticas instantneas (en su caso). El siguiente uso de la informacin estadstica provocar una nueva instantnea que descargar.
Una transaccin tambin puede ver sus propias estadsticas (an no emitido al colector) en los puntos de vista
Ver Nombre
Descripcin
pg_stat_activity
Una fila por cada proceso de servidor, que muestra la base de datos OID, el nombre de base de datos, el proceso de identificacin , el usuario OID, nombre de usuario, nombre de la aplicacin, la direccin del cliente, el nombre de host (si est disponible) y nmero de puerto, los tiempos en que el proceso del servidor, la transaccin actual, y consulta actual se inici la ejecucin, el estado de espera del proceso, y el texto de la consulta actual. Las columnas que reportan datos sobre la consulta actual estn disponibles a no ser que los parmetros track_activities se ha apagado. Por otra parte, estas columnas son accesibles solamente si el usuario examen de la vista es un superusuario o el mismo que el usuario propietario del proceso objeto de la informacin. Nombre de sistema del cliente estar disponible slo si log_hostname se activa o si el nombre de host del usuario tena que examinarse durante pg_hba.conf procesamiento.
pg_stat_bgwriter
Slo filas, mostrando el clster estadsticas del escritor de fondo: nmero de puntos de control programados, puestos solicitados, tampones escritos por los puestos de control y las exploraciones de limpieza, y el nmero de veces que el escritor fondo detuvo una exploracin de limpieza, ya que haba escrito muchos
Ver Nombre
Descripcin buffers. Tambin incluye informacin sobre la agrupacin de almacenamiento intermedio compartido, incluyendo tampones escritos por backends (es decir, no por el escritor de fondo), cuntas veces los backends tenan que ejecutar sus propias llamadas fsync (normalmente el escritor fondo maneja los que incluso cuando el backend hace su propios de escritura), tampones totales asignados, y el tiempo de la estadstica ltimo reinicio.
pg_stat_database
Una fila por cada base de datos, que muestra la base de datos OID, el nombre de base de datos, el nmero de procesos de servidor activo conectado a esa base de datos, el nmero de transacciones confirmadas, removi en esa base de datos, bloques de disco total de lectura, visitas totales tampn (es decir, bloquear las peticiones de lectura evitado mediante la bsqueda de el bloque est en la cache buffer), el nmero de filas devueltas, inverosmil, insertar, actualizar y eliminar, el nmero total de consultas canceladas debido a un conflicto con la recuperacin (en los servidores en espera), y la hora del ltimo restablecimiento de estadsticas.
pg_stat_database_confl icts
Una fila por cada base de datos, que muestra la base de datos OID, el nombre de base de datos y el nmero de consultas que han sido cancelados en esta base de datos debido a los espacios de tablas cadas, los tiempos de espera de bloqueo, fotos viejas, topes fijados y bloqueos. Slo contendr informacin sobre los servidores de reserva, ya que los conflictos no se producen en los servidores maestros.
Ver Nombre
Descripcin
pg_stat_replication
Una fila por cada proceso emisor WAL, mostrando el proceso ID , el usuario OID, nombre de usuario, nombre de la aplicacin, la direccin del cliente, el nombre de host (si est disponible) y el nmero de puerto, momento en el que el proceso del servidor se inici la ejecucin y el estado actual del remitente WAL y transaccin ingrese ubicacin. Adems, el modo de espera reporta la ltima posicin de registro de transacciones que recibi y escribi, la ltima posicin en la que se ruboriz al disco, y la ltima posicin se repite, y esta informacin tambin se visualiza aqu. Si los nombres de aplicacin de la reserva coincide con uno de los valores en synchronous_standby_name
pg_stat_all_tables
Para cada tabla de la base de datos actual (incluyendo tablas PAN), la tabla de OID, esquema y nombre de la tabla, nmero de exploraciones secuenciales iniciadas, el nmero de filas en vivo fue a buscar por las exploraciones secuenciales, el nmero de ndice de las exploraciones iniciadas (ms de todos los ndices que pertenecen a la tabla ), el nmero de filas en vivo fue a buscar por las exploraciones de ndices, nmeros de fila inserciones, actualizaciones y eliminaciones, el nmero de cambios de registro que se caliente (es decir, no hay ninguna actualizacin de ndice por
Ver Nombre
Descripcin separado), el nmero de filas de vivos y muertos, la ltima vez que la mesa era no COMPLETO aspirado manual, la ltima vez que fue aspirado por el demonio autovacuum, la ltima vez que se analiz de forma manual, la ltima vez que fue analizado por el demonio autovacuum, el nmero de veces que ha sido no COMPLETO aspirador manual, el nmero de veces que se ha aspirado por el demonio autovacuum, el nmero de veces que se ha analizado de forma manual, y el nmero de veces que ha sido analizado por el demonio autovacuum.
pg_stat_sys_tables
Igual que pg_stat_all_tables , excepto que slo las tablas del sistema se muestran.
pg_stat_user_tables
Igual que pg_stat_all_tables , excepto que slo se muestran las tablas de usuario.
pg_stat_xact_all_table s
Similar a pg_stat_all_tables , pero cuenta las medidas adoptadas hasta la fecha en que la transaccin actual (que son no todava incluidos enpg_stat_all_tables y puntos de vista relacionados). Las columnas de nmeros de filas vivos y muertos y de vaco y analizar las acciones no estn presentes en esta vista.
Igual
pg_stat_xact_sys_table s
que pg_stat_xact_all_tables , excepto que slo las tablas del sistema se muestran.
Ver Nombre
Descripcin
pg_stat_xact_user_tabl es
Igual que pg_stat_xact_all_tables , excepto que slo se muestran las tablas de usuario.
pg_stat_all_indexes
Para cada ndice de la base de datos actual, la tabla y el ndice OID, esquema, tabla y el nombre de ndice, el nmero de ndice de las exploraciones iniciadas en ese ndice, el nmero de entradas de ndice devuelto por las exploraciones de ndice, y el nmero de filas de la tabla en vivo fue a buscar por las exploraciones de ndices simples el uso de dicho ndice.
pg_stat_sys_indexes
Igual que pg_stat_all_indexes , excepto que slo se muestran los ndices de las tablas del sistema.
pg_stat_user_indexes
Igual que pg_stat_all_indexes , excepto que slo se muestran los ndices de las tablas de usuario.
pg_statio_all_tables
Para cada tabla de la base de datos actual (incluyendo tablas PAN), la tabla de OID, esquema y nombre de la tabla, el nmero de bloques de disco de lectura de esa tabla, el nmero de accesos a memoria intermedia, el nmero de bloques de disco de lectura y amortiguar golpes en todos los ndices de esa tabla , el nmero de bloques de disco leer y amortiguan golpes de mesa TOAST auxiliar de la mesa (si los hay), y el nmero de bloques de disco leer y amortiguan golpes para el ndice de la tabla TOAST.
Ver Nombre
Descripcin
pg_statio_sys_tables
Igual que pg_statio_all_tables , excepto que slo las tablas del sistema se muestran.
pg_statio_user_tables
Igual que pg_statio_all_tables , excepto que slo se muestran las tablas de usuario.
pg_statio_all_indexes
Para cada ndice de la base de datos actual, la tabla y el ndice OID, esquema, tabla y el nombre de ndice, el nmero de bloques de disco de lectura y amortiguar golpes de dicho ndice.
Igual
pg_statio_sys_indexes
que pg_statio_all_indexes , excepto que slo se muestran los ndices de las tablas del sistema.
pg_statio_user_indexes
Igual que pg_statio_all_indexes , excepto que slo se muestran los ndices de las tablas de usuario.
pg_statio_all_sequence s
Para cada objeto de secuencia en la base de datos actual, la secuencia de OID, esquema y nombre de la secuencia, el nmero de bloques de disco de lectura y amortiguar golpes en esa secuencia.
pg_statio_sys_sequence s
Igual que pg_statio_all_sequences , excepto que slo las secuencias del sistema se muestran. (En la actualidad, hay secuencias del
Ver Nombre
Descripcin sistema se definen, por lo que este punto de vista es siempre vaco.)
pg_statio_user_sequenc es
Igual que pg_statio_all_sequences , excepto que slo las secuencias de usuario se muestran.
pg_stat_user_functions
Para todas las funciones oruga, funcin OID, esquema, nombre, nmero de llamadas, el tiempo total y el tiempo libre. El tiempo mismo es la cantidad de tiempo empleado en la funcin en s, el tiempo total incluye el tiempo de permanencia en las funciones que llama. Los valores de tiempo estn en milisegundos.
Similar
pg_stat_xact_user_func tions
a pg_stat_user_functions , pero cuenta slo las llamadas durante la transaccin actual (que son no todava incluidos en pg_stat_user_functions).
Las estadsticas por ndices son particularmente tiles para determinar los ndices que se utilizan y qu tan efectivos son. Los ndices pueden ser utilizados ya sea directamente o por medio de "anlisis de mapa de bits" . En un anlisis de mapa de bits de la salida de varios ndices se pueden combinar mediante Y u O reglas, por lo que es difcil asociar fila del montn individuo obtiene con ndices especficos cuando se utiliza un anlisis de mapa de bits. Por lo tanto, un incremento de anlisis de mapa de bits los
pg_stat_all_indexes . idx_tup_read cuenta (s) para el ndice (es) que utiliza, pg_stat_all_tables . idx_tup_fetch nmero de la tabla, pero no pg_stat_all_indexes . idx_tup_fetch .
y se incrementa la afecta a
esencialmente siempre igual. Ahora pueden ser diferentes, incluso sin tener en cuenta los anlisis de mapa de bits, porque ndice mientras
menor si las filas muertos o que an no comprometidos se recuperan mediante el ndice de . Los
pg_statio_ vistas son principalmente tiles para determinar la eficacia de la cach del
bfer. Cuando el nmero de lecturas de disco real es mucho menor que el nmero de accesos de amortiguamiento, a continuacin, la memoria cach es satisfactorio peticiones ms ledos sin invocar una llamada ncleo. Sin embargo, estas estadsticas no dan toda la historia: debido a la forma en que PostgreSQL se encarga de disco I / O, los datos que no se encuentra en el PostgreSQL buffer cache an podra residir en la cach del kernel I / O, y podra por lo tanto todava se encontraron sin necesidad de una lectura fsica. Los usuarios interesados en obtener informacin ms detallada sobre PostgreSQL I / O comportamiento se aconseja utilizar elPostgreSQL recolector de estadsticas en combinacin con utilidades del sistema operativo que permiten comprender el manejo del kernel de I / O. Otras formas de ver las estadsticas pueden ser establecidos por escrito las consultas que utilizan las mismas funciones de acceso a las estadsticas subyacentes ya que estos puntos de vista estndar hacen. Estas funciones se enumeran en la Tabla 27-2 . Las funciones de acceso a bases de datos-por tener una base de datos OID como argumento para determinar qu base de datos para informar sobre. Las funciones de cada tabla y por ndice de tomar una tabla o ndice OID. Las funciones para las estadsticas de la funcin de llamada tienen una funcin OID. (Tenga en cuenta que slo las tablas, ndices y funciones de la base de datos actual se pueden ver con estas funciones.) Las funciones de acceso por servidor, los procesos que tienen un nmero de proceso del servidor, que va de uno a varios procesos de servidor activos. Tabla 27-2. Estadsticas Funciones de acceso
Funcin
Tipo devuelto
Descripcin
enter o
Funcin
Tipo devuelto
Descripcin
bigin t
Nmero de bloque de disco traiga solicitudes que se encuentran en la cach de base de datos
pg_stat_get_db_tuples_ returned ( OID ) pg_stat_get_db_tuples_ fetched ( OID ) pg_stat_get_db_tuples_ inserted ( OID ) pg_stat_get_db_tuples_ updated ( OID ) pg_stat_get_db_tuples_
Funcin
Tipo devuelto
Descripcin
deleted ( OID )
base de datos
bigin t
Nmero de consultas cancelado debido a un conflicto con la recuperacin de espacios de tabla se redujo la base de datos
bigin t
Nmero de consultas cancelado debido a un conflicto de recuperacin con bloqueos en la base de datos
bigin t
Nmero de consultas cancelado debido a un conflicto de recuperacin con instantneas antiguas en la base de datos
bigin t
Nmero de consultas cancelado debido a un conflicto de recuperacin de topes fijados en la base de datos
bigin t
Nmero de consultas cancelado debido a un conflicto de recuperacin con bloqueos en la base de datos
times tampt z
Tiempo de las ltimas estadsticas de restablecer la base de datos. Inicializado a la hora del sistema durante la primera conexin con cada base de datos. El tiempo de reposicin se actualiza cuando se llama pg_stat_reset en la base de datos, as como en la
Funcin
Descripcin
de pg_stat_reset_sing
le_table_counters cont
ra cualquier tabla o ndice en el mismo.
pg_stat_get_numscans ( OID )
bigin t
Nmero de exploraciones secuenciales realizados cuando el argumento es una tabla, o el nmero de ndice escanea hecho cuando el argumento es un ndice
bigin t
Nmero de filas ledas por exploraciones secuenciales cuando el argumento es una tabla, o el nmero de entradas de ndice devuelto cuando el argumento es un ndice
bigin t
Nmero de filas de la tabla cogi por los anlisis de mapa de bits cuando el argumento es una tabla, o filas de la tabla cogi por las exploraciones de ndices simples utilizando el ndice cuando el argumento es un ndice
bigin t bigin t
Funcin
Tipo devuelto
Descripcin
pg_stat_get_tuples_del eted ( OID ) pg_stat_get_tuples_hot _updated ( OID ) pg_stat_get_live_tuple s ( OID ) pg_stat_get_dead_tuple s ( OID ) pg_stat_get_blocks_fet ched ( OID )
pg_stat_get_blocks_hit ( OID )
bigin t
Hora del ltimo no COMPLETO vaco iniciada por el usuario en esta tabla
Hora del ltimo vaco iniciada por el demonio autovacuum en esta tabla
Funcin
Tipo devuelto
Descripcin
Hora del ltimo analice iniciado por el demonio autovacuum en esta tabla
pg_stat_get_vacuum_cou nt ( OID )
bigin t
bigin t
El nmero de veces que esta tabla ha sido aspirado por el demonio autovacuum
bigin t
bigin t
El nmero de veces que esta tabla ha sido analizado por el demonio autovacuum
bigin t
Nmero de exploraciones secuenciales realizados cuando el argumento es una tabla, o el nmero de ndice escanea hecho cuando el argumento es un ndice, en la transaccin actual
Funcin
Tipo devuelto
Descripcin
bigin t
Nmero de filas ledas por exploraciones secuenciales cuando el argumento es una tabla, o el nmero de entradas de ndice devuelto cuando el argumento es un ndice, en la transaccin actual
bigin t
Nmero de filas de la tabla cogi por los anlisis de mapa de bits cuando el argumento es una tabla, o filas de la tabla cogi por las exploraciones de ndices simples utilizando el ndice cuando el argumento es un ndice, en la transaccin actual
bigin t
bigin t
Funcin
Tipo devuelto
Descripcin
transaccin actual
bigin t
Nmero de peticiones de bloques de disco que se encuentran en cach para la tabla o ndice, en la transaccin actual
pg_backend_pid ()
enter o
recor d setof
Devuelve un registro de informacin sobre el servidor con el PID especificado, o un registro para cada backend activo en el sistema si NULL se especifica. Los campos devueltos son un subconjunto de los de la pg_stat_activity vist a.
bigin t
bigin t
Tiempo total de reloj de pared pas en la funcin, en microsegundos. Incluye el tiempo de permanencia en las funciones llamadas por este.
pg_stat_get_function_s
bigin
Funcin
Tipo devuelto
Descripcin
t bigin t
a funciones llamadas.
bigin t
Tiempo total de reloj de pared pas en la funcin, en microsegundos, en la transaccin actual. Incluye el tiempo de permanencia en las funciones llamadas por este.
bigin t
El tiempo dedicado a esta funcin nica, en la transaccin actual. Se excluye el tiempo dedicado a funciones llamadas.
pg_stat_get_backend_id set ()
setof enter o
Conjunto de nmeros de servidor de proceso actualmente activos (entre 1 y el nmero de procesos de servidor activas).Ver ejemplo de uso en el texto.
enter o
oid
pg_stat_get_backend_us
oid
Funcin
Descripcin
texto
Activo comando del proceso de servidor determinado, pero slo si el usuario actual es superusuario o el mismo usuario que la de la sesin de que se consulta (y track_activities est activada)
boole ano
Verdadero si el proceso de servidor dada est esperando para un bloqueo, pero slo si el usuario actual es superusuario o el mismo usuario que la de la sesin de que se consulta (y track_activities est activada)
Fecha y hora con zona horar ia Fecha y hora con zona horar
El momento en que se inici el proceso de servidor dada 'consulta se est ejecutando actualmente, pero slo si el usuario actual es superusuario o el mismo usuario que la de la sesin de que se consulta (y track_activities est activada)
El momento en que la transaccin se est ejecutando el proceso de servidor dada "se inici, pero slo si el usuario actual es superusuario o el mismo usuario que la de la sesin de que se consulta (y track_activities est
Funcin
Tipo devuelto
Descripcin
activada)
El momento en que se inici el proceso de servidor determinado, o null si el usuario actual no es un usuario root, ni el mismo usuario que la de la sesin de que se consulta
inet
La direccin IP del cliente conectado al proceso de servidor determinado, nulo si la conexin se realiza a travs de un socket de dominio Unix, tambin nulo si el usuario actual no es un usuario root, ni el mismo usuario que la de la sesin de que se consulta
enter o
El nmero de puerto TCP del cliente conectado al proceso de servidor determinado, -1 si la conexin se realiza a travs de un socket de dominio Unix, null si el usuario actual no es un usuario root, ni el mismo usuario que la de la sesin de que se consulta
pg_stat_get_bgwriter_t imed_checkpoints ()
bigin t
Nmero de veces que el escritor fondo ha comenzado controles programados (porque el checkpoint_timeout
Funcin
Tipo devuelto
Descripcin
tiempo ha expirado)
pg_stat_get_bgwriter_r equested_checkpoints ()
bigin t
Nmero de veces que el escritor fondo ha comenzado los puestos de control en base a las solicitudes de los backends porque el checkpoint_segment
pg_stat_get_bgwriter_b uf_written_checkpoints ()
bigin t
pg_stat_get_bgwriter_b uf_written_clean ()
bigin t
Nmero de buffers escrito por el escritor de fondo para la limpieza rutinaria de pginas sucias
pg_stat_get_bgwriter_m axwritten_clean ()
bigin t
Nmero de veces que el escritor fondo ha detenido su anlisis de limpieza, ya que ha escrito ms buffers de lo especificado en el bgwriter_lru_maxpa
ges parmetro
Tiempo de las ltimas estadsticas restablece para el escritor de fondo, actualizada al ejecutar pg_stat_reset_s
pg_stat_get_bgwriter_s tat_reset_time ()
times tampt z
hared ('bgwriter') en
Funcin
Tipo devuelto
Descripcin
pg_stat_get_buf_writte n_backend ()
bigin t
Nmero de bferes escritos por backends porque necesitaban para asignar un nuevo buffer
pg_stat_get_buf_alloc ()
bigin t
pg_stat_get_wal_sender s ()
recor d setof
Un registro para cada remitente wal activo. Los campos devueltos son un subconjunto de los de la pg_stat_replicatio
nvista.
pg_stat_clear_snapshot ()
anula r
pg_stat_reset ()
anula r
Restablecer todos los contadores de estadsticas de la base de datos actual a cero (requiere privilegios de superusuario)
pg_stat_reset_shared ( texto)
anula r
Restaura alguno de los contadores de estadsticas compartidas para el cluster de base de datos a cero (requiere privilegios de superusuario). Llamando pg_sta
Funcin
Tipo devuelto
Descripcin
por pg_stat_bgwriter .
anula r
Restablecer las estadsticas de una sola tabla o ndice en la base de datos actual a cero (requiere privilegios de superusuario)
anula r
Restablecer las estadsticas de una sola funcin en la base de datos actual a cero (requiere privilegios de superusuario)
pg_stat_get_blocks_fetched menos pg_stat_get_blocks_hit da el read () llama emitida para la tabla, ndice o base de datos, el nmero de *
nmero de kernel
lecturas fsicas real suele ser menor debido al buffering a nivel de kernel. Los
funcinpg_stat_get_backend_idset proporciona una manera conveniente para generar una fila para cada proceso de servidor activo. Por ejemplo, para mostrar el PID s y consultas actuales de todos los procesos del servidor:
SELECT pg_stat_get_backend_pid (s.backendid) AS procpid, pg_stat_get_backend_activity (s.backendid) AS current_query FROM (SELECT pg_stat_get_backend_idset () AS backendid) AS s;
sistema. Permite al administrador de base de datos para ver informacin sobre los bloqueos pendientes en el gestor de bloqueos. Por ejemplo, esta capacidad se puede utilizar para:
Ver todos los bloqueos actualmente en circulacin, todas las cerraduras de las relaciones en una base de datos especial, todas las cerraduras en una relacin particular o todos los bloqueos mantenidos por un particular, PostgreSQL sesin.
Determinar la relacin de la base de datos actual con las cerraduras ms Ungranted (que podran ser una fuente de conflicto entre los clientes de bases de datos).
Determinar el efecto de contencin de bloqueo en el rendimiento general de base de datos, as como el grado en que vara con la contencin del trfico global de base de datos.
Los detalles de la
probes.h .
Nombre
Parmetros
Descripcin
transaccin (LocalTransactio Sondeo que se activa al inicio de una nueva transaccin. arg0 es de inicio nId) el ID de la transaccin.
transaccion (LocalTransactio Sondeo que se activa cuando una transaccin se realiza es cometer nId) correctamente. arg0 es el ID de la transaccin.
operacin de aborto
(LocalTransactio Sondeo que se activa cuando se completa una transaccin sin nId) xito. arg0 es el ID de la transaccin.
Sondeo que se activa cuando se inicia el proceso de una consulta. arg0 es la cadena de consulta.
consultahecho
(Const char *)
Sondeo que se activa cuando el proceso de una consulta se ha completado. arg0 es la cadena de consulta.
consultaparse de
(Const char *)
Nombre inicio
Parmetros
consultaparsehecho
(Const char *)
Sondeo que se activa cuando el anlisis de una consulta se ha completado. arg0 es la cadena de consulta.
consultarewritestart
(Const char *)
Sondeo que se activa cuando la reescritura de una consulta que se inicia. arg0 es la cadena de consulta.
consultarewritehecho
(Const char *)
Sondeo que se activa cuando la reescritura de una consulta se ha completado. arg0 es la cadena de consulta.
consulta a ejecutarhecho
()
declaracin
(Const char *)
Sondeo que se activa cada vez que el proceso actualiza su servidor pg_stat_activity . current_quer
Nombre de estado
Parmetros
Descripcin
(Int)
Sondeo que se activa cuando un puesto de control se ha completado. (Las sondas que aparece junto incendio en (Int, int, int, int, secuencia durante el procesamiento de punto de control.) Arg0 int) es el nmero de bferes escritos. arg1 es el nmero total de bferes. arg2, arg3 y arg4 contienen el nmero de archivo xlog (s) aadido, eliminado y reciclado respectivamente.
Sondeo que se activa cuando se inicia la parte CLOG de un puesto de control. arg0 es cierto para puesto de control normal, falso puesto de control de parada.
Sondeo que se activa cuando la parte CLOG de un puesto de control se ha completado. arg0 tiene el mismo significado que para el zueco-puesto de control de arranque.
(Bool)
Sondeo que se activa cuando se inicia la parte SUBTRANS de un puesto de control. arg0 es cierto para puesto de control normal, falso puesto de control de parada.
Sondeo que se activa cuando la parte SUBTRANS de un puesto de control se ha completado. arg0 tiene el mismo significado que para subtrans-puesto de control de arranque.
Nombre
Parmetros
Descripcin
(Bool)
Sondeo que se activa cuando se inicia la parte MultiXact de un puesto de control. arg0 es cierto para puesto de control normal, falso puesto de control de parada.
Sondeo que se activa cuando la parte MultiXact de un puesto de control se ha completado. arg0 tiene el mismo significado que para multixact-puesto de control de arranque.
(Int)
Sondeo que se activa cuando se inicia la parte de bfer de escritura de un puesto de control. arg0 contiene los indicadores a nivel de bits utilizados para distinguir los diferentes tipos de puntos de control, como el apagado, inmediatos o fuerza.
buffersync-start
(Int, int)
Sondeo que se activa cuando empezamos a escribir buffers modificados durante el puesto de control (despus de la identificacin de los topes deben ser escritos). arg0 es el nmero total de bferes. arg1 es el nmero que actualmente estn sucias y necesitan ser por escrito.
buffersyncescrito
(Int)
Sondeo que se activa despus de cada bfer se escribe en puesto de control. arg0 es el nmero de identificacin de la memoria intermedia.
Sondeo que se activa cuando los buffers modificados se han escrito. arg0 es el nmero total de bferes. arg1 es el nmero de buffers en realidad escritas por el proceso de punto de control. arg2 es el nmero que se espera que sea por escrito (arg1 de buffer-sync-start), cualquier diferencia refleja otros procesos de lavado buffers en el puesto de control.
bufferpuesto de
()
Sondeo que se activa despus de buffers modificados se han escrito para el kernel, y antes de empezar a emitir solicitudes
Parmetros fsync.
Descripcin
buffercheckpoint () -hecho
()
Sondeo que se activa cuando se inicia la porcin de dos fases de un puesto de control.
Sondeo que se activa cuando la porcin de dos fases de un puesto de control se ha completado.
Sondeo que se activa cuando se inicia una lectura buffer. arg0 y arg1 contienen los nmeros de la horquilla y el bloque de la pgina (pero arg1 ser -1 si se trata de una solicitud de prrroga de relacin). arg2, arg3 y arg4 contiene el espacio de tablas, base de datos, y la relacin OID identificar la relacin. arg5 es el ID de la backend que cre la relacin temporal para un bfer local, o InvalidBackendId (-1) para un bfer compartido. arg6 es cierto para una solicitud de prrroga relacin, falsa lectura normal.
Sondeo que se activa cuando un bfer de lectura se ha completado. arg0 y arg1 contienen los nmeros de la horquilla y el bloque de la pgina (si se trata de una solicitud de prrroga relacin, arg1 contiene ahora el nmero de bloque del bloque recin agregado). arg2, arg3 y arg4 contiene el espacio de tablas, base de datos, y la relacin OID identificar la relacin. arg5 es el ID de la backend que cre la relacin temporal para un bfer local, o InvalidBackendId (-1) para un bfer compartido. arg6 es cierto para una solicitud de prrroga relacin, falsa lectura
Nombre
Parmetros
Descripcin normal. arg7 es cierto si se encontr el tampn en la piscina, false en caso contrario.
buffer-ras de inicio
Sondeo que se activa antes de emitir cualquier peticin de escritura de un buffer compartido. arg0 y arg1 contienen los nmeros de la horquilla y el bloqueo de la pgina. arg2, arg3 y arg4 contiene el espacio de tablas, base de datos, y la relacin OID identificar la relacin.
Sondeo que se activa cuando una solicitud de escritura se ha completado. (Tenga en cuenta que esto slo refleja el tiempo para pasar los datos al kernel,. Que en realidad no se suelen escribir en el disco an) Los argumentos son los mismos que para el buffer-ras-start.
Sondeo que se activa cuando un proceso de servidor comienza a escribir un buffer sucio. (Si esto sucede a menudo, implica que shared_buffers es demasiado pequeo o los parmetros de control bgwriter necesitan ajuste.) arg0 y arg1 contiene los nmeros de la horquilla y el bloqueo de la pgina. arg2, arg3 y arg4 contiene el espacio de tablas, base de datos, y la relacin OID identificar la relacin.
bufferwritesuciahecho
Sondeo que se activa cuando una escritura sucia-buffer se ha completado. Los argumentos son los mismos que para el bfer de escritura-sucio-inicio.
wal-bufferwrite() sucia-start
Sondeo que se activa siempre que un proceso de servidor comienza a escribir un buffer WAL sucia porque no hay ms espacio tampn WAL est disponible. (Si esto sucede a menudo, implica que wal_buffers es demasiado pequeo.)
Nombre
Parmetros
Descripcin
wal-bufferwrite() suciahecho
Sondeo que se activa cuando se inserta un disco WAL. arg0 es el (Unsigned char, xlog-insert gestor de recursos (rmid) para el registro. arg1 contiene las unsigned char) banderas informacin.
xlog-switch ()
Sondeo que se activa al comenzar a leer un bloque de una relacin. arg0 y arg1 contienen los nmeros de la horquilla y el bloqueo de la pgina.arg2, arg3 y arg4 contiene el espacio de tablas, base de datos, y la relacin OID identificar la relacin. arg5 es el ID de la backend que cre la relacin temporal para un bfer local, o InvalidBackendId (-1) para un bfer compartido.
Sondeo que se activa cuando un bloque de lectura se ha completado. arg0 y arg1 contienen los nmeros de la horquilla y el bloqueo de la pgina.arg2, arg3 y arg4 contiene el espacio de tablas, base de datos, y la relacin OID identificar la relacin. arg5 es el ID de la backend que cre la relacin temporal para un bfer local, o InvalidBackendId (-1) para un bfer compartido. arg6 es el nmero de bytes realmente ledos, mientras que arg7 es el nmero solicitado (si stos son diferentes que indica problemas).
Sondeo que se activa al comenzar a escribir un bloque a una relacin. arg0 y arg1 contienen los nmeros de la horquilla y el bloqueo de la pgina.arg2, arg3 y arg4 contiene el espacio de tablas, base de datos, y la relacin OID identificar la
Nombre
Parmetros int)
Descripcin relacin. arg5 es el ID de la backend que cre la relacin temporal para un bfer local, o InvalidBackendId (-1) para un bfer compartido.
Sondeo que se activa cuando un bloque de escritura se ha completado. arg0 y arg1 contienen los nmeros de la horquilla y el bloqueo de la pgina.arg2, arg3 y arg4 contiene el espacio de tablas, base de datos, y la relacin OID identificar la relacin. arg5 es el ID de la backend que cre la relacin temporal para un bfer local, o InvalidBackendId (-1) para un bfer compartido. arg6 es el nmero de bytes realmente escritos, mientras que arg7 es el nmero solicitado (si stos son diferentes que indica problemas).
tipo de inicio
Sondeo que se activa cuando se inicia una operacin de ordenacin. arg0 indica montn, ndice o tipo de referencia. arg1 (Int, int, int, int, es cierto para la ejecucin singular valor. arg2 es el nmero de bool) columnas de clave. arg3 es el nmero de kilobytes de memoria de trabajo permitidas. arg4 es cierto si se requiere acceso aleatorio al resultado especie.
Sondeo que se activa cuando una especie se ha completado. arg0 es cierto para ordenar externa, falsa clasificacin interna. arg1 es el nmero de bloques de disco usados para una especie externa o kilobytes de memoria utilizada para una clasificacin interna.
lwlock a adquirir
(LWLockId, LWLockMode)
Sondeo que se activa cuando un LWLock se ha adquirido. arg0 es el ID del LWLock. arg1 es el modo de bloqueo solicitado, ya sea exclusiva o compartida.
lwlock de liberacin
(LWLockId)
Sondeo que se activa cuando un LWLock ha sido puesto en libertad (pero tenga en cuenta que los camareros liberados an no han despertado).arg0 es el ID del LWLock.
Nombre
Parmetros
Descripcin
lwlockwait-start
(LWLockId, LWLockMode)
Sondeo que se activa cuando un LWLock no estuvo disponible de inmediato y un proceso servidor ha empezado a esperar a que el bloqueo est disponible. arg0 es el ID del LWLock. arg1 es el modo de bloqueo solicitado, ya sea exclusiva o compartida.
lwlockwait-done
(LWLockId, LWLockMode)
Sondeo que se activa cuando un proceso del servidor se ha liberado de su espera para una LWLock (que en realidad no tiene el bloqueo an). arg0 es el ID del LWLock. arg1 es el modo de bloqueo solicitado, ya sea exclusiva o compartida.
Sondeo que se activa cuando un LWLock fue adquirido exitosamente cuando la persona que llama se especifica sin esperas. arg0 es el ID del LWLock. arg1 es el modo de bloqueo solicitado, ya sea exclusiva o compartida.
Sondeo que se activa cuando un LWLock no fue adquirido exitosamente cuando la persona que llama se especifica sin esperas. arg0 es el ID del LWLock. arg1 es el modo de bloqueo solicitado, ya sea exclusiva o compartida.
lock-waitstart
(Unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, LockMode)
Sondeo que se activa cuando una solicitud de una cerradura de peso pesado (bloqueo lmgr) ha comenzado a esperar porque la cerradura no est disponible. arg0 travs arg3 son los campos de la etiqueta de identificacin del objeto bloqueado. arg4 indica el tipo de objeto que est siendo bloqueado. arg5 indica el tipo de bloqueo que se solicita.
lock-waitdone
(Unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, LockMode)
Sondeo que se activa cuando una solicitud de una cerradura de peso pesado (bloqueo lmgr) ha terminado de espera (es decir, ha adquirido la cerradura). Los argumentos son los mismos que para el bloqueo-espera-inicio.
Nombre
Parmetros
Descripcin
Sondeo que se activa cuando un callejn sin salida, apreciada por el detector de punto muerto.
Tipo
Definicin
LWLockId
int
LWLockMode
int
LockMode
int
BlockNumber
unsigned int
Oid
unsigned int
ForkNumber
int
bool
carbn
postgresql $ 1 ::: transaccin de inicio { @ Inicio ["Start"] = count (); self-> ts = marca de tiempo; }
postgresql $ 1 ::: transaccin-commit / Self-> ts / { @ Commit ["Commit"] = count (); @ Tiempo ["El tiempo total (ns)"] = suma (timestamp - self> ts); self-> ts = 0; }
Nota: SystemTap utiliza una notacin diferente para los scripts de traza de DTrace hace, a pesar de que los puntos de rastreo subyacentes son compatibles. Un punto a destacar es que en este escrito, los scripts de SystemTap deben hacer referencia a los nombres de la sonda con doble subrayado en lugar de guiones. Esto se espera est solucionado en futuras versiones de SystemTap. Usted debe recordar que los scripts de DTrace se deben escribir y depurar con cuidado, de lo contrario la informacin de rastreo recopilada puede ser sentido. En la mayora de los casos se encuentran problemas cuando se trata de la instrumentacin que tiene la culpa, no el sistema subyacente. Cuando se habla de informacin que se encuentra la utilizacin del rastreo dinmico, asegrese de incluir el script utilizado para permitir que tambin se comprueba y se discute. Ms scripts de ejemplo se puede encontrar en el pgFoundry proyecto dtrace .
3. Incluir
pg_trace.h si no est ya presente en el mdulo (s) que contiene los puntos de TRACE_POSTGRESQL macros de sonda en las posiciones deseadas
sondeo, e insertar
en el cdigo fuente 4. Vuelva a compilar y verificar que las nuevas sondas estn disponibles Ejemplo: A continuacin se muestra un ejemplo de cmo se debera aadir una sonda para rastrear todas las nuevas transacciones por ID de transaccin. 1. Decide que la sonda se llamar de tipo LocalTransactionId 2. Aadir la definicin sonda
Observe el uso de la doble subrayado en el nombre de la sonda. En una secuencia de comandos de DTrace mediante la sonda, el doble subrayado tiene que ser sustituido por un guin, por lo que para los usuarios. 4. En tiempo de compilacin, llamada
5. TRACE_POSTGRESQL_TRANSACTION_START (vxid.localTransactionId);
6. Despus de volver a compilar y ejecutar el nuevo binario, compruebe que la sonda recin agregado est disponible, ejecute el comando siguiente DTrace. Deber ver un resultado similar:
9. 18705 postgresql49878 postgres StartTransactionCommand transaccin de inicio 10. 18755 postgresql49877 postgres
Usted debe tener cuidado de que los tipos de datos especificados para los parmetros de un sondeo coinciden con los tipos de las variables utilizadas en la macro de datos. De lo contrario, recibir errores de compilacin.
- enable-dtrace ,
los argumentos de una macro rastro sern evaluados cuando el control pasa a travs de la macro,incluso si no se efecta ningn seguimiento . Esto por lo general no vale la pena preocuparse si usted est reportando los valores de algunas variables locales. Pero ten cuidado de poner las llamadas a funciones caros en los argumentos. Si tiene que hacerlo, tenga en cuenta la proteccin de la macro con una comprobacin para ver si el seguimiento est habilitado en realidad:
if (TRACE_POSTGRESQL_TRANSACTION_START_ENABLED ())
HABILITADO macro.
ruta del archivo es de inters si desea examinar archivos de disco de la tabla directamente. Para mostrar el espacio usado por TOSTADA tablas, utilice una consulta similar a la siguiente:
SELECT relname, relpages DE pg_class, (SELECT reltoastrelid DE pg_class DONDE relname = "cliente") AS ss DONDE oid = ss.reltoastrelid O oid = (SELECT reltoastidxid DE pg_class DONDE oid = ss.reltoastrelid) ORDER BY relname;
SELECT c2.relname, c2.relpages DE pg_class c, pg_class c2, pg_index i DONDE c.relname = "cliente" Y c.oid = i.indrelid Y c2.oid = i.indexrelid ORDER BY c2.relname;
Si no puede liberar espacio adicional en el disco eliminando otras cosas, puede mover algunos de los archivos de base de datos a otros sistemas de archivos mediante el uso de espacios de tabla. Consulte la Seccin 21.6 para ms informacin sobre esto. Consejo: Algunos sistemas de archivos mal rendimiento cuando estn casi lleno, as que no espere hasta que el disco est completamente lleno de actuar. Si su sistema es compatible con las cuotas de disco por usuario, a continuacin, la base de datos ser, naturalmente, sujeta a las cuotas se coloca en el usuario ejecuta el servidor. Exceder el cupo tendr los mismos efectos negativos como la falta de espacio en disco por completo.
29.1. Confiabilidad
La fiabilidad es una propiedad importante de cualquier sistema de base de datos seria, y PostgreSQL hace todo lo posible para garantizar un funcionamiento fiable. Un aspecto de funcionamiento fiable es que todos los datos registrados por una transaccin confirmada deben ser almacenados en un rea no voltil que est a salvo de la prdida de potencia, fallo del sistema operativo, y fallos de hardware (excepto fracaso de la propia rea no voltil, por supuesto). Escribir correctamente los datos en el almacenamiento permanente de la computadora (unidad de disco o equivalente) normalmente cumple con este requisito. De hecho, incluso si un equipo se daa fatalmente, si las unidades de disco sobreviven se pueden mover a otro equipo con hardware similar y todas las transacciones confirmadas se mantendrn intactos. Si bien obligando a los datos de los platos del disco peridicamente puede parecer una operacin simple, no lo es. Como las unidades de disco son dramticamente ms lento que la memoria principal y la CPU, existen varios niveles de almacenamiento en cach entre la memoria principal de la computadora y los platos del disco. En primer lugar, hay buffer cache del sistema operativo, que almacena los bloques de disco solicitados con frecuencia y combina escrituras en disco. Afortunadamente, todos los sistemas operativos proporcionan aplicaciones de una manera
de forzar escribe desde la cach del bfer en el disco, y PostgreSQL utiliza esas caractersticas. (Vea el wal_sync_method parmetro para ajustar cmo se hace esto.) Despus, puede haber una memoria cach en el controlador de la unidad de disco, lo que es particularmente comn en RAID tarjetas controladoras. Algunos de estos escondites estnwritethrough , es decir, las escrituras se enva a la unidad tan pronto como llegan. Otros son de reescritura , es decir, los datos se envan a la unidad en algn momento posterior. Estas cachs pueden ser un peligro de fiabilidad debido a la memoria en la cach de controlador de disco es voltil, y perdern sus contenidos en un corte de energa. Mejores tarjetas controladoras tienen unidades de batera de respaldo ( BBU s), lo que significa que la tarjeta tiene una batera que mantiene la potencia en la memoria cach en caso de prdida de alimentacin del sistema. Despus de que se restablezca el suministro elctrico, los datos se escriben en las unidades de disco. Y, por ltimo, la mayora de las unidades de disco tienen cachs. Algunos son escritura a travs mientras que algunos son write-back, y existen las mismas preocupaciones sobre la prdida de datos de las cachs de unidad de escritura no simultnea como para cachs de controlador de disco. IDE Consumidor de grado y SATA son especialmente propensos a tener write-back cachs que no va a sobrevivir un apagn. Muchas unidades de estado slido (SSD) tambin tienen voltiles caches write-back. Estas cachs normalmente se pueden desactivar, pero el mtodo para hacer esto vara segn el sistema operativo y el tipo de unidad:
En Linux , los discos IDE se pueden consultar usando est habilitada si hay un
* junto a tu cach . hdparm-W se puede utilizar para sdparm - get = WCE para comprobar si la cach de
desactivar la cach de escritura. Unidades SCSI pueden ser consultados mediante sdparm . Utilice escritura est activada y
En FreeBSD , los discos IDE se pueden consultar utilizando escritura desactivado usando
format-e . (El
Solaris ZFS sistema de archivos est segura con disco cach de escritura habilitada ya que emite sus propios comandos de cach de vaciado de disco.)
El de Windows , si
cach de escritura.
wal_sync_method a fsync_writethrough .
Las unidades SATA recientes (los que siguen ATAPI-6 o posterior) ofrecen un comando flush cach de la unidad (
FLUSH CACHE EXT ), mientras que las unidades SCSI han apoyado SYNCHRONIZE CACHE . Estos comandos no son
directamente accesibles a PostgreSQL , pero algunos sistemas de archivos (por ejemplo, ZFS , ext4 ) pueden utilizarlos para limpiar datos en los discos en las unidades de escritura no habilitados. Desafortunadamente, estos sistemas de archivos se comportan de manera subptima cuando se combina con una unidad de batera de reserva ( BBU ) controladores de disco. En tales configuraciones, el comando de todas las fuerzas de sincronizar los datos de la cach de la controladora a los discos, lo que elimina la mayor parte del beneficio de la BBU. Puede ejecutar el pg_test_fsync mdulo para ver si se ven afectados. Si se ve afectado, los beneficios de rendimiento de la BBU puede ser recuperado por apagar las barreras de escritura en el sistema de archivos o volver a configurar el controlador de disco, si eso es una opcin. Si las barreras de escritura se desactivan, asegrese de que la batera sigue siendo funcional, una batera defectuosa puede potencialmente conducir a la prdida de datos. Esperemos que el sistema de archivos y el disco diseadores controlador eventualmente resolver este comportamiento subptimo. Cuando el sistema operativo enva una peticin de escritura en el hardware de almacenamiento, hay poco que puede hacer para asegurarse de que los datos han llegado a una zona verdaderamente no voltil de almacenamiento. Ms bien, es la responsabilidad del administrador para asegurarse de que todos los componentes de almacenamiento de asegurar la integridad de los datos. Evite los controladores de disco que tienen cachs de escritura sin batera de
respaldo. A nivel de unidad, deshabilitar el write-back caching si la unidad no puede garantizar que los datos se escriben antes de la parada. Si utiliza discos SSD, tenga en cuenta que muchos de ellos no respetan los comandos flush cach por defecto. Puede comprobar el comportamiento del subsistema E / S confiable usando
diskchecker.pl .
Otro de los riesgos de prdida de datos es el que plantea el plato en s las operaciones de escritura de disco. Bandejas de discos se dividen en sectores, comnmente 512 bytes cada uno.Cada operacin de lectura o escritura fsica procesa todo un sector. Cuando una solicitud de escritura llega a la unidad, que podra ser de un mltiplo de 512 bytes ( PostgreSQLnormalmente escribe 8192 bytes, o 16 sectores, a la vez), y el proceso de escritura podra fallar debido a la prdida de potencia en cualquier momento, lo que significa algunos de los sectores de 512 bytes se escribieron mientras que otros no lo eran. Para evitar estos fallos, PostgreSQL escribe peridicamente imgenes a toda pgina con el almacenamiento WAL permanente antes modificar la pgina actual en el disco. De esta manera, durante el accidente de la recuperacin de PostgreSQL puede restaurar pginas parcialmente escritas de WAL. Si usted tiene un software de sistema de archivos que impide que parte de la pgina, escribe (por ejemplo, ZFS), puede desactivar esta pagina imagen apagando el full_page_writesparmetro. Controladores de disco Unidad de respaldo de batera (BBU) no impiden que parte de la pgina, escribe a menos que garantizan que los datos se escriben en el BBU como pginas completas (8kB).
de los archivos de datos o archivos WAL. De hecho, el diario sobrecarga puede reducir su rendimiento, especialmente si en diario causas del sistema de archivos de datos que se vuelca en disco. Afortunadamente, los datos lavado diario durante menudo se pueden desactivar con la opcin de montaje del sistema de archivos, por ejemplo,
data = reescritura en un
sistema de archivos Linux ext3. Sistemas de archivos registrados por diario hacen mejorar la velocidad de arranque despus de un accidente. Usando WAL resultados en un nmero significativamente menor de escrituras en disco, ya que slo el archivo de registro tiene que ser volcado a disco para garantizar que una transaccin se confirma, en lugar de todos los archivos de datos modificados por la transaccin. El archivo de registro se escribe secuencialmente, y por lo que el costo de la sincronizacin del registro es mucho menor que el costo de lavado de las pginas de datos. Esto es especialmente cierto para los servidores de manejo de muchas pequeas transacciones que tocan diferentes partes del almacn de datos. Por otra parte, cuando el servidor est procesando muchas pequeas transacciones simultneas, una muchas transacciones. WAL tambin hace posible para apoyar copia de seguridad en lnea y la recuperacin de punto en el tiempo, como se describe en la Seccin 24.3 . Al archivar los datos WAL podemos apoyar a volver a cualquier instante de tiempo cubierto por los datos disponibles WAL: simplemente instalamos una copia de seguridad fsica antes de la base de datos, y reproducir el registro de WAL tan lejos como el tiempo deseado. Lo que es ms, la copia de seguridad fsica no tiene por qu ser una instantnea instantnea del estado de la base de datos - si est hecho sobre un cierto perodo de tiempo, y luego repetir el registro de WAL para ese perodo fijar las incoherencias internas.
del servidor inmediatamente despus. Sin embargo, para las transacciones a corto esta demora es un componente importante del tiempo total de la transaccin. Al seleccionar el modo de entrega asncrona significa que el servidor devuelve el xito, tan pronto como se complete la transaccin, lgicamente, antes de la WAL registros que genera realmente han hecho su camino en el disco. Esto puede proporcionar un impulso significativo en el rendimiento para las pequeas transacciones. Commit asincrnico introduce el riesgo de prdida de datos. Hay una ventana de tiempo entre el informe de finalizacin de la transaccin con el cliente y el tiempo que la transaccin est verdaderamente comprometido (es decir, no se garantiza que se perder si el servidor se bloquea). As confirmacin asincrnica no debe utilizarse si el cliente tomar las acciones exteriores que dependen de la suposicin de que la transaccin ser recordado. Como un ejemplo, un banco sin duda no utilizar asncrono cometer para una transaccin de un cajero automtico de registro de dispensacin de dinero en efectivo. Pero en muchos escenarios, como por ejemplo el registro de eventos, no hay necesidad de una fuerte garanta de este tipo. El riesgo que se toma mediante el uso de compromiso asncrono es de prdida de datos, no corrupcin de los datos. Si la base de datos debe fallar, se recuperar mediante la reproduccin de WAL hasta el ltimo registro que se sonroj. Por tanto, la base de datos se restaura a un estado de auto-consistente, pero las transacciones que an no se han volcado a disco no se reflejar en ese estado. Por tanto, el efecto neto es la prdida de las ltimas transacciones. Debido a que las transacciones se reproducen en el orden de compromiso, no hay inconsistencia puede ser introducido - por ejemplo, si la transaccin B hizo cambios que dependen de los efectos de una transaccin anterior A, no es posible para los efectos de A a ser perdidas mientras que los efectos de B se conservan. El usuario puede seleccionar el modo de confirmacin de cada transaccin, por lo que es posible tener transacciones de ejecucin sincrnicos y asincrnicos se ejecutan simultneamente.Esto permite flexibilidad equilibrio entre el rendimiento y la seguridad de la durabilidad transaccin. La modalidad de confirmacin es controlado por el parmetro configurable por el usuariosynchronous_commit , que se puede cambiar en cualquiera de las formas en que un parmetro de configuracin se pueden establecer. El modo utilizado para cualquier transaccin depende del valor de
synchronous_commit cuando comienza transaccin de confirmacin. DROP TABLE , se ven obligados a cometer synchronous_commit . Esto es
para garantizar la coherencia entre el sistema de archivos del servidor y el estado lgico de la base de datos. Los comandos de apoyo en dos fases, como tambin son siempre sincrnica. Si la base de datos se bloquea durante la ventana de riesgo entre un compromiso asncrona y la escritura de la transaccin WAL registros, entonces los cambios realizados durante la transaccin se perdern. La duracin de la ventana de riesgo es limitada debido a un proceso de fondo (el "WAL escritor" ) rubores no escritas WAL registros en el disco cadawal_writer_delay milisegundos. La duracin mxima real de la ventana de riesgo es tres veces
TRANSACCIN PREPARE ,
Precaucin
Un apagado de modo inmediato es equivalente a una cada del servidor, y por lo tanto causar la prdida de cualquier asncrono unflushed comete.
transacciones. Se deshabilita toda la lgica dentro de PostgreSQL que intenta sincronizar escribe a diferentes porciones de la base de datos, y por lo tanto un fallo del sistema (es decir, un hardware o cada del sistema operativo, no un fallo de PostgreSQL s mismo) podra dar lugar a mal arbitrariamente la corrupcin de la base de datos estado. En muchos escenarios, confirmacin asincrnica proporciona la mayor parte de la mejora del rendimiento que se podra obtener apagando
commit_delay tambin suena muy similar a commit asincrnico, pero en realidad es un mtodo de confirmacin sncrona (de hecho, asincrnica).
para purgar WAL en el disco, con la esperanza de que un solo ras ejecutado por uno de tales transaccin tambin puede servir a otras transacciones que cometen a aproximadamente el mismo tiempo. Configuracin
operaciones simultneamente cometer, y es difcil de ajustar a un valor que realmente ayuda ms que perjudica el rendimiento.
PUNTO DE CONTROL .
que se produzcan ms a menudo. Esto permite la recuperacin despus de una colisin ms rpido (ya que se necesita menos trabajo para ser hecho de nuevo). Sin embargo, hay que
equilibrar esta en contra del aumento del costo de lavado pginas de datos no ms a menudo. Sifull_page_writes se establece (como es el valor predeterminado), hay otro factor a considerar. Para garantizar la coherencia pgina de datos, la primera modificacin de una pgina de datos despus de los resultados de cada punto de control en el registro de la totalidad del contenido de la pgina. En ese caso, un intervalo de punto de control ms pequeo aumenta el volumen de salida para el registro de WAL, negando parcialmente el objetivo de utilizar un intervalo ms pequeo, y en cualquier caso, causando ms disco I / O. Los puntos de control son bastante caros, primero porque requieren escribir todos los buffers actualmente sucios, y segundo, porque como resultado del trfico de WAL posterior adicional como se mencion anteriormente. Por tanto, es conveniente establecer los parmetros de los puntos de control lo suficientemente altos que los puestos de control no ocurren muy a menudo. Como una simple comprobacin de validez de los parmetros de los puntos de control, se puede establecer el checkpoint_warning parmetro. Si los puestos de control se producen ms cerca de lo
checkpoint_warning segundos, un mensaje se enviar al registro del checkpoint_segments . Aparicin ocasional de este tipo de
mensaje no es motivo de alarma, pero si a menudo aparece a continuacin, los parmetros de control de punto de control debe ser aumentada. Operaciones masivas como las grandesCOPIA transferencias pueden causar una serie de tales advertencias a aparecer si no ha configurado
Para evitar inundar el sistema de E / S con una explosin de la pgina, escribe, escribiendo buffers sucios en un puesto de control se extiende por un perodo de tiempo. Ese perodo est controlado por checkpoint_completion_target , que se da como una fraccin del intervalo de punto de control. La tasa de E / S se ajusta de modo que el punto de control termina cuando la fraccin dada de
checkpoint_segments segmentos WAL han sido consumidos desde el checkpoint_timeout segundos han
transcurrido, lo que ocurra primero. Con el valor por defecto de 0.5, PostgreSQL se puede esperar para completar cada puesto de control en la mitad de tiempo antes de que comience el siguiente punto de control. En un sistema que est muy cerca de la mxima de E / S. Durante el funcionamiento normal, es posible que desee aumentar
de control. La desventaja de esto es que la prolongacin de los puntos de control afecta el tiempo de recuperacin, porque necesitarn ms segmentos WAL que se le mantenga alrededor para su posible uso en la recuperacin. Aunque
checkpoint_completion_target se
puede configurar en 1.0, lo mejor es que sea menor que (tal vez 0,9 como mximo), ya que los
puntos de control incluyen otras actividades adems de escribir buffers sucios. Un valor de 1,0 es muy probable que resulte en los puestos de control no est terminados en tiempo, lo que resultara en la prdida de rendimiento debido a la variacin inesperada en el nmero de segmentos de WAL necesarios. Siempre habr al menos un archivo segmento WAL, y normalmente no deberan ser ms de (2 + o
normalmente 16 MB (aunque este tamao puede ser alterado cuando la construccin del servidor). Usted puede usar esto para estimar las necesidades de espacio para WAL . Normalmente, cuando ya no son necesarios los archivos segmento de registro antiguos, que son reciclados (renombrado a convertirse en los prximos segmentos de la secuencia numerada). Si, debido a un pico a corto plazo de la tasa de salida del registro, hay ms de 3 *
segmento se eliminarn en lugar de reciclarse hasta que el sistema vuelva bajo este lmite. En la recuperacin de archivos o en el modo de espera, el servidor realiza peridicamente restartpoints que son similares a los puestos de control en la operacin normal: el servidor fuerza todo su estado en el disco, se actualiza la
que los datos WAL ya procesados no tienen que ser escaneados de nuevo, y luego recicla los viejos archivos del segmento de registro en
restartpoint y al menos un registro de punto se ha repetido. Restartpoints no se pueden realizar con ms frecuencia que los puestos de control en el maestro, porque restartpoints slo se pueden realizar en los registros de los puestos de control. Hay dos internos utilizados WAL funciones:
para colocar un nuevo registro en los WAL buffers de memoria compartida. Si no hay espacio para el nuevo registro,
LogInsert tendr que escribir (mover a la cach del ncleo) algunas LogInsert se utiliza en cada base de datos de
modificacin de nivel bajo (por ejemplo, insercin de fila) en un momento en un bloqueo exclusivo se lleva a cabo en las pginas de datos afectadas, por lo que la operacin tiene que ser tan rpido como sea posible. Lo que es peor, escribir WAL tampones tambin pueden forzar la creacin de un nuevo segmento de registro, que toma an ms
LogFlush solicitud, que se realiza, en su mayor parte, en confirmacin de la transaccin LogFlush solicitudes no pueden
cuando para asegurarse de que los registros de transacciones se vacen al almacenamiento permanente. En los sistemas con alta salida de registro, producir lo suficiente para evitar
se debe aumentar el nmero de WAL tampones mediante la modificacin de los parmetros de configuracin wal_buffers . Cuando full_page_writes se establece y el sistema est muy ocupado, establecer este valor ms alto ayudar a los tiempos de respuesta suaves durante el perodo inmediatamente posterior a cada punto de control. El commit_delay parmetro define por el nmero de microsegundos del proceso del servidor va a dormir despus de escribir un registro de confirmacin en el registro con antes de realizar una
LogInsert pero
sus registros commit en el registro a fin de tener todos ellos se sonroj con un nico registro de sincronizacin. No sueo ocurrir si fsync no est habilitado, o si menos de commit_siblings otras sesiones se encuentran actualmente en las transacciones activas, lo que evita dormir cuando es poco probable que cualquier otra sesin se comprometer pronto. Tenga en cuenta que en la mayora de las plataformas, la resolucin de una solicitud de sueo es de diez milisegundos, de forma que cualquier distinto de cero
commit_delay ajuste
entre 1 y 10.000 microsegundos tendra el mismo efecto. Valores buenos para estos parmetros an no estn claros, se fomenta la experimentacin. El wal_sync_method parmetro determina PostgreSQL pedir al kernel para forzar WAL cambios en el disco. Todas las opciones deben ser las mismas en trminos de fiabilidad, con la excepcin de
incluso cuando otras opciones no lo hacen. Sin embargo, es muy especfico de la plataforma cul ser el ms rpido, usted puede probar velocidades de opciones utilizando el pg_test_fsync mdulo. Tenga en cuenta que este parmetro es irrelevante si apagado. Habilitacin del wal_debug parmetro de configuracin (siempre que PostgreSQL ha sido compilado con soporte para ello) se traducir en cada
fsync se ha
se registra en el registro del servidor. Esta opcin podra ser sustituido por un mecanismo ms general en el futuro.
WAL se activa automticamente y no requiere ninguna accin por parte del administrador, salvo asegurar que los requisitos de espacio en disco para los WAL se cumplen los registros, y que cualquier ajuste necesario se hace (vase la Seccin 29.4 ). WAL registros se almacenan en el directorio
conjunto de archivos de segmento, normalmente cada 16 MB de tamao (pero el tamao puede ser cambiado mediante la alteracin de la
de construir el servidor) . Cada segmento se divide en pginas, normalmente 8 kB cada uno (este tamao se puede cambiar a travs de la
xlog.h ; el contenido del registro depende del tipo de evento que se est registrando. Archivos
del segmento se dan los nmeros cada vez mayores como nombres, empezando por
muy, muy largo tiempo para agotar el stock disponible de los nmeros. Es ventajoso si el registro se encuentra en un disco diferente de los archivos de bases de datos principales. Esto se puede lograr moviendo el
servidor est apagado, por supuesto) y la creacin de un enlace simblico desde la ubicacin original en el directorio principal de datos a la nueva ubicacin. El objetivo de WAL es para asegurar que el registro se escribe antes de que se alteran los registros de base de datos, pero esto puede ser subvertido por las unidades de disco que falsamente informar de un xito de escritura para el ncleo, cuando en realidad slo tienen en cach los datos y todava no almacenado se en el disco. Un corte de energa en tal situacin podra dar lugar a la corrupcin de datos irrecuperable. Los administradores deben tratar de asegurar que los discos que sostiene PostgreSQL s ' WAL archivos de registro no hacen tales informes falsos. (Vea la Seccin 29.1 .) Despus de un puesto de control se ha hecho y el registro de enrojecimiento, la posicin del punto de control se guarda en el archivo recuperacin, el servidor primero lee
realiza la operacin de REDO mediante la exploracin hacia adelante desde la posicin de registro se indica en el registro de punto de control. Debido a que todo el contenido de pginas de datos se guarda en el registro de la primera modificacin de la pgina despus de un punto de control (suponiendo full_page_writes no se desactiva), todas las pginas modificadas desde el puesto de control se restaurar a un estado coherente.
segmentos de registro existentes en el orden inverso - reciente a ms antiguo - con el fin de encontrar el ltimo punto de control. Esto no se ha implementado todava.
suficientemente pequeo (menos de una pgina de disco) que no est sujeto a problemas parciales de escritura, ya partir de este escrito no ha habido reportes de fallas de la base de datos debe nicamente a la incapacidad de leer es un punto dbil,
gmake comprobar
ejecute el comando all.) Esto primero crear varios archivos auxiliares, como las funciones de disparo definido por el usuario de ejemplo y, a continuacin, ejecute el guin piloto de pruebas. Al final debera ver algo como:
o de otra manera una nota sobre la que las pruebas fracasaron. Consulte la Seccin 30.2 ms abajo antes de asumir que un "fracaso" representa un grave problema. Debido a este mtodo de ensayo se ejecuta un servidor temporal, no funciona cuando usted es el usuario root (ya que el servidor no se inicia como root). Si ya hiciste la acumulacin como root, usted no tiene que empezar de nuevo. En su lugar, hacer que el directorio de pruebas de regresin de escritura por otro usuario, inicie la sesin como ese usuario y reiniciar las pruebas. Por ejemplo:
root # chmod-R a + w src / test / retroceso root # su - joeuser joeuser $ cd directorio de construccin de alto nivel joeuser $ gmake comprobar
(La nica posible "riesgo de seguridad" es que los dems usuarios pueden ser capaces de alterar los resultados de las pruebas de regresin a sus espaldas. Utilice el sentido comn en la gestin de los permisos de usuario.) Tambin puede ejecutar las pruebas despus de la instalacin. Si ha configurado PostgreSQL para instalar en un lugar donde un viejo PostgreSQL ya existe instalacin, y realizar
encontrar que las pruebas fallan debido a que los nuevos programas tratan de utilizar las bibliotecas compartidas ya instaladas. (. Los sntomas tpicos son quejas sobre smbolos sin definir) Si desea ejecutar las pruebas antes de sobrescribir la instalacin anterior, tendr que construir con
instalacin final, sin embargo. La prueba de regresin paralela comienza bastantes procesos bajo su nombre de usuario. Actualmente, la concurrencia mxima es de veinte guiones de prueba en paralelo, lo que significa cuarenta procesos: hay un proceso de servidor y un psql proceso para cada script de prueba. As que si su sistema impone un lmite por usuario en el nmero de procesos, asegrese de que este lmite es por lo menos cincuenta ms o menos, de lo contrario podra tener fallos aleatorios aparentes en el ensayo paralelo. Si no est en condiciones de aumentar el lmite, usted puede reducir el grado de paralelismo estableciendo la
gmake installcheck
Las pruebas se esperan en contacto con el servidor en el host local y el nmero de puerto por defecto, a menos que se lo diga
La distribucin fuente tambin contiene pruebas de regresin para las lenguas de procedimiento opcionales y para algunos de los
contrib mdulos. En la actualidad, estas pruebas slo se src / pl directorio del rbol de
pueden utilizar en un servidor ya instalado. Para ejecutar las pruebas para todas las lenguas de procedimiento que se han construido e instalado, vaya al construccin y el tipo:
gmake installcheck
para una sola lengua de procedimiento. Para ejecutar las pruebas de todos los
contribmdulos que los tienen, cambie al contrib directorio del rbol de construccin y
el tipo:
gmake installcheck
Los
contrib mdulos deben haber sido construido e instalado primero. Tambin puede hacerlo contrib para ejecutar las pruebas de un solo mdulo.
en un subdirectorio
Ahora compruebe que la conexin por omisin para el probador es el servidor Standby bajo prueba y ejecute el
src
initdb . Puede ser til para probar diferentes configuraciones regionales mediante el
las dems variables de entorno local relacionados con hacer el trabajo. Cuando se prueba contra una instalacin existente, la configuracin regional est determinado por el grupo de base de datos existente y no se puede ajustar por separado para la ejecucin de la prueba. Tambin puede elegir la codificacin de la base de datos de forma explcita mediante la variable
Configuracin de la base de datos que codifica esta forma por lo general slo tiene sentido si la configuracin regional es C, de lo contrario la codificacin se elige de forma automtica de la configuracin regional, y la especificacin de una codificacin que no coincide con la configuracin regional dar lugar a un error. La codificacin se puede configurar para las pruebas contra un temporal o una instalacin existente.
numeric_big prueba:
El
generados en un sistema de referencia, por lo que los resultados son sensibles a pequeas diferencias del sistema. Cuando se reporta una prueba como "fallido" , siempre examinar las diferencias entre los resultados esperados y los reales, usted podra encontrar que las diferencias no son significativas. Sin embargo, todava nos esforzamos por mantener los archivos de referencia precisos en todas las plataformas compatibles, por lo que se puede esperar que todas las pruebas pasan. Los resultados reales de las pruebas de regresin se encuentran en los archivos de la
src /
diffpara comparar cada archivo de salida contra la referencia salidas almacenada en src / test / retroceso / regression.diffs . (O puede
src / test / retroceso / esperado directorio. Las diferencias se guardan para su diff ti mismo, si lo prefiere.)
inspeccin en ejecutar
Si por alguna razn una plataforma en particular genera un "fracaso" para una prueba determinada, pero la inspeccin de la salida que se convence de que el resultado sea vlido, se puede agregar un nuevo archivo de comparacin para silenciar el informe de fallo en futuras ejecuciones de prueba. Consulte la Seccin 30.3 para ms detalles.
hacer quela
la configuracin regional utilizando esa variable.) Para utilizar ninguna localizacin, ya sea desarmado todas las variables de entorno local relacionados con (o ponerlos a siguiente invocacin especial:
Al ejecutar las pruebas en contra de una instalacin existente, la configuracin de la configuracin regional est determinado por la instalacin existente. Para cambiarlo, inicializar el cluster de base de datos con una configuracin regional diferente al pasar las opciones apropiadas para
initdb .
En general, no obstante, es aconsejable tratar de ejecutar las pruebas de regresin en la configuracin de la configuracin regional que se queran para su uso en produccin, ya que esto ejercer la configuracin regional y de porciones de cdigo de codificacin relacionados que realmente se utilizan en la produccin. Dependiendo del entorno del sistema operativo, es posible que obtenga errores, pero entonces, al menos, saber qu comportamientos especficos de la localidad a esperar cuando se ejecutan aplicaciones reales.
PST8PDT (Berkeley,
California), y habr fracasos aparentes, si las pruebas no se ejecutan con la configuracin de zona horaria. El piloto de pruebas de regresin establece la variable de entorno
doble
precisin ) de las columnas de la tabla. Las diferencias en los resultados relacionados con las
funciones matemticas de columnas. Los
pequeas diferencias a travs de plataformas, o incluso con diferente configuracin de optimizacin del compilador. Es necesaria la comparacin globo ocular humano para determinar el verdadero significado de estas diferencias que suelen ser 10 lugares a la derecha del punto decimal. Algunos sistemas muestran menos cero Algunos errores de seal de sistemas de
-0 , mientras que otros slo muestran 0 . pow () y exp (), a diferencia del mecanismo
ORDER BY para cada SELECT , por lo que sus ordenamientos fila de resultado no
estn bien definidos de acuerdo a la especificacin SQL. En la prctica, ya que estamos ante las mismas consultas que se estn ejecutando en los mismos datos con el mismo software, por lo general obtenemos el mismo resultado al comprar en todas las plataformas, por lo que la falta de
multi-plataforma, sin embargo. Cuando se prueba en un servidor ya instalado, las diferencias pedidos tambin pueden ser causados por la configuracin no C locale o ajustes de parmetros
Por lo tanto, si usted ve una diferencia de orden, no es algo de qu preocuparse, a menos que la consulta tiene un
ORDER BY que su resultado est violando. Sin embargo, por favor, informe ORDER BY de la consulta concreta para
de todos modos, por lo que podemos agregar un eliminar la falsa "fracaso" en futuras versiones.
Usted podra preguntarse por qu no ordenamos todas las consultas de prueba de regresin explcitamente a deshacerse de este problema de una vez por todas. La razn es que eso hara que las pruebas de regresin menos tiles, no ms, desde que haban tienden a ejercer tipos de plan de consulta que producen resultados ordenados a la exclusin de aquellos que no lo hacen.
plataforma en el tamao de pila de proceso es ms pequeo que el max_stack_depth parmetro indica. Esto se puede solucionar mediante la ejecucin del servidor bajo un lmite de tamao de la pila superior (4 MB se recomienda el valor predeterminado de usted no puede hacer eso, una alternativa es reducir el valor de
max_stack_depth ). Si max_stack_depth .
azar script de prueba est diseado para producir resultados aleatorios. En casos raros, esto
debe producir slo una o unas pocas lneas de diferencias. Usted no necesita preocuparse a menos que la prueba aleatoria falla repetidamente.
prueba de regresin puede tener varios archivos de comparacin que muestra los posibles resultados en las diferentes plataformas. Hay dos mecanismos independientes para determinar qu archivo de comparacin se utiliza para cada prueba. El primer mecanismo permite que los archivos de comparacin para ser seleccionados para plataformas especficas. Hay un archivo de asignacin,
resultMap , que define qu archivo comparacin de usar para cada plataforma. Para eliminar
pruebas falsas "fracasos" para una plataforma en particular, primero elija o hacer un archivo de resultados variante y, a continuacin, agregar una lnea al
resultMap archivo.
El nombre de la prueba es el nombre del mdulo de prueba de regresin particular. El valor de salida indica que el archivo de salida para comprobarlo. Para las pruebas de regresin estndar, esto es siempre
a cabo . El valor corresponde a la extensin del archivo de salida. El modelo expr (es decir, una expresin ^ anclaje en el inicio). Se compara con el nombre de la plataforma
de plataforma es un patrn en el estilo de la herramienta de Unix regular con una implcita como impreso por
del archivo de comparacin resultado sustituto. Por ejemplo: algunos sistemas interpretan los valores de punto flotante muy pequeas como cero, en lugar de informar de un error de desbordamiento. Esto hace que algunas diferencias en la
float8 prueba de regresin. Por lo tanto, ofrecemos un archivo de comparacin float8-small-is-zero.out , que incluye los resultados que se esperan en resultMap incluye:
variante,
El segundo mecanismo de seleccin para los archivos de comparacin variante es mucho ms automtico: simplemente utiliza el "mejor partido" entre varios archivos de comparacin suministrados. El guin piloto de pruebas de regresin considera tanto la comparacin de archivos estndar para una prueba, nombradasnombre_prueba dgito
0 - 9 ). Si alguno de esos archivos es una coincidencia exacta, se considera la prueba de resultMap incluye una entrada para la prueba en particular, a continuacin, la
pasar, de lo contrario, el que genera el menor diff se utiliza para crear el informe de error. (Si base
char.out contiene los resultados que se esperan en el C y POSIX locales, mientras char_1.outcontiene resultados ordenados como aparecen en muchos otros
El mecanismo mejor partido fue ideado para hacer frente a los resultados dependientes de la localidad, pero puede ser utilizado en cualquier situacin en la que los resultados de las pruebas no se pueden predecir fcilmente desde el nombre de la plataforma solo. Una limitacin de este mecanismo es que el piloto de pruebas no se puede saber qu variante es en realidad "correcta" para el entorno actual, sino que slo recoger la variante que parece funcionar mejor. Por tanto, es ms seguro utilizar este mecanismo slo por los resultados variante que usted est dispuesto a considerar igualmente vlidas en todos los contextos.
. / Configure - enable-cobertura ... OTRAS OPCIONES ... gmake gmake cheque # u otro conjunto de pruebas
gmake cobertura-html
Para reiniciar los contadores de ejecucin entre las ejecuciones de prueba, ejecute: