Antes de poder hacer nada, debes inicializar un área de almacenamiento de
base de datos en el disco. A esto lo llamamos un clúster de bases de datos.
(El estándar SQL usa el término clúster de catálogos). Un
clúster de bases de datos es una colección de bases de datos que es gestionada por una
sola instancia de un servidor de bases de datos en ejecución. Después de la inicialización,
un clúster de bases de datos contendrá una base de datos llamada postgres,
la cual está pensada como una base de datos predeterminada para el uso por utilidades, usuarios y
aplicaciones de terceros. El servidor de bases de datos en sí mismo no requiere que la
base de datos postgres exista, pero muchos programas de utilidad externos asumen que existe.
Hay dos bases de datos más creadas dentro de cada clúster durante la inicialización, llamadas template1
y template0. Como sugieren los nombres, estas serán
utilizadas como plantillas para las bases de datos creadas posteriormente; no deben ser
utilizadas para trabajo real. (Ver Chapter 22 para
información sobre cómo crear nuevas bases de datos dentro de un clúster).
En términos del sistema de archivos, un clúster de bases de datos es un único directorio
bajo el cual se almacenarán todos los datos. Llamamos a esto el directorio de datos
o área de datos. Depende completamente de ti dónde decidas almacenar
tus datos. No hay un valor por defecto, aunque ubicaciones como
/usr/local/pgsql/data o
/var/lib/pgsql/data son populares.
El directorio de datos debe ser inicializado antes de ser usado, usando el programa
initdb
que se instala con PostgreSQL.
Si estás usando una versión preempaquetada
de PostgreSQL, bien podría tener una convención específica
para dónde colocar el directorio de datos, y también puede
proporcionar un script para crear el directorio de datos. En ese caso
deberías usar ese script con preferencia a
ejecutar initdb directamente.
Consulta la documentación del paquete para los detalles.
Para inicializar un clúster de bases de datos manualmente,
ejecuta initdb y especifica la ubicación deseada en el
sistema de archivos del clúster de bases de datos con la
opción -D, por ejemplo:
$initdb -D /usr/local/pgsql/data
Ten en cuenta que debes ejecutar este comando mientras inicias sesión en la cuenta de usuario de PostgreSQL, la cual es descrita en la sección anterior.
Alternativamente, puedes ejecutar initdb vía
el programa pg_ctl
así:
$pg_ctl -D /usr/local/pgsql/data initdb
Esto puede ser más intuitivo si estás
usando pg_ctl para iniciar y detener el
servidor (ver Section 18.3), de modo
que pg_ctl sería el único comando que usas
para gestionar la instancia del servidor de bases de datos.
initdb intentará crear el directorio que
especifiques si no existe ya. Por supuesto, esto fallará si
initdb no tiene permisos para escribir en el
directorio padre. Es generalmente recomendable que el usuario de
PostgreSQL sea propietario no solo del directorio de datos
sino también de su directorio padre, para que esto no sea un problema. Si el
directorio padre deseado tampoco existe, necesitarás crearlo primero,
usando privilegios de root si el directorio abuelo no es escribible. Así que el proceso
podría verse así:
root#mkdir /usr/local/pgsqlroot#chown postgres /usr/local/pgsqlroot#su postgrespostgres$initdb -D /usr/local/pgsql/data
initdb se negará a correr si el directorio de datos
existe y ya contiene archivos; esto es para evitar accidentalmente
sobrescribir una instalación existente.
Debido a que el directorio de datos contiene todos los datos almacenados en la
base de datos, es esencial que esté asegurado contra el acceso no autorizado.
initdb por lo tanto revoca los permisos de acceso
a todos menos al usuario de PostgreSQL, y opcionalmente, al grupo.
El acceso de grupo, cuando está habilitado, es de solo lectura. Esto permite a un usuario
sin privilegios en el mismo grupo que el propietario del clúster tomar una copia de seguridad de
los datos del clúster o realizar otras operaciones que solo requieren acceso de lectura.
Ten en cuenta que habilitar o deshabilitar el acceso de grupo en un clúster existente requiere
que el clúster sea apagado y el modo apropiado sea establecido en todos
los directorios y archivos antes de reiniciar
PostgreSQL. De lo contrario, una mezcla de modos podría
existir en el directorio de datos. Para los clústeres que permiten acceso solo por el
propietario, los modos apropiados son 0700 para directorios
y 0600 para archivos. Para los clústeres que también permiten
lecturas por el grupo, los modos apropiados son 0750
para directorios y 0640 para archivos.
Sin embargo, aunque los contenidos del directorio son seguros, la configuración predeterminada de
autenticación de clientes permite a cualquier usuario local conectarse a la
base de datos e incluso convertirse en el superusuario de la base de datos. Si no
confías en otros usuarios locales, recomendamos que uses una de las opciones
-W, --pwprompt o --pwfile de
initdb para asignar una contraseña al
superusuario de la base de datos.
Además, especifica -A scram-sha-256
para que el modo de autenticación predeterminado trust
no sea usado; o modifica el archivo pg_hba.conf generado
después de correr initdb, pero
antes de que inicies el servidor por primera vez. (Otros
enfoques razonables incluyen el uso de autenticación peer
o permisos del sistema de archivos para restringir conexiones. Ver Chapter 20 para más información.)
initdb también inicializa la configuración regional
predeterminada (locale) para el clúster de la base de datos.
Normalmente, solo tomará la configuración regional en el entorno
y la aplicará a la base de datos inicializada. Es posible
especificar una configuración regional diferente para la base de datos; más información sobre
eso se puede encontrar en Section 23.1. El orden de clasificación predeterminado usado
dentro del clúster de base de datos particular es establecido por
initdb, y aunque puedes crear nuevas bases de datos usando
un orden de clasificación diferente, el orden usado en las bases de datos de plantilla que initdb
crea no puede ser cambiado sin borrarlas y recrearlas.
También hay un impacto en el rendimiento por usar configuraciones regionales
distintas a C o POSIX. Por lo tanto, es
importante tomar esta decisión correctamente la primera vez.
initdb también establece la codificación de caracteres predeterminada
para el clúster de la base de datos. Normalmente esto debería ser elegido para que coincida con
la configuración regional. Para detalles ver Section 23.3.
Las configuraciones regionales no C y no POSIX dependen de la
biblioteca de ordenación del sistema operativo para el orden de los juegos de caracteres.
Esto controla el orden de las claves almacenadas en los índices. Por esta razón,
un clúster no puede cambiar a una versión de biblioteca de ordenación incompatible,
ya sea a través de restauración de instantánea, replicación binaria por streaming, un
sistema operativo diferente, o una actualización del sistema operativo.
Muchas instalaciones crean sus clústeres de base de datos en sistemas de archivos (volúmenes) distintos al volumen “root” de la máquina. Si eliges hacer esto, no es recomendable intentar usar el directorio superior (punto de montaje) del volumen secundario como directorio de datos. La mejor práctica es crear un directorio dentro del directorio de punto de montaje que sea propiedad del usuario de PostgreSQL, y luego crear el directorio de datos dentro de eso. Esto evita problemas de permisos, particularmente para operaciones tales como pg_upgrade, y también asegura fallos limpios si el volumen secundario es desconectado.
Generalmente, cualquier sistema de archivos con semántica POSIX puede ser usado para PostgreSQL. Los usuarios prefieren diferentes sistemas de archivos por una variedad de razones, incluyendo soporte del proveedor, rendimiento y familiaridad. La experiencia sugiere que, todas las demás cosas siendo iguales, uno no debería esperar grandes cambios de rendimiento o comportamiento simplemente por cambiar sistemas de archivos o hacer cambios menores en la configuración del sistema de archivos.
Es posible usar un sistema de archivos NFS para almacenar el directorio de datos de PostgreSQL. PostgreSQL no hace nada especial para sistemas de archivos NFS, lo que significa que asume que NFS se comporta exactamente igual que las unidades conectadas localmente. PostgreSQL no usa ninguna funcionalidad que se sepa que tiene comportamiento no estándar en NFS, tal como bloqueo de archivos.
El único requisito firme para usar NFS con
PostgreSQL es que el sistema de archivos esté montado
usando la opción hard. Con la
opción hard, los procesos pueden “colgarse”
indefinidamente si hay problemas de red, por lo que esta configuración
requerirá una configuración de monitoreo cuidadosa. La opción soft
interrumpirá las llamadas al sistema en caso de problemas de red, pero
PostgreSQL no repetirá las llamadas al sistema
interrumpidas de esta manera, por lo que cualquier interrupción de este tipo resultará en
un error de E/S siendo reportado.
No es necesario usar la opción de montaje sync. La
comportamiento de la opción async es suficiente, ya que
PostgreSQL emite llamadas fsync
en los momentos apropiados para vaciar las cachés de escritura. (Esto es análogo
a cómo funciona en un sistema de archivos local). Sin embargo, es fuertemente
recomendado usar la opción de exportación sync en el NFS
servidor en sistemas donde exista (principalmente Linux).
De lo contrario, un fsync o equivalente en el cliente NFS
no está realmente garantizado que llegue al almacenamiento permanente en el servidor, lo cual
podría causar corrupción similar a ejecutar con el parámetro fsync desactivado. Los valores predeterminados de estas opciones de montaje y exportación
difieren entre proveedores y versiones, por lo que se recomienda
revisar y quizás especificarlos explícitamente en cualquier caso para evitar cualquier
ambigüedad.
En algunos casos, un producto de almacenamiento externo puede ser accedido ya sea vía NFS o un protocolo de nivel inferior tal como iSCSI. En el último caso, el almacenamiento aparece como un dispositivo de bloque y cualquier sistema de archivos disponible puede ser creado en él. Ese enfoque podría liberar al DBA de tener que lidiar con algunas de las idiosincrasias de NFS, pero por supuesto la complejidad de gestionar almacenamiento remoto ocurre entonces en otros niveles.