Buscar este blog

viernes, 11 de noviembre de 2016

59.1. Diseño de base de datos de archivos

En esta sección se describe el formato de almacenamiento a nivel de archivos y directorios.

Tradicionalmente, los archivos de configuración y los datos utilizados por un grupo de base de datos se almacenan juntos dentro de directorio de datos del cluster,
se hace referencia comúnmente como PGDATA (después del nombre de la variable de entorno que se puede utilizar para definir él). Un lugar común para PGDATA es / var
/ lib / pgsql / data . Varios clústeres, gestionados por diferentes instancias del servidor, pueden existir en la misma máquina.

El PGDATA contiene directorios y archivos de control, como se muestra en la Tabla 59-1 . Además de estos elementos necesarios, los archivos de configuración de
clúster postgresql.conf , pg_hba.conf , y pg_ident.conf se almacenan tradicionalmente en PGDATA , aunque es posible colocarlos en otro lugar.


Tabla 59-1. Contenido de PGDATA

ít.                        descripción
pg_version             Un archivo que contiene el número de versión principal de PostgreSQL
base                        Subdirectorio que contiene subdirectorios por base de datos
global                  Subdirectorio que contiene las tablas de todo el racimo, como pg_database
pg_clog        Subdirectorio que contiene los datos de estado de confirmación de transacción
pg_dynshmem        Subdirectorio que contiene los archivos que utiliza el subsistema de memoria                                        dinámica compartida
pg_logical        datos de estado que contiene subdirectorios para decodificación lógica
pg_multixact        Subdirectorio que contiene multitransaction datos de estado (utilizado para                                            bloqueos de registro compartidos)
pg_notify        Subdirectorio que contiene LISTEN / NOTIFY datos de estado
pg_replslot        Subdirectorio de datos ranura que contiene la replicación
pg_serial        Subdirectorio que contiene información sobre las transacciones serializables                                         cometidos
pg_snapshots        instantáneas de subdirectorios que contiene exportado
pg_stat        Subdirectorio que contiene los archivos permanentes para el subsistema de                                            estadísticas
pg_stat_tmp        Subdirectorio que contiene los archivos temporales para el subsistema de                                              estadísticas
pg_subtrans        Subdirectorio que contiene datos de estado subtransacción
pg_tblspc        Subdirectorio que contiene enlaces simbólicos a los espacios de tabla
pg_twophase        Subdirectorio que contiene los archivos de estado para las transacciones                                                preparadas
pg_xlog        Subdirectorio que contiene WAL (Escribe Ahead Log) archivos
postgresql.auto.
conf                        Un archivo usado para almacenar parámetros de configuración que se establece                                    por alteraciones en el sistema
postmaster.opts      Un archivo de grabación de las opciones de línea de comando, el servidor se                                          inició por última vez con
postmaster.pid        Un archivo de bloqueo de grabar el ID de proceso del administrador de correo                                      actual (PID), la ruta del directorio de datos del clúster, jefe de correos inicia fecha                                y hora, número de puerto, la ruta del directorio socket de dominio Unix (vacío en                                  Windows), primera listen_address válido (la dirección IP o * o vacía si no se                                        escuchando en TCP), y compartido ID del segmento de memoria (este archivo no                                está presente después de la parada del servidor)


Para cada base de datos en el clúster no es un subdirectorio dentro PGDATA / base , el nombre de la base de datos de OID en pg_database . Este subdirectorio es la
ubicación predeterminada para los archivos de la base de datos; en particular, sus catálogos del sistema se almacenan allí.

Cada tabla y el índice se almacena en un archivo separado. Para las relaciones ordinarias, estos archivos tienen el nombre de la tabla o del índice de filenode
número, que se puede encontrar en pg_class . Relfilenode . Pero para las relaciones temporales, el nombre del archivo es de la forma t acreditación _ FFF , donde la
acreditación es el ID de backend del backend que creó el archivo, y FFF es el número filenode. En cualquiera de los casos, además del archivo principal (a / k / a
tenedor principal), y el índice de cada tabla tiene un mapa del espacio libre (véase  la **Sección 59.3**), que almacena información sobre el espacio libre disponible en
la relación. El mapa de espacio libre se almacena en un archivo denominado con el número filenode más el sufijo _fsm . Las tablas también tienen un mapa de
visibilidad , almacenada en un tenedor con el sufijo _vm , para realizar un seguimiento de las páginas que se sabe que no tiene tuplas muertas. El mapa de visibilidad
se describe adicionalmente en la **Sección 59.4** . Mesas de invitados y los índices tienen tercera tenedor, conocido como el tenedor de inicialización, que se almacena
en un tenedor con el sufijo _init (véase la **Sección 59.5** ).



Precaución
Tenga en cuenta que mientras que filenode de una mesa a menudo coincide con su OID, esto es no necesariamente el caso; algunas operaciones, como TRUNCATE ,
REINDEX , CLUSTER y algunas formas de ALTER TABLE , pueden cambiar el filenode preservando al mismo tiempo el OID. Evitar el supuesto de que filenode y OID tabla
son los mismos. Además, para ciertos catálogos del sistema incluyendo pg_class sí, pg_class . Relfilenode contiene cero. El número filenode real de estos catálogos se
almacena en una estructura de datos de nivel inferior, y se puede obtener utilizando la pg_relation_filenode() función.



Cuando una tabla o un índice superior a 1 GB, que se divide en gigabytes de tamaño segmentos . El nombre de archivo del primer segmento es el mismo que el
filenode; segmentos siguientes se crea filenode.1, filenode.2, etc. Esta disposición evita problemas en plataformas que tienen limitaciones de tamaño de archivo.
(En realidad, 1 GB es sólo el tamaño de segmento por defecto. El tamaño de segmento se puede ajustar mediante la opción de configuración --with-SEGSIZE en la
construcción de PostgreSQL .) En principio, el espacio y el mapa de visibilidad mapa horquillas libres podían requieren múltiples segmentos también, aunque esto es
poco probable que suceda en la práctica.

Una tabla que tiene columnas con potencialmente grandes entradas tendrá un asociado TOSTADA mesa, que se utiliza para el almacenamiento fuera de línea de los
valores de campo que son demasiado grandes para mantenerse en las filas de la tabla apropiada. Pg_class . Reltoastrelid enlaces desde una tabla a su TOSTADA
mesa, si la hay. Vea la **Sección 59.2** para más información.

El contenido de las tablas e índices se discuten en la **Sección 59.6**.

Los espacios de tabla hacen que el escenario más complicado. Cada espacio de tabla definida por el usuario dispone de un enlace simbólico dentro de la PGDATA /
pg_tblspc directorio, que apunta al directorio de tablas física (es decir, la ubicación especificada en el espacio de tabla CREATE TABLESPACE de comandos). Este enlace
simbólico es el nombre de OID del espacio de tabla. Dentro del directorio de tablas física no es un subdirectorio con un nombre que depende de la PostgreSQL
versión del servidor, tales como PG_9.0_201008051 . (La razón de utilizar este subdirectorio es por lo que las versiones sucesivas de la base de datos pueden usar la
misma CREATE TABLESPACE valor de ubicación sin conflictos.) Dentro del subdirectorio específico de la versión, hay un subdirectorio para cada base de datos que tiene
elementos en el espacio de tabla, el nombre de OID de la base de datos. Tablas e índices se almacenan dentro de ese directorio, utilizando el esquema de
nomenclatura filenode. El pg_default espacio de tabla no se accede a través de pg_tblspc , pero corresponde a PGDATA / base . Del mismo modo, el pg_global espacio de
tabla no se accede a través de pg_tblspc , pero corresponde a PGDATA / global.

La pg_relation_filepath()función muestra la ruta completa (en relación con PGDATA ) de cualquier relación. A menudo es útil como un sustituto para recordar muchas de
las reglas anteriores. Pero hay que tener en cuenta que esta función solo da el nombre del primer segmento del tenedor principal de la relación - puede que tenga
que añadir un número de segmento y / o _fsm , _vm , o _init para encontrar todos los archivos asociados con la relación.

Los archivos temporales (para operaciones tales como la clasificación más datos de los que caben en la memoria) se crean dentro de PGDATA / base / pgsql_tmp , o
dentro de un pgsql_tmp subdirectorio de un directorio de tabla si un espacio de tabla que no sea pg_default se especifica para ellos. El nombre de un archivo temporal
tiene la forma pgsql_tmp PPP . NNN , donde PPP es el PID del backend poseer y NNN distingue diferentes archivos temporales de backend.