Captulo 24.

Copia de seguridad y restauracin

Tabla de contenidos 24.1. SQL Dump 24.1.1. Restauracin El Escorial 24.1.2. Uso pg_dumpall 24.1.3. el manejo de grandes bases de datos 24.2. archivo de copia de seguridad a nivel de sistema 24.3. Archivar y Point-in-Time recuperacin continua (PITR) 24.3.1. Configuracin de WAL Archiving 24.3.2. Hacer una copia de seguridad de Base 24.3.3. Recuperacin del Uso de un archivo de copia de seguridad continua 24.3.4. Plazos 24.3.5. Consejos y ejemplos 24.3.6. Advertencias Al igual que con todo lo que contiene valiosos datos, PostgreSQL bases de datos deben ser respaldados peridicamente. Si bien el procedimiento es esencialmente simple, es importante tener una comprensin clara de las tcnicas y los supuestos subyacentes. Hay tres enfoques fundamentalmente diferentes a la copia de seguridad de PostgreSQL datos:

SQL dump Copia de seguridad a nivel de sistema de archivos Continua archivo

Cada uno tiene sus propias fortalezas y debilidades, cada uno se analiza a su vez en las siguientes secciones.

24.1. SQL Dump

La idea detrs de este mtodo de descarga es generar un archivo de texto con los comandos SQL que, cuando se alimenta de nuevo al servidor, volver a crear la base de datos en el mismo estado en que se encontraba en el momento de la descarga. PostgreSQL proporciona el programa de utilidad pg_dump para este propsito. El uso bsico de este comando es la siguiente:

pg_dump dbname > archivosalida

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

-h anfitrin y -p puerto . El host predeterminado es el host local o

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

U- opcin o establecer la variable de

PGUSER . Recuerde que pg_dump conexiones estn sujetas a los mecanismos de

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

24.1.1. Restauracin de El Escorial

Los archivos de texto creados por pg_dump estn destinados a ser ledo en el psql programa. El formato de comando general de restaurar un volcado es

psql dbname < infile

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

ON_ERROR_STOP conjunto de variables para

modificar ese comportamiento y tienen psql salida con un cdigo de salida de 3 si se produce un error SQL:

psql - set ON_ERROR_STOP dbname = on <infile

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

-1 o - un transaccin opciones de lnea de comandos

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 | psql-h host2

dbname

Importante: Los depsitos producidos por pg_dump son relativas a significa que los lenguajes, procedimientos, etc aaden travs

template0 . Esto

template1 tambin ser

abandonado por pg_dump . Como resultado, cuando la restauracin, si usted est utilizando una medida

template1 , debe crear la base de datos vaca de template0 , como en el ejemplo

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 .

24.1.2. Usando pg_dumpall

pg_dump vuelca una sola base de datos a la vez, y no enva informacin acerca de las funciones o espacios de tabla (porque son en todo el clster en lugar de por base de datos). Para apoyar el dumping conveniente de todo el contenido de un clster de base de datos, la pg_dumpall se proporciona programa. pg_dumpall copia de seguridad de cada base de datos en un grupo determinado, y tambin conserva los datos de todo el cluster tales como papel y definiciones de espacio de tablas. El uso bsico de este comando es la siguiente:

pg_dumpall> archivosalida

El volcado resultante puede ser restaurado con psql :

psql-f infile postgres

(En realidad, se puede especificar un nombre de base de datos existente a partir, pero si va a cargar en un clster vaco, entonces

postgres generalmente deben ser utilizados.) Siempre es

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.

24.1.3. El manejo de grandes bases de datos

Algunos sistemas operativos tienen lmites de tamao mximo de archivo que causan problemas al crear grandes pg_dump archivos de salida. Afortunadamente, pg_dump puede escribir en la salida estndar, por lo que puede utilizar las herramientas estndar de Unix para evitar este posible problema. Hay varios mtodos posibles: Use vertederos comprimido. Usted puede utilizar su programa de compresin favorito, por ejemplo gzip :

pg_dump dbname | gzip> nombre del archivo . gz

Actualizar con:

gunzip-c archivo gz |. psql dbname

o:

cat archivo gz |. gunzip | psql dbname

Utilice

divisin . La divisin de comandos le permite dividir la salida en archivos ms

pequeos que son aceptables en el tamao del sistema de archivos subyacente. Por ejemplo, para hacer trozos de 1 megabyte:

pg_dump dbname | dividida b 1m - nombre del archivo

Actualizar con:

cat nombre * | psql dbname

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

gzip , pero tiene la ventaja aadida de que las tablas se pueden

restaurar selectivamente. El comando siguiente vuelca una base de datos utilizando el formato de volcado de encargo:

pg_dump-Fc dbname > nombre

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.

divisin con uno de

24.2. Copia de seguridad a nivel de sistema de archivos

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:

tar-cf backup.tar / usr / local / pgsql / data

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

alquitrn y herramientas similares no

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.

PUNTO DE CONTROL antes de tomar la instantnea para reducir

24.3. Archivado y Point-in-Time recuperacin continua (PITR)

En todo momento, PostgreSQL mantiene una escritura delante iniciar (WAL) en el

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.

24.3.1. Configuracin de archivado WAL

En un sentido abstracto, a correr PostgreSQL sistema produce un indefinidamente larga secuencia de registros WAL. El sistema divide fsicamente esta secuencia en WAL archivos de segmentos , que son normalmente de 16 MB cada uno (aunque el tamao de segmento puede ser alterado en la construccin de PostgreSQL ). Los archivos del segmento reciben nombres numricos que reflejan su posicin en la secuencia WAL abstracto. Cuando no utilice WAL archiving, el sistema crea normalmente slo unos pocos archivos del segmento y luego "recicla"ellos por el cambio de nombre que ya no se necesitan archivos segmentos a los nmeros de segmentos superiores. Se supone que los archivos del segmento cuyos contenidos preceder al puesto de control-penltima ya no son de inters y pueden ser reciclados. Al archivar datos WAL, tenemos que capturar el contenido de cada archivo segmento una vez que se llena, y guardar los datos en algn lugar antes de que el archivo de segmentos es

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

usar en elarchive_command parmetro de configuracin. En la prctica siempre se colocan estos ajustes en el

nombre de la ruta del archivo a archivo, y

nombre de la ruta es relativa al directorio de trabajo actual, es decir, el directorio de datos de la agrupacin.) Utilice

%%si necesita integrar un verdadero % personaje en el comando. El comando

ms simple til es algo as como:

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

que copiar segmentos WAL archivarse en el directorio

/ mnt / server /

archivedir . (. Este es un ejemplo, no una recomendacin, y podra no funcionar en todas

las plataformas) Despus de que el

% p y % f parmetros se han sustituido, el comando real

ejecutado podra tener este aspecto:

prueba! -F / mnt/server/archivedir/00000001000000A900000065 && cp pg_xlog/00000001000000A900000065 / mnt/server/archivedir/00000001000000A900000065

Un comando similar se generar para cada nuevo archivo del expediente.

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

-i se utiliza y el archivo de destino ya existe, que es no el

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

resuelva la situacin. (Si el sistema de archivos que contiene

/ 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

pg_xlog / directorio contendr un gran nmero de archivos del segmento que

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,

postgresql.conf , pg_hba.conf y pg_ident.conf ), ya que stas estn

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.

archive_timeout ajustes de un minuto ms o menos suelen ser razonable. pg_switch_xlog si usted

Adems, puede forzar un cambio de segmento manualmente con

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.

recarga. Si desea detener temporalmente el archivo, una forma de hacerlo es establecer

acumulen en

24.3.2. Hacer una copia de seguridad de Base

El procedimiento para hacer una copia de seguridad de base es relativamente simple: 1. Asegrese de que el archivado WAL est habilitada y en funcionamiento. 2. Conctese a la base de datos como superusuario y ejecute el comando:

3. SELECT pg_start_backup ("etiqueta");

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.)

una etiqueta de copia de seguridad de archivos, llamado

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,

pg_start_backup puede tardar mucho tiempo para

finalizar. Esto se debe a que se realiza un punto de control y E / S requerida para el

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:

SELECT pg_start_backup ('label', true);

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:

6. SELECT pg_stop_backup ();

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

pg_stop_backup resultado 's es el

ltimo segmento que se requiere para formar un conjunto completo de archivos de copia de seguridad. Si

archive_mode est activada, pg_stop_backup no vuelve hasta archive_command . En la mayora

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

de tiempo para la ejecucin de adecuada

pg_stop_backup , establecer una

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

() , copia y pg_stop_backup () los pasos automticamente, y pg_basebackup no

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

pg_start_backup y el inicio de la copia de seguridad actual, ni entre el final de la full_page_writes discapacidad, es

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

pg_start_backup y pg_stop_backup , ya full_page_writes se ve obligado

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,

/ usr / local / pgsql / data ). Si est

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

riesgo de errores al restaurar. Esto es fcil de arreglar si

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

postmaster.pid y postmaster.opts , que registran informacin sobre el

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

pg_stop_backup funcin crea un archivo de historial de copia de

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

pg_start_backup , as como las horas de inicio y

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_start_backup funcin hace que un archivo

backup_label en el directorio del clster de base de datos, que se elimina

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

pg_start_backup se ha ejecutado, y el nombre del archivo WAL partida. En caso de

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

pg_start_backup o pg_stop_backup , por lo que se le dej a sus propios

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.

24.3.3. Recuperacin El uso de un archivo de copia de seguridad continua

Bueno, lo peor ha pasado y lo que necesita para recuperarse de su copia de seguridad. ste es el procedimiento: 1. Detenga el servidor, si se est ejecutando. 2. Si usted tiene el espacio para ello, copie todo el directorio de datos del clster y los espacios de tablas en una ubicacin temporal en caso de que los necesite ms tarde. Tenga en cuenta que esta precaucin, se requerir que usted tiene suficiente espacio libre en el sistema para realizar dos copias de su base de datos existente. Si usted no tiene suficiente espacio, al menos debe guardar el contenido de la

agrupacin

pg_xlog subdirectorio, ya que podra contener registros que no fueron

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

la raz !) y con los permisos adecuados. Si est

utilizando los espacios de tabla, debe verificar que los enlaces simblicos en

pg_tblspc / se restauraron correctamente. pg_xlog / , los cuales procedan de la copia

5. Elimine todos los archivos presentes en

de seguridad del sistema de archivos y por lo tanto probablemente obsoleto y no actual. Si no lo hizo archivo

pg_xlog / en absoluto, vuelva a crearla con los permisos

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

pg_xlog / . (Lo mejor es copiarlos, no moverlos, por lo que an tienen los

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

recovery.conf arecovery.done (para evitar el modo de recuperacin

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.conf.sample (normalmente ubicado en la instalacin share

/ directorio) como prototipo. La nica cosa que es absolutamente necesario especificar

en

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

comando. El comando ms simple til es algo as como:

restore_command = 'cp / mnt / server / archivedir /% f% p'

que copiar previamente archivada segmentos WAL desde el directorio

/ 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

que el nombre de base de la intercambiables.

Segmentos WAL que no se pueden encontrar en el archivo, se buscarn en

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

pg_xlog / al recuperar los archivos

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

la recuperacin de un archivo llamado algo as como

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

pg_stop_backup . No se puede utilizar una copia

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

ser escaneados de nuevo.

24.3.4. Lneas de tiempo

La capacidad de restaurar la base de datos a un punto anterior en el tiempo crea algunas complejidades que son similares a las historias de ciencia ficcin sobre viajes en el tiempo y universos paralelos. Por ejemplo, en la historia original de la base de datos, supongamos que se le cay una tabla crtico a las 5:15 pm el martes por la noche, pero no se dio cuenta de su error hasta el mircoles al medioda. Sin inmutarse, que salga la copia de seguridad, restaurar al punto en el tiempo 17:14 martes por la noche, y estn en marcha. En la historia del universo de bases de datos, nunca se cay de la mesa. Pero supongamos que posteriormente se da cuenta que esto no era una buena idea, y me gustara volver algn da a la maana del mircoles en la historia inicial. Usted no ser capaz de si, mientras que su base de datos fue hacia arriba y funcionando, sobrescrito algunos de los archivos del segmento WAL que condujeron a la vez que ahora desea que usted podra regresar. Por lo tanto, para evitar esto, es necesario distinguir la serie de registros WAL generada despus de haber hecho una recuperacin de punto en el tiempo de los que se generaron en la historia base de datos original. Para hacer frente a este problema, PostgreSQL tiene un concepto de lneas de tiempo . Cada vez que completa una recuperacin de archivos, se crea una nueva lnea de tiempo para identificar la serie de registros WAL generada tras esa recuperacin. El nmero de identificacin de la lnea de tiempo es parte de los nombres de archivo de segmentos WAL por lo que una nueva lnea de tiempo no sobrescribe los datos WAL generados por los plazos anteriores. De hecho, es posible archivar muchas lneas de tiempo diferentes. Mientras que puede parecer una caracterstica intil, a menudo es un salvavidas. Tenga en cuenta la situacin en la que no estn muy seguros de lo que un punto en el tiempo para recuperar a, por lo que tienen que hacer varias recuperaciones de punto en el tiempo de prueba y error hasta encontrar el mejor lugar para ramifican desde la historia antigua. Sin plazos de este proceso no tardara en generar un caos ingobernable. Con lneas de tiempo, puede recuperar a cualquier estado anterior, incluyendo los estados de ramas de lnea de tiempo que abandonaste antes. Cada vez que se crea una nueva lnea de tiempo, PostgreSQL crea una "historia de la lnea de tiempo" archivo que muestra la lnea de tiempo que se bifurca desde y cundo. Estos archivos de la historia son necesarios para permitir que el sistema para recoger los archivos segmento WAL correctas cuando se recupera de un archivo que contiene varias lneas de tiempo. Por lo tanto, se archivan en el rea de WAL archivo como archivos segmentos WAL. Los archivos de la historia son slo un pequeo archivo de texto, por lo que es barato y apropiado para mantener los widgets por tiempo indefinido (a diferencia de los archivos de los segmentos que son

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

recovery.conf . No se puede recuperar en plazos que bifurcan antes

de la copia de seguridad base.

24.3.5. Consejos y ejemplos

Algunos consejos para configurar continua archivado se dan aqu.

24.3.5.1. Las copias de seguridad independientes calientes

Es posible utilizar PostgreSQL mecanismos de seguridad 's para producir copias de seguridad calientes independientes. Se trata de copias de seguridad que no se pueden utilizar para la recuperacin de punto en el tiempo, sin embargo, suelen ser mucho ms rpido de copia de seguridad y restauracin de pg_dump vuelca. (Tambin son mucho ms grandes quepg_dump vuelca, por lo que en algunos casos, la ventaja de la velocidad puede ser negada.) Para prepararse para las copias de seguridad calientes autnomas, establezca

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

cambio existe. Por ejemplo:

prueba archive_command = '! -F / var / lib / pgsql / backup_in_progress | | (prueba!-F / var / lib / pgsql / archive /% && cp f% p / var / lib / pgsql / archive /% f) '

Este mandato llevar a cabo cuando el archivo

/ var / lib / pgsql /

backup_in_progress existe, y de lo contrario volver en silencio el cdigo de salida cero (lo

que permitePostgreSQL para reciclar el archivo WAL no deseado).

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

/ var / lib / pgsql / backup_in_progress se crearon

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.

24.3.5.2. Archivo comprimido Registros

Si el tamao de almacenamiento de archivos es un problema, use pg_compresslog , http://pglesslog.projects.postgresql.org , para eliminar innecesarias full_page_writes y espacio al final de los archivos WAL. A continuacin, puede utilizar gzip para comprimir an ms la salida de pg_compresslog :

archive_command = 'pg_compresslog% p - | gzip> / var / lib / pgsql / archive /% f'

A continuacin, deber utilizar gunzip y pg_decompresslog durante la recuperacin:

restore_command = 'gunzip </ mnt / server / archivedir /% f | pg_decompresslog -% p'

24.3.5.3.

archive_command Scripts

Muchas personas optan por utilizar secuencias de comandos para definir su

archive_command , por lo que su postgresql.conf entrada parece muy simple:

archive_command = 'local_backup_script.sh "% p" "% f"'

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

Consejo: Cuando se utiliza un

archive_command guin, es deseable

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

DATABASE copiado se modifica mientras la copia de seguridad de base an est en

curso, es posible que la recuperacin har que las modificaciones que se propagan en el creado base de datos tambin. Esto es por supuesto indeseable. Para evitar este riesgo, es mejor no modificar las bases de datos de la plantilla mientras se hace una copia de seguridad de base.

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

full_page_writes est encendido. Mientras tanto, los administradores pueden

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.

Captulo 25. Alta disponibilidad, balanceo de carga y replicacin

Tabla de contenidos 25.1. comparacin de diferentes soluciones 25.2. Servidores espera trasvase de registros 25.2.1. Planificacin 25.2.2. Operacin servidor Standby 25.2.3. Preparacin del maestro para los servidores en espera 25.2.4. Configuracin de un servidor en espera 25.2.5. Replicacin Streaming 25.2.6. replicacin sincrnica 25.3. Failover 25.4. Mtodo alternativo para el trasvase de registros 25.4.1. Ejecucin 25.4.2. trasvase de registros basados en registros 25.5. Hot Standby 25.5.1. Descripcin general del usuario 25.5.2. Manejo de Conflictos de consulta 25.5.3. Descripcin general del administrador 25.5.4. Hot Standby Parmetro Referencia 25.5.5. Advertencias Servidores de bases de datos pueden trabajar juntos para permitir un segundo servidor para hacerse cargo rpidamente si el servidor principal falla (alta disponibilidad), o para permitir que varios ordenadores para servir a los mismos datos (balanceo de carga). Lo ideal sera que los servidores de bases de datos pueden trabajar juntos sin problemas. Servidores web que sirven pginas web estticas se pueden combinar fcilmente con slo el equilibrio de carga peticiones web a varios equipos. De hecho, los servidores de bases de datos de slo lectura se pueden combinar con relativa facilidad tambin. Desafortunadamente, la mayora de los servidores de bases de datos tienen una lectura / escritura de la mezcla de las solicitudes, y lectura / escritura de los servidores son mucho ms difciles de combinar. Esto se debe a que, aunque datos de slo lectura tiene que ser colocado en cada servidor de una sola vez, una escritura en cualquier servidor tiene que ser propagado a todos los servidores por lo que el futuro las solicitudes de lectura a esos servidores devuelve resultados consistentes. Este problema de la sincronizacin es la dificultad fundamental para los servidores que trabajan juntos. Porque no hay una solucin nica que elimina el impacto del problema de sincronizacin

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.

25.1. Comparacin de diferentes soluciones

Conmutacin por error de disco compartido Conmutacin por error de disco compartido evita la sobrecarga de sincronizacin por tener slo una copia de la base de datos. Se utiliza una sola matriz de disco que es

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

aleatorio () , CURRENT_TIMESTAMP , y las secuencias pueden tener

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

Mtodo de disco bloques Comunicac compartid de disco in o

WAL

filas de la tabla

SQL

filas de la tabla

filas y bloqueos de fila

No se requiere hardware especial

Permite mltiples servidores maestros

No sobrecarga del servidor maestro

No tiene que esperar varios servidores

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

Insuficienc ia Maestro nunca perder los datos

Standby aceptar consultas de slo lectura

Calien te slo

Granularid ad para cada tabla

No necesaria resolucin de conflictos

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.

25.2. Servidores en espera trasvase de registros

Continua archivo se puede utilizar para crear una alta disponibilidad (HA) de configuracin del clster con uno o ms servidores de reserva listos para hacerse cargo de las operaciones si el servidor principal falla. Esta capacidad se refiere extensamente como reserva en caliente o el trasvase de registros . El servidor principal y en espera trabajar juntos para proporcionar esta capacidad, aunque los servidores se conectan solamente libremente. El servidor principal funciona en modo de archivo continuo, mientras que cada servidor de reserva funciona en modo de recuperacin continua, la lectura de los archivos WAL desde el primario. No hay cambios en las tablas de base de datos se requieren para habilitar esta capacidad, por lo que ofrece bajos costos de administracin en comparacin con otras soluciones de replicacin. Esta configuracin tambin tiene un impacto relativamente bajo rendimiento en el servidor principal. Mover directamente los registros WAL de un servidor de base de datos a otro se suele describir como el trasvase de registros. PostgreSQL implementa el trasvase de registros basados en archivos mediante la transferencia de los registros de un archivo WAL (segmento WAL) a la vez. Archivos WAL (16 MB) se puede enviar fcilmente ya bajo costo a cualquier distancia, ya se trate de un sistema adyacente, otro sistema en el mismo sitio, u otro sistema, al otro lado del globo. El ancho de banda requerido para esta tcnica vara en funcin de la tasa de transaccin

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

archive_timeout parmetro, que se

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.

25.2.2. Funcionamiento del servidor Standby

En el modo de espera, el servidor se aplica continuamente WAL recibido desde el servidor maestro. El servidor de reserva puede leer desde un archivo WAL WAL (ver restore_command ) o directamente desde el master en una conexin TCP (streaming de replicacin). El servidor en espera tambin intentar restaurar cualquier WAL encuentra en el clster en espera

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

restore_command . Una vez que llega al final de la WAL disponibles all

yrestore_command falla, intenta restaurar cualquier WAL disponible en el

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,

pg_xlog , ya travs de streaming de replicacin contina hasta que se detiene el

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

Promotor se ejecuta o un archivo de disparo se encontr ( trigger_file ). Antes de

conmutacin por error, cualquier WAL inmediatamente disponibles en el archivo o en

pg_xlog ser restaurado, pero no se hace ningn intento de conectar con el maestro.

25.2.3. Preparacin del Maestro para los servidores en espera

Configure el archivo continuo en el primario a un directorio de archivos accesibles desde el modo de espera, como se describe en la Seccin 24.3 . La ubicacin del archivo debe ser accesible desde el modo de espera an cuando el amo est abajo, es decir, debe residir en el servidor en espera s mismo oa otro servidor de confianza, no en el servidor maestro. Si desea utilizar la replicacin streaming, configurar la autenticacin en el servidor principal para permitir conexiones de replicacin del servidor de reserva (s), es decir, crear un rol y proporcionar una entrada adecuada o entradas en datos establecida en

pg_hba.conf con el campo de base de

replicacin . Asegrese tambin de max_wal_senders se establece

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.

25.2.4. Configuracin de un servidor en espera

Para configurar el servidor de reserva, restaurar la copia de seguridad base tomado de servidor primario (vase la seccin 24.3.3 ). Crear una orden de recuperacin de archivosrecovery.conf en el directorio de datos del clster del modo de espera y encender

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.

restore_command debe regresar de inmediato si el archivo no existe, el

servidor volver a intentar el comando de nuevo si es necesario. Consulte la Seccin 25.4 para el uso de herramientas como pg_standby.

Si desea utilizar la replicacin de streaming, rellene

primary_conninfo con una cadena de

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

archive_cleanup_command en configuraciones tpicas de una sola reserva,

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

max_wal_senders lo suficientemente alto en la

primaria para que puedan estar conectados al mismo tiempo.

25.2.5. Streaming de replicacin

Transmisin de replicacin permite un servidor de reserva para permanecer ms al da de lo que es posible con el trasvase de registros basados en archivos. El modo de espera se conecta a la

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,

archive_timeout no se requiere para reducir la ventana de la prdida de datos.

Si utiliza la replicacin de streaming sin basados en archivos continuos archivo, usted tiene que fijar

wal_keep_segments en el maestro a un valor lo suficientemente alto como para

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,

wal_keep_segments no se requiere que la 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

primary_conninfo ajuste en el recovery.conf archivo para que apunte al

servidor primario. Establecer listen_addresses y opciones de autenticacin (vase la

pg_hba.conf ) en el primario para que el servidor de reserva puede conectarse a

replicacin depseudo-bases de datos en el servidor primario (vase la Seccin

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

primary_conninfo est configurado correctamente, la

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

REPLICACION privilegio. Por lo tanto un papel con

INGRESAR privilegios se debe crear en el primario.

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

predeterminada, no se recomienda el uso de cuentas de superusuario para la rplica.Mientras

modificar los datos en el sistema primario, que el

La autenticacin del cliente para la replicacin est controlada por un especificando

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

se est ejecutando en host IP es

foo , el administrador puede aadir la siguiente lnea al pg_hba.conf archivo en el

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

recovery.conf archivo. La contrasea tambin se puede

~ /. pgpass archivo en el modo de espera (especificar la

replicacin en el base de datos de campo). Por ejemplo, si el principal se est

ejecutando en host IP192.168.1.50 , puerto es la

5432 , el nombre de cuenta para la replicacin

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

pg_last_xlog_receive_location en el modo de espera, respectivamente (vase 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

ps comando (vase la Seccin 27.1 para ms detalles).

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.

25.2.6. Replicacin sincrnica

PostgreSQL replicacin de transmisin es asincrnico de forma predeterminada. Si el servidor principal se bloquea a continuacin algunas transacciones que se cometieron no se hayan replicado en el servidor de reserva, causando la prdida de datos. La cantidad de prdida de datos es proporcional al retraso de la replicacin en el momento de conmutacin por error.

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.

25.2.6.1. Configuracin bsica

Una vez que la replicacin de streaming se ha configurado, la configuracin de la replicacin sncrona requiere slo un paso de configuracin adicional: synchronous_standby_namesdeben establecerse en un valor que no est vaca. establecerse en

synchronous_commit tambin debe

el , pero ya que este es el valor predeterminado, se requiere por lo general no

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.

synchronous_commit se puede establecer por los usuarios individuales, por

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

datos se escriben en el disco, a menos

wal_receiver_status_interval se pone a cero

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.

25.2.6.2. La planificacin de Rendimiento

Replicacin sincrnica por lo general requiere servidores de reserva cuidadosamente planificadas y colocado a asegurar que las aplicaciones funcionan aceptablemente. Esperando no utiliza los recursos del sistema, pero bloqueos de transacciones continan presos hasta que se confirme la transferencia. Como resultado, el uso imprudente de la replicacin sncrona reducir el rendimiento para aplicaciones de base de datos debido al aumento de los tiempos de respuesta y una mayor contencin. PostgreSQL permite que el desarrollador de la aplicacin para especificar el nivel de durabilidad requerida a travs de la replicacin. Esto puede ser especificado para el sistema en general, aunque tambin se puede especificar para los usuarios o conexiones especficas, o incluso las transacciones individuales. Por ejemplo, una carga de trabajo de aplicacin puede constar de: 10% de los cambios son importantes los datos del cliente, mientras que el 90% de los cambios de datos son menos importantes que el negocio pueda sobrevivir ms fcilmente si se pierde, como los mensajes de chat entre usuarios. Con las opciones de replicacin sincrnica especificados a nivel de aplicacin (en la primaria) podemos ofrecer replicacin sincrnica de los cambios ms importantes, sin ralentizar el grueso de la carga de trabajo total. Opciones de nivel de aplicacin son una herramienta importante y prctico para permitir que los beneficios de la replicacin sincrnica para aplicaciones de alto rendimiento.

Debe tener en cuenta que el ancho de banda de la red debe ser superior a la tasa de generacin de datos de WAL.

25.2.6.3. Planificacin de alta disponibilidad

Comete hecho cuando

synchronous_commit se establece en el esperar hasta que el modo

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

synchronous_standby_names . La primera llamada en

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

catchup modo. Una vez que el desfase entre la espera y transmisin

primaria llega a cero por primera vez nos trasladamos a tiempo real de

de estado. La duracin de puesta al da puede ser largo e inmediatamente despus de crear la

reserva. Si el modo de espera est apagado, entonces el perodo de puesta al da se incrementar de acuerdo a la longitud de tiempo que la espera ha sido hacia abajo. La reserva slo es capaz de convertirse en un modo de espera sncrono una vez que ha alcanzado

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

synchronous_standby_names y volver a cargar el archivo de configuracin en

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

synchronous_commit = off , de lo contrario esas peticiones

van a esperar para siempre por la espera de que aparezca .

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

ruta especificada por el planeando utilizar

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.

25.4. Mtodo alternativo para el trasvase de registros

Una alternativa a la incorporada en el modo de espera descrito en la seccin anterior es utilizar un

restore_command que sondea la ubicacin del archivo. Esta fue la nica opcin disponible Standby_mode off, porque va

en las versiones 8.4 y por debajo. En esta configuracin, ajuste

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.

archive_timeout puede ser

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

WAL siguiente, espera a que estn disponibles desde el primario. El especifica en el

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

backup o . historia no hay necesidad de esperar, y un cdigo de retorno distinto de cero

debe ser devuelto.A la espera

restore_command se puede escribir como un script

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

restore_command , romper el bucle y devolver un error de archivo no

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;

} if (! activada) CopyWALFileForRecovery ();

Un ejemplo de trabajo de una espera

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

restore_command comandos. Se ejecuta una restore_command se crea y restore_command no es

vez para cada archivo WAL, pero el proceso que ejecuta el

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

archive_timeout ajuste en el primario. Sin embargo, esto es poco propenso a

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

recovery.conf que especifica un restore_command que espera, como se

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.

25.4.2. Record basado trasvase de registros

Tambin es posible llevar a cabo el trasvase de registros de registro basado en el uso de este mtodo alternativo, aunque esto requiere el desarrollo personalizado, y los cambios se siguen slo se hacen visibles a las preguntas de reserva en caliente despus de que se haya enviado el archivo completo WAL. Un programa externo puede llamar al

pg_xlogfile_name_offset () funcin (vase la

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

restore_command script con el programa de copia de datos.

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.

25.5. Hot Standby

Hot Standby es el trmino utilizado para describir la capacidad de conectar con el servidor y ejecutar consultas de slo lectura, mientras que el servidor se encuentra en recuperacin de archivos o en el modo standby. Esto es til tanto para fines de replicacin y para la restauracin de una copia de seguridad a un estado deseado con gran precisin. El trmino Hot Standby tambin se refiere a la capacidad del servidor para pasar de la recuperacin a travs de la operacin normal, mientras que los usuarios siguen ejecutando consultas y / o mantener las conexiones abiertas. Ejecucin de consultas en el modo de espera activa es similar a la operacin normal de consulta, aunque hay varios usos y diferencias administrativas se explica a continuacin.

25.5.1. Descripcin general del usuario

Cuando el hot_standby parmetro se establece en true en un servidor de reserva, que comenzar a aceptar conexiones una vez que la recuperacin se ha llevado el sistema a un estado coherente. Todas estas conexiones son estrictamente de slo lectura, ni siquiera las tablas temporales se pueden escribir. Los datos sobre la reserva lleva algn tiempo en llegar desde el servidor primario por lo que habr un retraso medible entre primario y standby. Ejecucin de la misma consulta casi simultneamente en primaria y en espera por lo tanto podra volver resultados diferentes. Decimos que los datos sobre el modo de espera es el tiempo en consonancia con el primario. Una vez que el registro de confirmacin de una transaccin se vuelve a jugar en el modo de espera, los cambios realizados por la transaccin sern visibles para las nuevas instantneas tomadas en el modo de espera. Las instantneas se pueden tomar en el inicio de cada consulta o en el inicio de cada transaccin, dependiendo del nivel de aislamiento de transaccin actual. Para ms detalles, consulte la Seccin 13.2 . Las operaciones iniciadas durante la espera en caliente pueden emitir los siguientes comandos:

Acceso de consulta -

SELECT , copia a

Comandos de cursor Parmetros -

DECLARA , FETCH , CLOSE

VER , SET , REAJUSTE

Comandos de gestin de transacciones

o o o

EMPEZAR , END , ABORTO , iniciar la transaccin SAVEPOINT , RELEASE , ROLLBACK TO SAVEPOINT EXCEPCIN bloques y otros subtransacciones internos

Bloqueo de tabla , aunque slo cuando explcitamente en uno de estos

modos:

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:

Lenguaje de manipulacin de datos (DML) -

INSERTAR , ACTUALIZAR , BORRAR , Copiar desde , TRUNCATE . Tenga en

cuenta que no hay acciones permitidas que se traducen en un disparador de ser ejecutado durante la recuperacin. Esta restriccin se aplica incluso a las tablas temporales, ya que las filas de la tabla no pueden ser ledos o escritos sin asignar una ID de transaccin, que en la actualidad no es posible en un entorno de Hot Standby.

Data Definition Language (DDL) -

CREATE , DROP , ALTER , COMMENT . Esta

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.

SELECT ... PARA COMPARTIR | ACTUALIZACIN , porque los bloqueos de fila

no se pueden tomar sin actualizar los archivos de datos subyacentes.

Normas sobre

SELECT declaraciones que generan comandos DML.

LOCK que pida explcitamente un modo superior FILA MODO EXCLUSIVO . LOCK en forma predeterminada corto, ya que solicita acceder al modo EXCLUSIVO .

Comandos de administracin de transacciones que establezca explcitamente no estado de slo lectura:

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

SET transaction_read_only = off PREPARAR TRANSACCIN , COMMIT

Comandos de confirmacin en dos fases -

PREPARADO , ROLLBACK PREPARADO porque incluso transacciones de slo lectura

tienen que escribir WAL en la fase de preparacin (la primera fase de dos fases).

Cambios de secuencia -

nextval () , setval ()

ESCUCHAR , UNLISTEN , NOTIFICAR

En funcionamiento normal, "slo lectura" transacciones pueden actualizar secuencias y utilizar

ESCUCHAR , UNLISTEN y NOTIFICAR , sesiones de espera tan caliente operan bajo

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

transaction_read_only siempre es cierto y no se

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

MOSTRAR transaction_read_only . Adems, un conjunto de funciones ( Tabla

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.

25.5.2. Manejo de Conflictos de consulta

Los servidores primarios y de reserva son en muchos aspectos vagamente conectados. Acciones en la primaria tendrn un efecto en el modo de espera. Como resultado, existe la posibilidad de interacciones o conflictos entre ellos negativos. El conflicto ms fcil de entender es el rendimiento: si la carga de datos enorme est llevando a cabo en la primaria entonces esto va a generar un flujo similar de registros WAL en las consultas de modo en espera, espera pueden competir por los recursos del sistema, tales como I / O. Tambin hay otros tipos de conflictos que pueden ocurrir con Hot Standby. Estos conflictos son conflictos duros en el sentido de que tenga que ser cancelado y, en algunos casos, las sesiones desconectadas para resolverlos consultas. El usuario dispone de varias formas de manejar estos conflictos. Casos de conflicto son:

Acceso bloqueos exclusivos tomadas en el servidor principal, incluyendo tanto explcitas

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

DROP TABLE se ejecuta en el primario, el

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.

DROP TABLE se puede

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

max_standby_archive_delay o max_standby_streaming_delay se ha DROP DATABASE se dar 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

espera. Ejecucin de un manual de

congelacin al vaco puede causar conflictos, incluso

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

max_standby_archive_delay o max_standby_streaming_delay puede

considerarse similar a la configuracinstatement_timeout .

Remediacin posibilidades existen si no se encuentra el nmero de cancelaciones de esperaconsulta es inaceptable. La primera opcin es establecer el parmetro

hot_standby_feedback , que impide VACO de la eliminacin de filas recin

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.

max_standby_archive_delay debe mantener grandes en este caso, porque

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

max_standby_streaming_delay . Sin embargo, es difcil

garantizar cualquier ventana especfica de ejecucin en tiempo con este enfoque, ya que

vacuum_defer_cleanup_age se mide en las operaciones realizadas en el servidor

principal. El nmero de consultas se cancela y la razn de que se pueden ver con el

pg_stat_database_conflicts vista del sistema en el servidor de pg_stat_database vista del sistema tambin contiene informacin de resumen.

reserva. El

25.5.3. Descripcin general del administrador

Si

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: entrar en el modo de espera

... a continuacin, un poco ms tarde ...

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

hot_standby en el primario. Alcanzar un estado coherente tambin se puede

retrasar en la presencia de estas dos condiciones:

Una transaccin de escritura tiene ms de 64 subtransacciones Transacciones de escritura muy longevo

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

archive_timeout ajuste en la primaria.

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:

max_connections max_prepared_transactions max_locks_per_transaction

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:

Data Definition Language (DDL) - por ejemplo, Privilegios y propiedad -

CREATE INDEX

GRANT , REVOKE , reasignar ANALIZAR , VACO , CLUSTER , REINDEX

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_cancel_backend () funcionar en backends de usuario, pero no el proceso de inicio,

que lleva a cabo la recuperacin.

pg_stat_activity no muestra una entrada para el

proceso de arranque, ni las transacciones se recuperan mostrar activa. Como resultado,

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.

pg_locks mostrarn bloqueos que tienen los backends, como de

costumbre.

pg_locks tambin muestra una transaccin virtual gestionado por el proceso de

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

AccessExclusiveLocks no se muestran en pg_locks para el proceso de

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

pg_start_backup , pg_switch_xlog etc pg_stat_statements .

Mdulos de carga dinmica de trabajo, incluyendo

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

DROP DATABASE o ALTER DATABASE ... SET TABLESPACE en la primaria

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

ALTER DATABASE ... RENAME no desconectar a los usuarios, que en muchos

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

DROP USER o DROP ROLE para un papel con

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.

DROP USER en la primaria

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

PUNTO DE CONTROL se acepta comandos durante la recuperacin, a pesar de que

realiza una restartpoint en lugar de un nuevo puesto de control.

25.5.4. Hot Standby Parmetro Referencia

Varios parmetros se han mencionado anteriormente en la Seccin 25.5.2 y la Seccin 25.5.3 . En la primaria, los parmetros wal_level y vacuum_defer_cleanup_age pueden ser utilizados. max_standby_archive_delay y max_standby_streaming_delay no tienen efecto si se establece en el primario. En el modo de espera, los parmetros hot_standby , max_standby_archive_delay y max_standby_streaming_delay pueden ser utilizados. vacuum_defer_cleanup_age no tiene ningn efecto mientras el servidor permanece en modo de espera, a pesar de que ser relevante si la espera se convierte en primordial.

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,

AccessExclusiveLocks poder de transacciones

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

AccessExclusiveLocks o planea tener un

gran transaccin que tiene muchosAccessExclusiveLocks , se recomienda seleccionar un valor mayor de

max_locks_per_transaction , quizs tanto como max_prepared_transactions es 0.

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.

Captulo 26. Configuracin de recuperacin

Tabla de contenidos 26.1. Configuracin de recuperacin de archivos 26.2. Configuracin del destino de Recuperacin

26.3. Configuracin del servidor en espera En este captulo se describe la configuracin disponible en el

recovery.conf archivo. Se aplican slo para la duracin de la recuperacin. Deben

poner a cero para cualquier recuperacin posterior que desea realizar. No se puede cambiar una vez que la recuperacin ha comenzado.

Ajustes en

recovery.conf se especifican en el formato nombre = 'valor' . Un # ) designan el resto de la lnea

parmetro es especificado por lnea. Marcas de hash (

como un comentario.Para insertar una comilla simple en un valor de parmetro, escriba dos comillas (

'' ). share / recovery.conf.sample , se proporciona en la

Un archivo de ejemplo, instalacin

share / directorio.

26.1. Configuracin de recuperacin de archivos

restore_command ( string )
El comando shell para ejecutar para recuperar un segmento archivada de la serie de archivos WAL. Este parmetro es necesario para la recuperacin de archivos, pero es opcional para el streaming de replicacin. Cualquier

f% en la cadena se sustituye por el % p se sustituye por el

nombre del archivo que se recuperan del archivo, y cualquier

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

% r se sustituye por el nombre del archivo que contiene el ltimo punto de

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.

r es tpicamente utilizado por calentamiento en espera configuraciones (vase la Seccin

25.2 ). Escribe

%% para insertar un real % personaje.

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

por el servidor en espera. Cualquier

% r se sustituye por el nombre del archivo que

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

% r se puede eliminar de forma segura. Esta informacin puede ser utilizada

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

archive_cleanup_command para configuraciones de un solo modo de espera,

por ejemplo:

archive_cleanup_command = 'pg_archivecleanup / mnt / server / archivedir% r'

Tenga en cuenta sin embargo, que si hay varios servidores en espera estn restaurando desde el mismo directorio de archivo, usted tendr que asegurarse de que no elimina los archivos WAL hasta que ya no son necesarios para cualquiera de los servidores.

archive_cleanup_command normalmente se usara en una %% para % personaje en el comando.

configuracin de calentamiento en espera (vase la Seccin 25.2 ). Escribe insertar un real

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

de la replicacin o la recuperacin. Cualquier

que contiene el ltimo reinicio punto vlido, como en archive_cleanup_command .

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.

26.2. Configuracin del destino de Recuperacin

recovery_target_name ( string )
Este parmetro especifica el punto de restauracin con nombre, creada con

pg_create_restore_point () a la que la recuperacin va a continuar. A lo

sumo uno

derecovery_target_name , recovery_target_time o recovery_target_xid se pueden

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

recovery_target_time , recovery_target_name o recovery_target_xid se

puede especificar. El valor predeterminado es recuperar al final del registro de WAL. El

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

recovery_target_xid , recovery_target_name o recovery_target_time se

pueden especificar. El valor predeterminado es recuperar al final del registro de WAL. El

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 (

verdadero ), o justo antes de la meta de recuperacin ( falso ). Se aplica tanto

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

verdadero . recovery_target_timeline ( string )

predeterminado es Especifica la recuperacin en una lnea de tiempo particular. El valor predeterminado es recuperar a lo largo de la misma lnea de tiempo que estaba vigente cuando se realiz la copia de seguridad base. Si se establece en

ltima recupere a la ltima lnea de

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

pg_xlog_replay_resume () (Ver Tabla 9-58 ), lo que provoca

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.

26.3. Configuracin del servidor en espera

Standby_mode ( booleano )
Especifica si se debe iniciar el PostgreSQL como servidor en espera. Si este parmetro est

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

servidor principal como se especifica en el primary_conninfo ( string )

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

PQconnectdb funcin, se describe en la Seccin 31.1 . Si alguna opcin no se

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

REPLICACIN y INGRESAR privilegios en el primario (vase la

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

especifique un nombre de base de datos en la

Este ajuste no tiene efecto si Standby_mode es trigger_file ( string )

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

pg_ctl promover . Este ajuste no tiene efecto

Standby_mode es off .

Captulo 27. Supervisin de la actividad de base de datos

Tabla de contenidos 27.1. estndar Unix Herramientas 27.2. El coleccionista Estadsticas 27.2.1. Estadsticas configuracin de la coleccin 27.2.2. Viendo Collected Estadsticas 27.3. Visualizacin Locks 27.4. Dynamic Tracing 27.4.1. Compilacin de seguimiento dinmico 27.4.2. Las sondas incorporadas en 27.4.3. Uso de Sondas 27.4.4. Definicin de nuevas sondas Un administrador de base de datos con frecuencia se pregunta, "Qu est haciendo el sistema en este momento?" Este captulo trata sobre cmo encontrar eso. Existen varias herramientas para monitorizar la actividad de base de datos y el anlisis de rendimiento. La mayor parte de este captulo est dedicado a la descripcin de PostgreSQL 's recolector de estadsticas, pero no hay que descuidar los programas de vigilancia de Unix regulares como

ps , top , iostat y vmstat . Adems, una vez que

se ha identificado una consulta de bajo rendimiento, podra ser necesaria una mayor investigacin utilizando PostgreSQL 's EXPLICAR comando. Seccin 14.1 discute

EXPLICAR y otros mtodos para comprender el comportamiento de una

consulta individual.

27.1. Estndar Unix Herramientas

En la mayora de plataformas Unix, PostgreSQL modifica su ttulo de comando segn lo informado por

ps , por lo que los procesos de servidor individuales pueden ser fcilmente

identificados. Una pantalla muestra es

$ 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

(La invocacin adecuada de

ps vara en diferentes plataformas, as como los detalles de lo que

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

transaccin (en espera de cliente dentro de un EMPEZAR bloque) o un nombre de tipo

comando comoSELECT . Adems, encuentra actualmente a la espera de un bloqueo que tiene otra sesin. En el ejemplo anterior podemos inferir que el proceso 1003 est a la espera para el proceso 1016 para completar su transaccin y de ese modo liberar parte de bloqueo. Si ha desactivado update_process_title entonces el indicador de actividad no se actualiza, el ttulo de proceso se configura una sola vez cuando se inicia un nuevo proceso. En algunas plataformas esto ahorra una cantidad medible de sobrecarga por mando, en otros es insignificante. Consejo: Solaris requiere un manejo especial. Usted debe usar lugar de

/ 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

invocacin original del

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

postgres lnea de comandos.

27.2. El coleccionista Estadsticas

PostgreSQL 's recolector de estadsticas es un subsistema que apoya la recopilacin y comunicacin de la informacin sobre la actividad del servidor. En la actualidad, el colector puede contar con accesos a las tablas e ndices, tanto en trminos de bloques de disco e individual-fila. Tambin realiza un seguimiento del nmero total de filas en cada tabla, y la informacin sobre vaco y analizar acciones para cada mesa. Tambin puede contar con las llamadas a funciones definidas por el usuario y el tiempo total empleado en cada uno. PostgreSQL tambin soporta la notificacin de la orden exacta est siendo ejecutado por otros procesos del servidor. Este servicio es independiente del proceso de colector.

27.2.1. Configuracin de la recopilacin de estadsticas

Desde recopilacin de estadsticas aade algo de sobrecarga para ejecucin de la consulta, el sistema puede ser configurado para recoger o no recoger informacin. Esto es controlado por los parmetros de configuracin que se establecen normalmente en

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

postgresql.conf para que se apliquen a

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

permanente de los datos de las estadsticas en el

rendimiento, el parmetrostats_temp_directory puede sealar a un sistema de archivos basado en RAM, la disminucin de los requisitos de E / S fsicas.

27.2.2. Visualizacin de las estadsticas acumuladas

Varios puntos de vista predefinidos, que se enumeran en la Tabla 27-1 , estn disponibles para mostrar los resultados de la recopilacin de estadsticas. Alternativamente, se puede crear vistas personalizadas mediante las funciones estadsticas subyacentes. Al utilizar las estadsticas para monitorizar la actividad actual, es importante darse cuenta de que la informacin no se actualiza instantneamente. Cada proceso de servidor individual transmite nuevos cargos estadsticos para el colector justo antes de ir inactivo, de modo que una consulta u operacin en curso no afecta los totales mostrados. Adems, el propio colector emite un nuevo informe como mximo una vez por

PGSTAT_STAT_INTERVAL milisegundos (500

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

track_activities est siempre al da.

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

pg_stat_clear_snapshot (), lo que

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

pg_stat_xact_all_tables , pg_stat_xact_sys_tables ,pg_stat_xact_u

ser_tables y pg_stat_xact_user_functions , o por medio de las funciones

subyacentes estos puntos de vista. Estos nmeros no actan como se ha indicado anteriormente, en su lugar se ponen al da continuamente durante toda la transaccin. Tabla 27-1. Estadsticas estndar Vistas

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

s entonces el sync_priority se muestra aqu

tambin, ese es el orden en el que se convertir en la carta de crdito standby sincronizada. Las columnas que detallan exactamente qu est haciendo la conexin slo son visibles si el usuario examen de la vista es un super-usuario. 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_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

Nota: Antes de PostgreSQL 8.1, los

idx_tup_read y idx_tup_fetch recuentos eran

esencialmente siempre igual. Ahora pueden ser diferentes, incluso sin tener en cuenta los anlisis de mapa de bits, porque ndice mientras

idx_tup_read entradas de ndice recuentos obtenidos del

idx_tup_fetch cuenta viven filas recuperadas de la mesa, esta ltima ser

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

pg_stat_get_db_numback ends ( OID )

enter o

Nmero de procesos del servidor de base de datos para activos

Funcin

Tipo devuelto

Descripcin

pg_stat_get_db_xact_co mmit ( OID ) pg_stat_get_db_xact_ro llback ( OID ) pg_stat_get_db_blocks_ fetched ( OID )

bigin t bigin t bigin t

Nmero de transacciones confirmadas en la base de datos

Nmero de transacciones deshace en la base de datos

Nmero de bloque de disco traiga solicitudes de base de datos

pg_stat_get_db_blocks_ hit ( OID )

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_

bigin t bigin t bigin t bigin t bigin

Nmero de tuplas devuelto por la base de datos

Nmero de tuplas devueltas para la base de datos

Nmero de tuplas inserta en la base de datos

Nmero de tuplas actualizados en la base de datos

Nmero de tuplas eliminados en la

Funcin

Tipo devuelto

Descripcin

deleted ( OID )

base de datos

pg_stat_get_db_conflic t_tablespace ( OID )

bigin t

Nmero de consultas cancelado debido a un conflicto con la recuperacin de espacios de tabla se redujo la base de datos

pg_stat_get_db_conflic t_lock ( OID )

bigin t

Nmero de consultas cancelado debido a un conflicto de recuperacin con bloqueos en la base de datos

pg_stat_get_db_conflic t_snapshot ( OID )

bigin t

Nmero de consultas cancelado debido a un conflicto de recuperacin con instantneas antiguas en la base de datos

pg_stat_get_db_conflic t_bufferpin ( OID )

bigin t

Nmero de consultas cancelado debido a un conflicto de recuperacin de topes fijados en la base de datos

pg_stat_get_db_conflic t_startup_deadlock (OI D )

bigin t

Nmero de consultas cancelado debido a un conflicto de recuperacin con bloqueos en la base de datos

pg_stat_get_db_stat_re set_time ( OID )

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

Tipo devuelto ejecucin

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

pg_stat_get_tuples_ret urned ( OID )

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

pg_stat_get_tuples_fet ched ( OID )

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

pg_stat_get_tuples_ins erted ( OID ) pg_stat_get_tuples_upd ated ( OID )

bigin t bigin t

Nmero de filas insertadas en la tabla

Nmero de filas actualizadas en la tabla (incluye actualizaciones HOT)

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 )

bigin t bigin t bigin t bigin t bigin t

Nmero de registros borrados de la tabla

Nmero de filas HOT-actualizada en la tabla

Nmero de filas en directo en la tabla

Nmero de filas de muertos en la tabla

Nmero de bloque de disco traiga solicitudes de tabla o ndice

pg_stat_get_blocks_hit ( OID )

bigin t

Nmero de peticiones de bloques de disco se encuentra en la cach para la tabla o ndice

pg_stat_get_last_vacuu m_time ( OID )

times tampt z times tampt z

Hora del ltimo no COMPLETO vaco iniciada por el usuario en esta tabla

pg_stat_get_last_autov acuum_time ( OID )

Hora del ltimo vaco iniciada por el demonio autovacuum en esta tabla

Funcin

Tipo devuelto

Descripcin

pg_stat_get_last_analy ze_time ( OID )

times tampt z times tampt z

Hora del ltimo analice iniciado por el usuario en esta tabla

pg_stat_get_last_autoa nalyze_time ( OID )

Hora del ltimo analice iniciado por el demonio autovacuum en esta tabla

pg_stat_get_vacuum_cou nt ( OID )

bigin t

El nmero de veces que esta tabla ha sido no COMPLETO aspiradora manual

pg_stat_get_autovacuum _count ( OID )

bigin t

El nmero de veces que esta tabla ha sido aspirado por el demonio autovacuum

pg_stat_get_analyze_co unt ( OID )

bigin t

El nmero de veces que esta tabla se ha analizado de forma manual

pg_stat_get_autoanalyz e_count ( OID )

bigin t

El nmero de veces que esta tabla ha sido analizado por el demonio autovacuum

pg_stat_get_xact_numsc ans ( 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, en la transaccin actual

Funcin

Tipo devuelto

Descripcin

pg_stat_get_xact_tuple s_returned ( OID )

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

pg_stat_get_xact_tuple s_fetched ( OID )

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

pg_stat_get_xact_tuple s_inserted ( OID )

bigin t

Nmero de filas insertadas en la tabla, en la transaccin actual

pg_stat_get_xact_tuple s_updated ( OID )

bigin t

Nmero de filas actualizadas en la tabla (incluye actualizaciones caliente), en la transaccin actual

pg_stat_get_xact_tuple s_deleted ( OID ) pg_stat_get_xact_tuple s_hot_updated ( OID ) pg_stat_get_xact_block s_fetched ( OID )

bigin t bigin t bigin t

Nmero de filas eliminadas de la tabla, en la transaccin actual

Nmero de filas HOT-actualizados en la tabla, en la transaccin actual

Nmero de bloque de disco traiga solicitudes de tabla o un ndice, en la

Funcin

Tipo devuelto

Descripcin

transaccin actual

pg_stat_get_xact_block s_hit ( OID )

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

ID de proceso del proceso del servidor conectado a la sesin actual

pg_stat_get_activity ( nmero entero )

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.

pg_stat_get_function_c alls ( OID )

bigin t

Nmero de veces que la funcin se ha llamado

pg_stat_get_function_t ime ( OID )

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

El tiempo dedicado a esta funcin nica. Se excluye el tiempo dedicado

Funcin

Tipo devuelto

Descripcin

elf_time ( OID ) pg_stat_get_xact_funct ion_calls ( OID )

t bigin t

a funciones llamadas.

Nmero de veces que la funcin se ha llamado, en la transaccin actual.

pg_stat_get_xact_funct ion_time ( OID )

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.

pg_stat_get_xact_funct ion_self_time ( OID )

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.

pg_stat_get_backend_pi d ( nmero entero ) pg_stat_get_backend_db id ( nmero entero )

enter o

ID de proceso del proceso de servidor determinado

oid

Nmero de registro del proceso de servidor determinado

pg_stat_get_backend_us

oid

ID de usuario del proceso de servidor

Funcin

Tipo devuelto determinado

Descripcin

erid ( nmero entero )

pg_stat_get_backend_ac tivity ( nmero entero)

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)

pg_stat_get_backend_wa iting ( nmero entero)

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)

pg_stat_get_backend_ac tivity_start ( nmero entero )

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)

pg_stat_get_backend_xa ct_start ( nmero entero )

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

ia Fecha y hora con zona horar ia

activada)

pg_stat_get_backend_st art ( nmero entero )

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

pg_stat_get_backend_cl ient_addr ( nmero entero )

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

pg_stat_get_backend_cl ient_port ( nmero entero )

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

s se ha excedido o porque el PUNTO DE CONTROL comando se ha emitido

pg_stat_get_bgwriter_b uf_written_checkpoints ()

bigin t

Nmero de bferes escritos por el escritor de fondo durante los controles

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

el tablero de base de datos.

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

Nmero total de reservas de buffer

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

Deseche la corriente instantnea de estadsticas

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

t_reset_shared ('bgwriter') pondr a cero

todos los valores mostrados

Funcin

Tipo devuelto

Descripcin

por pg_stat_bgwriter .

pg_stat_reset_single_t able_counters (OID)

anula r

Restablecer las estadsticas de una sola tabla o ndice en la base de datos actual a cero (requiere privilegios de superusuario)

pg_stat_reset_single_f unction_counters (OID)

Nota:

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

_blks_readestadsticas columnas utilizan esta resta, es decir, menos exagerado xito.

Todas las funciones de acceso a la informacin sobre los motores son indexados por nmero de identificacin backend, excepto

pg_stat_get_activity que est indexado por PID. La

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;

27.3. Visualizacin Locks

Otra herramienta til para monitorizar la actividad de base de datos es la

pg_locks tabla del

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

pg_locks vista aparecen en la Seccin 45.56 . Para obtener ms informacin

sobre el bloqueo y la gestin de concurrencia con PostgreSQL , consulte el Captulo 13 .

27.4. Dynamic Tracing

PostgreSQL ofrece instalaciones para apoyar el seguimiento dinmico del servidor de base de datos. Esto permite que una utilidad externa que se llama en puntos especficos en el cdigo y con ello traza de ejecucin. Un nmero de sondas o puntos de traza ya se insertan en el cdigo fuente. Estas sondas estn destinados a ser utilizados por los desarrolladores y administradores de bases de datos.Por defecto, las sondas no se compilan en PostgreSQL , el usuario debe indicar explcitamente el script de configuracin para que las sondas disponibles. En la actualidad, slo el DTrace utilidad es compatible, que est disponible en OpenSolaris, Solaris 10, y Mac OS X Leopard. Se espera que DTrace estar disponible en el futuro en FreeBSD y posiblemente otros sistemas operativos. El SystemTap proyecto de Linux tambin proporciona un DTrace equivalente. Apoyo a otras utilidades de seguimiento dinmico es tericamente posible, cambiando las definiciones de las macros en

src / include / utils /

probes.h .

27.4.1. Compilacin de seguimiento dinmico

De forma predeterminada, las sondas no estn disponibles, por lo que tendrn que decirle explcitamente el script de configuracin para que las sondas disponibles en PostgreSQL . Para incluir soporte DTrace especificar 15.4 para ms informacin.

- enable-dtrace configurar. Consulte la Seccin

27.4.2. Las sondas incorporadas en

Un nmero de sondas estndar se proporcionan en el cdigo fuente, como se muestra en la Tabla 27-3 , Tabla 27-4 muestra los tipos utilizados en las sondas. Ms sondas sin duda se pueden aadir para mejorar PostgreSQL observabilidad 's. Tabla 27-3. Construido en sondeos de DTrace

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.

consulta de (Const char *) inicio

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 *)

Sondeo que se activa cuando se inicia el anlisis de una

Nombre inicio

Parmetros

Descripcin consulta. arg0 es la cadena de consulta.

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 de planta de () arranque

Sondeo que se activa cuando se inicia la planificacin de una consulta.

consulta de planta() hecho

Sondeo que se activa cuando la planificacin de una consulta se ha completado.

consulta a ejecutar en () marcha

Sondeo que se activa cuando se inicia la ejecucin de una consulta.

consulta a ejecutarhecho

()

Sondeo que se activa cuando la ejecucin de una consulta es completa.

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

y estado. arg0 es la nueva cadena de estado.

Sondeo que se activa cuando se inicia 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.

punto de control de arranque

(Int)

puesto de control realizado

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.

obstruccio nes puesto de control (Bool) de arranque

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.

obstruccio nes (Bool) checkpoint -hecho

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.

subtranspuesto 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.

subtranscheckpoint (Bool) -hecho

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

multixactpuesto de control de arranque

(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.

multixactcheckpoint (Bool) -hecho

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.

bufferpuesto 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.

buffer(Int, int, int) sync-hecho

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

Nombre control de sincronizaci n de inicio

Parmetros fsync.

Descripcin

buffercheckpoint () -hecho

Sondeo que se activa cuando la sincronizacin de buffers en el disco est completo.

dos fasespuesto de control de arranque

()

Sondeo que se activa cuando se inicia la porcin de dos fases de un puesto de control.

dos fasescheckpoint () -hecho

Sondeo que se activa cuando la porcin de dos fases de un puesto de control se ha completado.

bfer de lectura en marcha

(ForkNumber, BlockNumber, Oid, Oid, Oid, int, bool)

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.

(ForkNumber, bufferBlockNumber, read-hecho Oid, Oid, Oid, int, bool, bool)

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

(ForkNumber, BlockNumber, Oid, Oid, Oid)

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.

(ForkNumber, buffer-rasBlockNumber, hecho Oid, Oid, Oid)

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.

bufferescritura sucia de inicio

(ForkNumber, BlockNumber, Oid, Oid, Oid)

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

(ForkNumber, BlockNumber, Oid, Oid, Oid)

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 un WAL buffer como sucio es completa.

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 cuando se solicita un cambio de segmento WAL.

(ForkNumber, SMGR-md- BlockNumber, read-inicio Oid, Oid, Oid, int)

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.

(ForkNumber, SMGR-mdBlockNumber, lecturaOid, Oid, Oid, hecho int, int, int)

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).

SMGR-md(ForkNumber, escritura BlockNumber, en marcha Oid, Oid, Oid,

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.

(ForkNumber, SMGR-mdBlockNumber, writeOid, Oid, Oid, hecho int, int, int)

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.

tipo-hecho (Int, long)

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.

lwlock(LWLockId, condacquir LWLockMode) e

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.

lwlock(LWLockId, condacquir LWLockMode) e quebrar

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

callejn sin salida() found

Sondeo que se activa cuando un callejn sin salida, apreciada por el detector de punto muerto.

Tabla 27-4. Tipos definidos utilizados en los parmetros de sonda

Tipo

Definicin

LocalTransactionId unsigned int

LWLockId

int

LWLockMode

int

LockMode

int

BlockNumber

unsigned int

Oid

unsigned int

ForkNumber

int

bool

carbn

27.4.3. Uso de Sondas

El siguiente ejemplo muestra una secuencia de comandos de DTrace para el anlisis de los recuentos de transaccin en el sistema, como una alternativa a snapshotting

pg_stat_databaseantes y despus de una prueba de rendimiento:

! # / Usr / sbin / dtrace-qs

postgresql $ 1 ::: transaccin de inicio { @ Inicio ["Start"] = count (); self-> ts = marca de tiempo; }

postgresql $ 1 ::: operacin de aborto { @ Abortar ["Cancelar"] = count (); }

postgresql $ 1 ::: transaccin-commit / Self-> ts / { @ Commit ["Commit"] = count (); @ Tiempo ["El tiempo total (ns)"] = suma (timestamp - self> ts); self-> ts = 0; }

Cuando se ejecuta, el script de ejemplo D da salida como:

#. / Txn_count.d `pgrep-n postgres` o. / Txn_count.d <PID> ^ C

Inicio 71 Comprometerse 70 Tiempo total (ns) 2312105013

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 .

27.4.4. Definicin de nuevas sondas

Nuevas sondas pueden ser definidos dentro del cdigo donde los deseos de desarrollo, aunque esto requerir una recompilacin. A continuacin se presentan los pasos para la insercin de nuevas sondas: 1. Decidir sobre los nombres y los datos de la sonda que estar disponibles a travs de las sondas 2. Agregue las definiciones de sondeo a

src / backend / utils / probes.d

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

transaccin de inicio y requiere un parmetro

src / backend / utils / probes.d :

3. sonda transaction__start (LocalTransactionId);

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

la transaccin de inicio es el nombre del documento

transaction__start se convierte en una macro pg_trace.h . Aada la llamada macro

TRACE_POSTGRESQL_TRANSACTION_START (notar el relieve son solo

aqu), que est disponible mediante la inclusin

en la ubicacin adecuada en el cdigo fuente. En este caso, se tiene el siguiente aspecto:

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:

7. # Dtrace-ln transaccin de inicio 8. ID PROVEEDOR MDULO NOMBRE FUNCIN

9. 18705 postgresql49878 postgres StartTransactionCommand transaccin de inicio 10. 18755 postgresql49877 postgres

StartTransactionCommand transaccin de inicio 11. 18805 postgresql49876 postgres

StartTransactionCommand transaccin de inicio 12. 18855 postgresql49875 postgres

StartTransactionCommand transaccin de inicio 13. 18986 postgresql49873 postgres

StartTransactionCommand transaccin de inicio

Hay algunas cosas a tener cuidado al agregar macros de seguimiento al cdigo C:

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.

En la mayora de plataformas, si PostgreSQL se construye con

- 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 ())

TRACE_POSTGRESQL_TRANSACTION_START (some_function (...));

Cada macro tiene una huella correspondiente

HABILITADO macro.

Captulo 28. Supervisar el uso de disco

Tabla de contenidos 28.1. Determinacin de uso de disco 28.2. fallo de disco completo En este captulo se explica cmo controlar el uso del disco de PostgreSQL sistema de base de datos.

28.1. Determinacin de uso de disco

Cada tabla tiene un montn de archivos de disco principal donde la mayora de los datos estn almacenados. Si la tabla tiene las columnas con valores potencialmente en todo, tambin puede haber un TOAST archivo asociado con la tabla que se utiliza para almacenar valores demasiado grandes para caber cmodamente en la mesa principal (vase la Seccin 55.2 ). Habr un ndice en la TOSTADA mesa, si est presente. Tambin puede haber ndices asociados a la tabla base. Cada tabla y el ndice se almacenan en un archivo de disco independiente - posiblemente ms de un archivo, si el archivo superara un gigabyte. Convenciones de nombres de estos archivos se describen en la Seccin 55.1 . Puede controlar el espacio de disco de tres maneras: usando las funciones de SQL que figuran en la Tabla 9-59 , usando el oid2name mdulo, o el uso de la inspeccin manual de los catlogos del sistema. Las funciones de SQL son los ms fciles de usar y por lo general se recomiendan. El resto de esta seccin se muestra cmo hacerlo mediante la inspeccin de los catlogos del sistema. Usando psql en un recientemente aspirada o base de datos analizados, puede realizar consultas para ver el uso de disco de cualquier tabla:

SELECT pg_relation_filepath (OID), relpages DESDE DONDE pg_class relname = "cliente";

pg_relation_filepath | relpages ---------------------- + ---------base/16384/16806 | 60 (1 row)

Cada pgina es tpicamente 8 kilobytes. (Recuerde, por

relpages slo se actualiza

VACO , ANALIZAR , y algunos comandos DDL como CREATE INDEX .) El nombre de la

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;

relname | relpages ---------------------- + ---------pg_toast_16806 | 0 pg_toast_16806_index | 1

Se puede mostrar fcilmente tamaos ndice, tambin:

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;

relname | relpages ---------------------- + ---------customer_id_indexdex | 26

Es fcil encontrar a tus tablas e ndices utilizando la informacin ms grandes:

SELECT relname, relpages DE pg_class ORDER BY relpages DESC;

relname | relpages ---------------------- + ---------BigTable | 3290 cliente | 3144

28.2. Fallo de disco completo

La ms importante tarea de monitoreo de disco de un administrador de base de datos es para asegurarse de que el disco no se ha llenado. Un disco de datos lleno de no daar los datos, pero puede evitar que se produzca actividad til. Si el disco que contiene los archivos WAL crece podran ocurrir, pnico servidor de base de datos completa y la consecuente paralizacin.

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.

Captulo 29. La fiabilidad y la escritura anticipada registro

Tabla de contenidos 29.1. Confiabilidad 29.2. escritura anticipada registro ( WAL ) 29.3. asincrnico Encomienda 29.4. WAL configuracin 29.5. Internos de WAL

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

hdparm-I ; cach de escritura

* 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

sdparm - clear = WCE para desactivarlo. atacontrol y cach de

En FreeBSD , los discos IDE se pueden consultar utilizando escritura desactivado usando

hw.ata.wc = 0 en / boot / loader.conf ; camcontrol identificar , y la sdparm cuando est disponible.

unidades SCSI pueden ser consultados mediante

cach de escritura tanto consultar y modificar con

En Solaris , la cach de escritura en disco es controlado por

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

wal_sync_method es open_datasync (por defecto), la cach Mi PC \ Abrir \ disco \

de escritura se puede desactivar desmarcando

Inmuebles \ Hardware \ Inmuebles \ Policies \ Habilitar cach de escritura en el disco . Alternativamente,

ajuste

wal_sync_method a fsync o fsync_writethrough , que impiden la

cach de escritura.

En Mac OS X , el cach de escritura se puede prevenir mediante el establecimiento de

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

durante mucho tiempo un comando similar

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).

29.2. Escritura anticipada registro ( WAL )

Escritura anticipada registro ( WAL ) es un mtodo estndar para garantizar la integridad de los datos. Una descripcin detallada se puede encontrar en la mayora (si no todos) los libros sobre el procesamiento de transacciones. En pocas palabras, WAL concepto central 's es que los cambios en los archivos de datos (donde residen las tablas e ndices) deben escribirse slo despus de esos cambios se han registrado, es decir, despus de registros que describen los cambios que se han volcado a su almacenamiento permanente. Si seguimos este procedimiento, no es necesario para eliminar las pginas de datos en disco en cada confirmacin de transaccin, ya que sabemos que en el caso de un accidente, podremos recuperar la base de datos con el registro: los cambios que no se han aplicado a las pginas de datos puede hacerse de nuevo a partir de los registros. (Se trata de la recuperacin en avance, tambin conocido como REDO.) Consejo: Debido WAL restaura el contenido del archivo de base de datos despus de un accidente, los sistemas de archivos de diario no son necesarios para el almacenamiento seguro

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.

fsync del archivo de registro puede ser suficiente para cometer

29.3. Commit asncrono

Commit asincrnico es una opcin que permite que las transacciones para completar ms rpidamente, a costa de que las transacciones ms recientes se pueden perder si la base de datos debe bloquearse. En muchas aplicaciones, se trata de un compromiso aceptable. Como se describe en la seccin anterior, transaccin de confirmacin suele sincrnica : el servidor espera a que la transaccin WAL registros a las tablas de almacenamiento permanente antes de devolver una indicacin xito al cliente. Por consiguiente, el cliente se garantiza que una transaccin informado de que se cometido ser preservado, incluso en el caso de una cada

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

Ciertos comandos de utilidad, por ejemplo

sincrnicamente independientemente de la configuracin de

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 ,

wal_writer_delay porque el escritor WAL est diseado para favorecer la creacin de

pginas enteras a la vez durante perodos de mucho trabajo.

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.

Compromiso asncrono proporciona un comportamiento diferente del fijando fsync = off.

fsync es un servidor de toda configuracin que va a alterar el comportamiento de todas las

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

fsync , pero sin el riesgo de corrupcin de datos.

commit_delay tambin suena muy similar a commit asincrnico, pero en realidad es un mtodo de confirmacin sncrona (de hecho, asincrnica).

commit_delay se ignora durante una confirmacin

commit_delay provoca un retraso antes de un intento de confirmacin sncrona

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

commit_delay slo puede ayudar cuando hay muchas

operaciones simultneamente cometer, y es difcil de ajustar a un valor que realmente ayuda ms que perjudica el rendimiento.

29.4. WAL configuracin

Hay varias WAL parmetros de configuracin relacionados que afectan al rendimiento de base de datos. En esta seccin se explica su uso. Consulte el Captulo 18 para obtener informacin general sobre la configuracin de los parmetros de configuracin del servidor. Los puntos de control son puntos en la secuencia de las operaciones en las que se garantiza que los archivos de datos de almacenamiento dinmico y el ndice se han actualizado con toda la informacin por escrito antes de que el puesto de control. A la hora del punto de control, todas las pginas de datos no se vacan en el disco y un registro especial de control se escriben en el archivo de registro. (Los cambios se lavaron previamente a los WAL archivos.) En el caso de un choque, el procedimiento de recuperacin de fallos se ve en el ltimo disco de control para determinar el punto en el registro (conocido como el registro redo) de la que debe comenzar la REDO operacin. Los cambios realizados en los archivos de datos antes de ese punto se garantiza que sea ya en el disco. Por lo tanto, despus de un punto de control, registro ya no son necesarios los segmentos anteriores del que contiene el registro de rehacer y pueden ser reciclados o eliminados. (Cuando WAL se est haciendo de archivo, los segmentos de registro deben ser archivados antes de ser reciclado o eliminado.) El requisito puesto de control de lavado de todas las pginas de datos modificados al disco puede causar una carga significativa de E / S. Por esta razn, la actividad puesto de control es estrangulado por lo E / S comienza en el punto de control de inicio y se completa antes de que comience el prximo punto de control, lo que reduce al mnimo la degradacin del rendimiento durante los puestos de control. Proceso escritor fondo del servidor realiza automticamente un puesto de control de vez en cuando. Un punto de control se crea cada checkpoint_segments segmentos de registro, o cadacheckpoint_timeout segundo, lo que ocurra primero. La configuracin predeterminada es 3 segmentos y 300 segundos (5 minutos), respectivamente. Tambin es posible forzar a un puesto de control con el comando SQL Reducir

PUNTO DE CONTROL .

checkpoint_segments y / o checkpoint_timeout causa puestos 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

servidor recomendar crecientes

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

checkpoint_segments lo suficientemente alto.

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

inicio punto de control, o la fraccin dada de

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

checkpoint_completion_target para reducir la carga de E / S de los puestos

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

checkpoint_completion_target ) * checkpoint_segments + 1 checkpoint_segments +wal_keep_segments + 1 archivos. Cada segmento de archivo es

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 *

checkpoint_segments 1 ficheros segmento +, los archivos innecesarios del

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

pg_control archivo para indicar

que los datos WAL ya procesados no tienen que ser escaneados de nuevo, y luego recicla los viejos archivos del segmento de registro en

pg_xlog directorio. A restartpoint se activa si al checkpoint_timeout segundos han

menos un registro de punto de control se ha repetido y

pasado desde la ltima restartpoint. En el modo de espera, un restartpoint tambin se activa si

checkpoint_segments segmentos de registro se han repetido desde el pasado

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:

LogInsert y LogFlush . LogInsert se utiliza

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

llenas WAL buffers. Esto no es deseable porque

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

tiempo. Normalmente, WALtampones deben ser escritos y sonrojadas por una

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

LogInsert de tener que hacer escrituras. En tales sistemas

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

LogFlush . Este retraso permite a otros procesos de servidor para aadir

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

fsync_writethrough , que a veces puede obligar a un vaciado de la cach de disco,

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

LogInsert y LogFlush WAL llamada

se registra en el registro del servidor. Esta opcin podra ser sustituido por un mecanismo ms general en el futuro.

29.5. Internos de WAL

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

pg_xlog bajo el directorio de datos, como un

conjunto de archivos de segmento, normalmente cada 16 MB de tamao (pero el tamao puede ser cambiado mediante la alteracin de la

- con-Wal-segsize opcin de configurar la hora opcin - with-wal-blocksize opcin de el acceso /

de construir el servidor) . Cada segmento se divide en pginas, normalmente 8 kB cada uno (este tamao se puede cambiar a travs de la

configuracin). Los encabezados de registro de registro se describen en

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

000000010000000000000000 .Los nmeros no se ajustan, pero tomar un tiempo

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

pg_xlog directorio a otra ubicacin (mientras 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

pg_control . Por lo tanto, en el inicio de la

pg_control y entonces el registro de punto; entonces se

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.

Para lidiar con el caso en

pg_control es corrupto, debemos apoyar la posibilidad de escanear pg_control es lo

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,

pg_control en s. As que, aunque en teora

pg_control no parece ser un problema en la prctica.

Captulo 30. Las pruebas de regresin

Tabla de contenidos 30.1. Ejecucin de las Pruebas 30.1.1. Ejecucin de las pruebas en contra de una instalacin temporal 30.1.2. Ejecucin de las pruebas en contra de una instalacin existente 30.1.3. Prueba de Hot Standby 30.1.4. Configuracin regional y codificacin 30.1.5. Ensayos adicionales 30.2. Evaluacin de prueba 30.2.1. Error Diferencias Mensaje 30.2.2. Diferencias Locale 30.2.3. fecha y hora Diferencias 30.2.4. Las diferencias de punto flotante 30.2.5. Fila Orden Diferencias 30.2.6. insuficiente profundidad de la pila 30.2.7. El "azar" de prueba 30.3. Archivos Comparacin Variant 30.4. Prueba de Examen de cobertura Las pruebas de regresin son un conjunto completo de pruebas para la aplicacin SQL en PostgreSQL . Ponen a prueba las operaciones de SQL estndar, as como las capacidades ampliadas de PostgreSQL .

30.1. Ejecucin de las Pruebas

Las pruebas de regresin se pueden ejecutar en un servidor ya instalado y en funcionamiento, o el uso de una instalacin temporal en el rbol de construccin. Adems, hay un "paralelo" y un "secuencial" modo de ejecucin de las pruebas. El mtodo secuencial ejecuta cada script de prueba solamente, mientras que el mtodo paralelo, se pone en marcha varios procesos de servidor para ejecutar grupos de pruebas en paralelo. Pruebas paralelas da confianza en que la comunicacin entre procesos y el bloqueo funcionen correctamente.

30.1.1. Ejecucin de las pruebas en contra de una instalacin temporal

Para ejecutar las pruebas de regresin paralelas despus de la construccin, pero antes de la instalacin, escriba:

gmake comprobar

en el directorio de nivel superior. (O bien, puede cambiar a

src / test / retroceso y

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:

======================= Las 115 pruebas pasaron. =======================

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

comprobacin gmake antes de instalar la nueva versin, usted podra

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

configure - disable-rpath . No se recomienda utilizar esta opcin para la

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

MAX_CONNECTIONS parmetro. Por ejemplo:

gmake MAX_CONNECTIONS = 10 compruebe

se ejecuta no ms de diez pruebas simultneamente.

30.1.2. Ejecucin de las pruebas en contra de una instalacin existente

Para ejecutar las pruebas despus de la instalacin (vase el captulo 15 ), se inicializa un rea de datos e iniciar el servidor, como se explica en el captulo 17 , a continuacin, escriba:

gmake installcheck

o para una prueba en paralelo:

gmake installcheck paralelo

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

PGHOST y PGPORT variables de entorno.

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

Tambin puede hacerlo en cualquiera de los subdirectorios

src / pl para ejecutar las pruebas

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

30.1.3. Prueba de Hot Standby

La distribucin fuente tambin contiene pruebas de regresin del comportamiento esttico de Hot Standby. Estas pruebas requieren un servidor primario corriente y un servidor de reserva en ejecucin que est aceptando nuevos cambios WAL de la primaria utilizando el trasvase de registros basados en archivos o replicacin streaming. Los servidores no se crean automticamente para usted, ni es la instalacin documentado aqu. Por favor, consulte las distintas secciones de la documentacin ya dedicados a los comandos necesarios y las cuestiones conexas.

En primer lugar crear una base de datos llamada "regresin" en el principal.

psql-h primaria-c "CREATE regresin DATABASE"

A continuacin, ejecutar un script de preparacin de la primaria en la base de datos de regresin:

src / test / retroceso / sql / hs_primary_setup.sql , y permitir

que los cambios se propaguen a la espera, por ejemplo,

psql-h-f primaria src / test / retroceso / sql / hs_primary_setup.sql regresin

Ahora compruebe que la conexin por omisin para el probador es el servidor Standby bajo prueba y ejecute el

standbycheck destino desde el directorio de regresin:

cd src / test / retroceso gmake standbycheck

Algunas conductas extremas tambin pueden generarse en la primaria mediante el script:

src

/ test / retroceso / sql / hs_primary_extremes.sql para permitir que el

comportamiento de la espera para ser probado. Pruebas automatizadas adicional puede estar disponible en versiones posteriores.

30.1.4. Idioma y Codificacin

Por defecto, las pruebas en contra de una instalacin temporal utilizan la configuracin regional definida en el entorno actual y la codificacin de la base de datos correspondiente, determinado por

initdb . Puede ser til para probar diferentes configuraciones regionales mediante el

establecimiento de las variables de entorno adecuadas, por ejemplo:

gmake comprobar LANG = C gmake cheque LC_COLLATE = en_US.utf8 LC_CTYPE = fr_CA.utf8

Por razones de implementacin, configuracin

LC_ALL no funciona para este propsito, todas

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

CODIFICACIN , por ejemplo:

gmake check LANG = C ENCODING = EUC_JP

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.

30.1.5. Pruebas adicionales

El conjunto de pruebas de regresin contiene algunos archivos de prueba que no se ejecutan por defecto, ya que pueden ser dependientes de la plataforma o tardar mucho tiempo en ejecutarse. Puede ejecutar estos u otros archivos de prueba adicionales mediante el establecimiento de las variables el

EXTRA_TESTS . Por ejemplo, para ejecutar

numeric_big prueba:

gmake cheque EXTRA_TESTS = numeric_big

Para ejecutar las pruebas de cotejo:

gmake cheque EXTRA_TESTS = collate.linux.utf8 LANG = en_US.utf8

El

collate.linux.utf8 prueba slo funciona en Linux / glibc plataformas, y slo cuando se

ejecuta en una base de datos que utiliza la codificacin UTF-8.

30.2. Prueba de Evaluacin

Algunos instalados correctamente y completamente funcionales PostgreSQL instalaciones pueden "quebrar" algunas de estas pruebas de regresin debido a los artefactos especficos de la plataforma, tales como diversos representacin de coma flotante y el mensaje de texto. Las pruebas se evalan actualmente el uso de una simple

esta comparacin contra los resultados

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 /

test / retroceso / Resultados directorio. La secuencia de comandos de prueba

utiliza el

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.

30.2.1. Error Diferencias Mensaje

Algunas de las pruebas de regresin implican valores de entrada no vlidos intencionales. Los mensajes de error pueden provenir del PostgreSQL cdigo o de las rutinas del sistema de plataforma de acogida. En este ltimo caso, los mensajes pueden variar entre plataformas, pero deben reflejar informacin similar. Estas diferencias en los mensajes darn lugar a un"fallido" prueba de regresin que puede ser validado por la inspeccin.

30.2.2. Diferencias Locale

Si ejecuta las pruebas en contra de un servidor que se ha inicializado con una configuracin regional de intercalacin de orden distinta de C, es posible que haya diferencias por orden de clasificacin y los fracasos posteriores. El conjunto de pruebas de regresin se estableci para manejar este problema al proporcionar archivos de resultados alternativos que en conjunto se conocen para manejar un gran nmero de locales. Para ejecutar las pruebas en un escenario diferente cuando se utiliza el mtodo de instalacin temporal, pasar las variables de entorno apropiadas localidad relacionados con el lnea de comandos, por ejemplo:

hacer quela

gmake check LANG = de_DE.utf8

(El piloto de pruebas de regresin se desarma

LC_ALL , por lo que no funciona para seleccionar C ) o utilizar la

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:

cheque gmake NO_LOCALE = 1

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.

30.2.3. Fecha y hora Diferencias

La mayora de los resultados de la fecha y la hora son dependientes en el medio ambiente de zona horaria. Los archivos de referencia se generan para la zona horaria

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

PGTZ aPST8PDT , que normalmente garantiza resultados adecuados.

30.2.4. Las diferencias de punto flotante

Algunas de las pruebas implican computacin nmeros de punto flotante de 64 bits (

doble

precisin ) de las columnas de la tabla. Las diferencias en los resultados relacionados con las
funciones matemticas de columnas. Los

doble precisin se han observado

float8 y geometra de las pruebas son particularmente propensos a las

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

previsto por la corriente PostgreSQL cdigo.

30.2.5. Fila Diferencias Orden

Usted puede ver las diferencias en las que las mismas filas se emiten en un orden diferente al que aparece en el fichero esperada. En la mayora de los casos esto no es, estrictamente hablando, un error. La mayora de los scripts de pruebas de regresin no son tan pedante como utilizar un

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

ORDER BY no es un problema. Algunas consultas hacen exhiben diferencias ordenamiento

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

no predeterminados, como los valores personalizados de planificador.

work_mem o los parmetros de costos

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.

30.2.6. Insuficiente profundidad de la pila

Si los el

errores de resultados de la prueba en una cada del servidor en

infinite_recurse seleccione () de comandos, que significa que el lmite de la

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 .

30.2.7. El "azar" de prueba

El

azar script de prueba est diseado para producir resultados aleatorios. En casos raros, esto

hace que la prueba de regresin aleatoria falle. Typing:

resultados diff / random.out espera / random.out

debe producir slo una o unas pocas lneas de diferencias. Usted no necesita preocuparse a menos que la prueba aleatoria falla repetidamente.

30.3. Archivos Comparacin Variant

Dado que algunas de las pruebas por s producen resultados depende del entorno, hemos proporcionado maneras de especificar alternativas "esperados" archivos de resultados. Cada

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,

src / test / retroceso /

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.

Cada lnea en el archivo de asignacin es de la forma

nombre_prueba: Salida: platformpattern = comparisonfilename

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

config.guess . El nombre del archivo de comparacin es el nombre base

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,

estos sistemas.Para silenciar la falsa "fracaso" mensaje en OpenBSD plataformas,

float8: Salida:. i.86-*-openbsd = float8-small-is-zero.out

lo que dar lugar en cualquier equipo en el que la salida de

config.guess coincide i.86-.

*-openbsd . Otras lneas de resultMap seleccionar el archivo de comparacin variante para

otras plataformas en las que es apropiado.

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

nombre_prueba cabo. , y los archivos de variantes

_ dgitos a cabo. (donde la cifra es de un solo

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

nombre_prueba es el nombre dado sustituto en resultMap .) carbn de lea de prueba, la comparacin de

Por ejemplo, para el archivos

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

que el archivo lugares.

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.

30.4. Prueba de Examen de cobertura

El cdigo fuente se puede compilar PostgreSQL con la cobertura de las pruebas de instrumentos, de modo que se hace posible examinar qu partes del cdigo estn cubiertos por las pruebas de regresin o cualquier otro conjunto de pruebas que se ejecuta con el cdigo. Esto se apoya actualmente al compilar con GCC y requiere los

gcov y lcov programas.

Un flujo de trabajo tpico sera el siguiente:

. / Configure - enable-cobertura ... OTRAS OPCIONES ... gmake gmake cheque # u otro conjunto de pruebas

gmake cobertura-html

Entonces apunte su navegador HTML de tambin funcionan en los subdirectorios.

cobertura / index.html . Los gmake comandos

Para reiniciar los contadores de ejecucin entre las ejecuciones de prueba, ejecute:

gmake cobertura de limpiar