Postgresql creando un clúster de base de datos

18.2.1. Uso de sistemas de archivos secundarios

18.2.2. Sistemas de archivos

Antes de que pueda hacer algo, debe inicializar un área de almacenamiento de base de datos en el disco. A esto lo llamamos un clúster de base de datos. (El estándar SQL utiliza el término agrupación de catálogo). Una agrupación de bases de datos es una colección de bases de datos administrada por una sola instancia de un servidor de bases de datos en ejecución. Después de la inicialización, un clúster de base de datos contendrá una base de datos denominada postgres, que está pensada como una base de datos predeterminada para que la utilicen las empresas de servicios públicos, los usuarios y las aplicaciones de terceros. El servidor de base de datos en sí no requiere postgres que exista la base de datos, pero muchos programas de utilidad externos asumen que existe. Otra base de datos creada dentro de cada clúster durante la inicialización se llama template1. Como sugiere el nombre, esto se utilizará como plantilla para las bases de datos creadas posteriormente; no debe utilizarse para el trabajo real. (Ver Capítulo 22 para obtener información sobre la creación de nuevas bases de datos dentro de un clúster).

En términos de sistema de archivos, un clúster de base de datos es un directorio único en el que se almacenarán todos los datos. A esto lo llamamos el directorio de datos o área de datos. Depende completamente de usted dónde elija almacenar sus datos. No existe un valor predeterminado, aunque ubicaciones como /usr/local/pgsql/data o /var/lib/pgsql/data son populares. El directorio de datos debe inicializarse antes de ser utilizado, utilizando el programa initdb que se instala con PostgreSQL.

Si está utilizando una versión preempaquetada de PostgreSQL, es posible que tenga una convención específica sobre dónde colocar el directorio de datos, y también puede proporcionar un script para crear el directorio de datos. En ese caso, debe usar ese script en lugar de ejecutar initdb directamente. Consulte la documentación a nivel de paquete para obtener más detalles.

Para inicializar un clúster de base de datos manualmente, ejecute initdb y especifique la ubicación deseada del sistema de archivos del clúster de la base de datos con el -D opción, por ejemplo:

$ initdb -D /usr/local/pgsql/data

Tenga en cuenta que debe ejecutar este comando mientras está conectado a la cuenta de usuario de PostgreSQL, que se describe en la sección anterior.

Propina

Como alternativa al -D opción, puede establecer la variable de entorno PGDATA.

Alternativamente, puede ejecutar initdb a través del programa pg_ctl así:

$ pg_ctl -D /usr/local/pgsql/data initdb

Esto puede resultar más intuitivo si está utilizando pg_ctl para iniciar y detener el servidor (consulte la Sección 18.3), de modo que pg_ctl sería el único comando que usa para administrar la instancia del servidor de base de datos.

initdb intentará crear el directorio que especifique si aún no existe. Por supuesto, esto fallará si initdb no tiene permisos para escribir en el directorio principal. En general, es recomendable que el usuario de PostgreSQL sea propietario no solo del directorio de datos, sino también de su directorio principal, para que esto no sea un problema. Si el directorio principal deseado tampoco existe, deberá crearlo primero, utilizando privilegios de root si el directorio principal no se puede escribir. Entonces, el proceso podría verse así:

root# mkdir /usr/local/pgsql
root# chown postgres /usr/local/pgsql
root# su postgres
postgres$ initdb -D /usr/local/pgsql/data

initdb se negará a ejecutarse si el directorio de datos existe y ya contiene archivos; esto es para evitar sobrescribir accidentalmente 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é protegido contra el acceso no autorizado. initdb por lo tanto, revoca los permisos de acceso de todos menos el usuario de PostgreSQL y, opcionalmente, el grupo. El acceso de grupo, cuando está habilitado, es de solo lectura. Esto permite que un usuario sin privilegios del mismo grupo que el propietario del clúster realice una copia de seguridad de los datos del clúster o realice otras operaciones que solo requieran acceso de lectura.

Tenga en cuenta que habilitar o deshabilitar el acceso de grupo en un clúster existente requiere que el clúster se cierre y que se establezca el modo apropiado en todos los directorios y archivos antes de reiniciar PostgreSQL. De lo contrario, podría existir una combinación de modos en el directorio de datos. Para los clústeres que permiten el acceso solo al propietario, los modos apropiados son 0700 para directorios y 0600 para archivos. Para los clústeres que también permiten lecturas del grupo, los modos apropiados son 0750 para directorios y 0640 para archivos.

Sin embargo, aunque el contenido del directorio es seguro, la configuración de autenticación de cliente predeterminada permite que cualquier usuario local se conecte a la base de datos e incluso se convierta en el superusuario de la base de datos. Si no confía en otros usuarios locales, le recomendamos que utilice uno de initdb‘s -W, --pwprompt o --pwfile opciones para asignar una contraseña al superusuario de la base de datos. Además, especifique -A md5 o -A password para que el defecto trust no se utiliza el modo de autenticación; o modificar el generado pg_hba.conf archivo después de ejecutar initdb, pero antes de inicia el servidor por primera vez. (Otros enfoques razonables incluyen el uso peer permisos de autenticación o del sistema de archivos para restringir las conexiones. Ver Capítulo 20 para más información.)

initdb también inicializa la configuración regional predeterminada para el clúster de la base de datos. Normalmente, solo tomará la configuración regional del entorno y la aplicará a la base de datos inicializada. Es posible especificar una configuración regional diferente para la base de datos; se puede encontrar más información al respecto en la Sección 23.1. El orden de clasificación predeterminado utilizado dentro del clúster de base de datos en particular lo establece initdb, y aunque puede crear nuevas bases de datos utilizando un orden de clasificación diferente, el orden utilizado en las bases de datos de plantilla que crea initdb no se puede cambiar sin eliminarlas y volver a crearlas. También hay un impacto en el rendimiento por usar configuraciones regionales que no sean C o POSIX. Por lo tanto, es importante hacer esta elección correctamente la primera vez.

initdb también establece la codificación del juego de caracteres predeterminado para el clúster de la base de datos. Normalmente, esto debe elegirse para que coincida con la configuración regional. Para obtener más detalles, consulte la Sección 23.3.

No-C y noPOSIX las configuraciones regionales dependen de la biblioteca de intercalación del sistema operativo para ordenar el juego de caracteres. Esto controla el orden de keys almacenado en índices. Por esta razón, un clúster no puede cambiar a una versión de biblioteca de clasificación incompatible, ya sea mediante restauración de instantáneas, replicación de transmisión binaria, un sistema operativo diferente o una actualización del sistema operativo.

18.2.1. Uso de sistemas de archivos secundarios

Muchas instalaciones crean sus grupos de bases de datos en sistemas de archivos (volúmenes) distintos a los de la máquina. “raíz“ volumen. Si elige hacer esto, no es recomendable intentar usar el directorio superior del volumen secundario (punto de montaje) como directorio de datos. La mejor práctica es crear un directorio dentro del directorio de punto de montaje que es propiedad del usuario de PostgreSQL y luego crear el directorio de datos dentro de ese. Esto evita problemas de permisos, particularmente para operaciones como pg_upgrade, y también asegura fallas limpias si el volumen secundario se desconecta.

18.2.2. Sistemas de archivos

Generalmente, cualquier sistema de archivos con semántica POSIX se puede utilizar para PostgreSQL. Los usuarios prefieren diferentes sistemas de archivos por diversas razones, incluido el soporte, el rendimiento y la familiaridad de los proveedores. La experiencia sugiere que, en igualdad de condiciones, no se deben esperar cambios importantes en el rendimiento o el comportamiento simplemente por cambiar de sistema de archivos o realizar cambios menores en la configuración del sistema de archivos.

18.2.2.1. NFS

Es posible utilizar un sistema de archivos NFS para almacenar el directorio de datos de PostgreSQL. PostgreSQL no hace nada especial para los sistemas de archivos NFS, lo que significa que asume que NFS se comporta exactamente como unidades conectadas localmente. PostgreSQL no utiliza ninguna funcionalidad que se sepa que tiene un comportamiento no estándar en NFS, como el bloqueo de archivos.

El único requisito firme para usar NFS con PostgreSQL es que el sistema de archivos se monte usando el hard opción. Con el hard opción, los procesos pueden “colgar“ indefinidamente si hay problemas de red, por lo que esta configuración requerirá una configuración de monitoreo cuidadosa. los soft La opción 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 resultará en un error de E / S.

No es necesario utilizar el sync opción de montaje. El comportamiento del async La opción es suficiente, ya que PostgreSQL emite fsync llamadas en los momentos adecuados para vaciar las cachés de escritura. (Esto es análogo a cómo funciona en un sistema de archivos local). Sin embargo, se recomienda encarecidamente utilizar el sync opción de exportación en el NFS servidor en los sistemas donde existe (principalmente Linux). De lo contrario, un fsync o equivalente en el cliente NFS no está realmente garantizado para alcanzar el almacenamiento permanente en el servidor, lo que podría causar una corrupción similar a la ejecución 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 verificarlos y quizás especificarlos explícitamente en cualquier caso para evitar cualquier ambigüedad.

En algunos casos, se puede acceder a un producto de almacenamiento externo a través de NFS o un protocolo de nivel inferior como iSCSI. En el último caso, el almacenamiento aparece como un dispositivo de bloque y se puede crear cualquier sistema de archivos disponible en él. Ese enfoque podría aliviar al DBA de tener que lidiar con algunas de las idiosincrasias de NFS, pero, por supuesto, la complejidad de administrar el almacenamiento remoto ocurre en otros niveles.