Ediciones ENI Editorial | líder en informática
Explotación
Ejecución de una instancia
Una instancia de PostgreSQL se corresponde con la ejecución de un proceso postgres. Este proceso recibe las conexiones de los clientes y abre un nuevo proceso postgres para cada conexión exitosa. Otros procesos postgres para diferentes tareas se lanzan durante el arranque por el proceso padre: un proceso durante la carga de la escritura de los datos y otro para la recuperación de las estadísticas, como en el resultado del siguiente comando ps:
$ ps fx
32460 ? S 0:01 /usr/lib/postgresql/10/bin/postgres -D
/var/lib/postgresql/10/main -c
config_file=/etc/postgresql/10/main/postgresql.conf
32462 ? Ss 0:00 \_ postgres: 10/main: checkpointer process
32463 ? Ss 0:00 \_ postgres: 10/main: writer process
32464 ? Ss 0:00 \_ postgres: 10/main: wal writer process
32465 ? Ss 0:01 \_ postgres: 10/main: autovacuum launcher process
32466 ? Ss 0:01 \_ postgres: 10/main: stats collector process
32467 ? Ss 0:00 \_ postgres: 10/main: bgworker: logical
replication launcher
2891 ? ...Administración del servidor
1. Configuración
El archivo de configuración propio de cada instancia de PostgreSQL se llama postgresql.conf y se sitúa generalmente en el directorio inicializado con la instancia, correspondiente a la opción -D del comando initdb. En los casos de los sistemas Debian, se sitúa en el directorio /etc/postgresql/, seguido de la versión principal de PostgreSQL y del nombre de la instancia elegida.
El archivo postgresql.conf puede contener las directivas include e include_dir, que pueden hacer referencia a otros archivos que contienen diversas directivas. Por defecto, estas dos directivas no se utilizan.
El archivo postgresql.auto.conf siempre se ubica en el directorio de los datos y contiene los argumentos modificados por el comando ALTER SYSTEM. Este archivo siempre se lee en último lugar, lo que hace que los argumentos presentes sobrecarguen los mismos argumentos presentes en el resto de los archivos de configuración.
Estos archivos se parecen a las directivas de configuración, que permiten adaptar el comportamiento del servidor al hardware sobre el que funciona, así como a las bases de datos utilizadas. Una vez que el servidor arranca, algunas de estas directivas se pueden sobrecargar con el comando SET o asociándolas a una base de datos o a un rol, con los comandos ALTER respectivos. Las directivas se pueden definir durante el arranque o durante la ejecución del servidor o bien con una sencilla recarga del archivo de configuración.
Las directivas que indican un valor de tamaño de memoria o de duración se pueden expresar utilizando una unidad, lo que simplifica la escritura y relectura del archivo de configuración.
Las unidades de tamaño son: KB, MB, GB. Las unidades de tiempo son: ms, s, min, h, d.
Los argumentos de configuración están dotados de valores por defecto, que se pueden revisar sobre todo en función del hardware realmente utilizado.
Cuando se añaden modificaciones al archivo de configuración, no se tienen en cuenta sin intervención del administrador. Es necesario que la instancia PostgreSQL vuelva a leer el archivo y algunas directivas necesitan un rearranque completo de la instancia, lo que implica una parada de las sesiones actuales y, por lo tanto, un corte de servicios. Cada argumento se puede modificar en un contexto concreto....
Administrador de conexiones
El administrador de conexiones trabaja entre las aplicaciones cliente y servidor de las bases de datos. Su principal tarea es gestionar la apertura de las conexiones al servidor de bases de datos, en lugar de las aplicaciones cliente. Esta administración va a mantener las conexiones abiertas en el servidor de bases de datos y permitir a las aplicaciones cliente reutilizarlas más fácilmente. De hecho, esta administración de un conjunto de conexiones permite ahorrar tiempo de apertura de una conexión al servidor de bases de datos y por lo tanto ahorrar recursos. En efecto, la apertura de una conexión en PostgreSQL implica la creación de un nuevo proceso, que es una operación costosa. Este ahorro de recursos, y en consecuencia de tiempo, permite un mejor escalado de las aplicaciones que utilizan un servidor de bases de datos PostgreSQL.
El administrador de conexiones se puede ejecutar en un sistema independiente de aquel en el que funciona el servidor de bases de datos. No existe regla, sino que la elección se hace en función de la topología existente entre las aplicaciones cliente y los servidores de bases de datos y en función de la resiliencia deseada del conjunto. Por ejemplo, si queremos que el administrador de bases de datos participe en los mecanismos de alta disponibilidad de la aplicación, es oportuno no ejecutarlo en el mismo sistema que el servidor de bases de datos, sino quizás en el sistema donde funcionan las aplicaciones cliente.
De hecho, algunos servidores de aplicaciones integran un administrador de conexiones, como J2E o Node.js, lo que hace inútil la adopción de una herramienta. A la inversa, los lenguajes como PHP no integran esta funcionalidad, por lo que se benefician de estas herramientas.
1. Pgpool
El administrador de conexiones Pgpool es una herramienta externa a PostgreSQL. No se proporciona por el grupo PostgreSQL, pero forma parte de los proyectos del ecosistema PostgreSQL.
El rol de Pgpool es insertarse entre el software cliente y los servidores PostgreSQL para reagrupar las conexiones, optimizando de esta manera el número de conexiones abiertas sobre un servidor PostgreSQL. Un cliente puede conectarse directamente a Pgpool exactamente como si se conectara a un servidor PostgreSQL. El software Pgpool conserva las conexiones abiertas, optimizando de esta manera el tiempo de apertura...
Copia de seguridad y restauración
Existen dos métodos de copia de seguridad de los datos con PostgreSQL. La primera es la copia de seguridad lógica. Se centra en el nivel de los objetos contenidos en la base de datos y, por lo tanto, el resultado consiste en un conjunto de instrucciones que permiten reconstruir los objetos y los datos. La segunda es la copia de seguridad física, que se situa en el nivel de los archivos, ignorando completamente el sentido de los datos contenidos, pero que permite una gran finura de restauración, en términos de evolución en el tiempo.
1. Copia de seguridad lógica con pg_dump y pg_dumpall
Las estrategias de copia de seguridad en caliente de las bases de datos obligatoriamente deben tener en cuenta la restauración de estos datos.
Existen dos herramientas para que la copia de seguridad lógica en caliente tenga éxito, cada una con sus particularidades y sus opciones. La elección de la herramienta correcta y las opciones correctas determinan la cualidad y la rapidez de la restauración. Por lo tanto, es importante haber planificado las copias de seguridad correctas, con los formatos correctos y conocer al avance de los métodos de restauración adaptados.
a. pg_dump
pg_dump es una herramienta en línea de comandos entregada con PostgreSQL y por lo tanto disponible con todas las versiones del servidor. Es la herramienta más completa y flexible para realizar las copias de seguridad lógicas. La unidad de copia de seguridad normalmente es la base de datos, pero es posible hacer copia de seguridad solo de un esquema, incluso de una única tabla.
La herramienta propone varios formatos de copia de seguridad. Cada una tiene sus ventajas y sus inconvenientes. El formato más clásico es el formato de texto, que, de hecho, es un archivo de comandos SQL que permite recrear los objetos e insertar los datos con consultas SQL clásicas. La ventaja de este formato es una gran flexibilidad para la restauración de los datos durante un cambio de versión de PostgreSQL o, por ejemplo, para utilizar estos datos en otros servidores SGBD. Los formatos binarios, específicos de PostgreSQL, ofrecen más flexibilidad, principalmente durante la inserción de los datos. La elección del formato determina el método de restauración: el formato texto se puede...
Explotación y tareas de mantenimiento
Una vez instalada la base de datos y conectadas las aplicaciones, es necesario seguir la actividad de la instancia. En efecto, una base de datos evoluciona a lo largo del tiempo, principalmente con las inserciones de datos, las actualizaciones y las eliminaciones de datos.
Es necesario comprender su funcionamiento y actuar en consecuencia.
1. Análisis de una consulta con EXPLAIN
El comando EXPLAIN permite estudiar el comportamiento de una consulta y principalmente los diferentes métodos utilizados por PostgreSQL para acceder a los datos.
El plan de ejecución detalla el recorrido de las tablas y, por ejemplo, permite entender dónde añadir un índice en una tabla. También muestra los algoritmos utilizados para los joins y los costes estimados de ejecución, expresados en unidades de recuperación sobre las páginas en disco.
La opción ANALYZE ejecuta realmente la consulta y añade el tiempo real de ejecución y el número real de registros devueltos.
La sinopsis del comando es la siguiente:
EXPLAIN <opciones> consulta; donde <opciones> puede ser:
( ANALYZE <booleano>, BUFFERS <booleano>, COSTS <booleano>,
TIMING <booleano>,FORMAT { TEXT | XML | JSON | YAML } ) -
ANALYZE ejecuta realmente la consulta y recoge la información de ejecución.
-
BUFFERS añade la información de la memoria RAM de datos utilizada.
-
COSTS, visualizada por defecto, muestra la estimación de los costes.
-
TIMING muestra los cronómetros de la ejecución.
A continuación se muestra, por ejemplo, una sencilla consulta de lectura con un filtro sobre la clave primaria de la tabla prestaciones. Aquí, la tabla tiene muy pocas tuplas. Por lo tanto, el planificador de consultas no juzga necesario utilizar el índice de la clave primaria y realiza una lectura secuencial de la tabla:
clientes=# EXPLAIN SELECT * FROM prestaciones
where prest_id = 32;
QUERY PLAN
——————————————————————————————
Seq Scan on prestaciones (cost=0.00..1.38...Probar la instalación con pgbench
La herramienta pgbench, que se entrega en las contribuciones de PostgreSQL, permite probar una instalación evaluando un número de transacciones por segundo. Esto permite medir las mejoras aportadas por un cambio en la configuración.
Utiliza una base de datos, en la que crea las tablas y las rellena con datos, cuya cantidad se indica en la inicialización. Después, durante la fase de pruebas, pgbench envía las transacciones y cuenta el número de transacciones por segundo en función de diferentes argumentos, como el número de conexiones o el número de transacciones actuales.
Las pruebas se pueden desarrollar en una base de datos dedicada, llamada pgbench, creada con el siguiente comando:
[postgres] $ createdb pgbench Después, el siguiente comando permite inicializar la base para las pruebas:
[postgres] $ pgbench -i -s 10 pgbench La opción -i activa la inicialización y la opción -s es un factor multiplicador que permite insertar más datos, aquí con un factor 10.
A continuación, se pueden lanzar las pruebas con el siguiente comando:
[postgres] $ pgbench -c 10 -t 30 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 10
number of clients: 10
number of transaction per client: 30
number of transaction actually processed:...Explotación de las trazas de actividad con pgBadger
El software pgBadger es un script Perl que permite analizar el contenido de los archivos de trazas de actividad para extraer los datos estadísticos. Esto sirve para evaluar el comportamiento de PostgreSQL, por ejemplo el número de sentencias de inserción o actualización.
1. Instalación
La herramienta se empaqueta en diferentes distribuciones GNU/Linux, pero se puede instalar siguiendo las instrucciones indicadas en su documentación, en la siguiente dirección: http://dalibo.github.io/pgbadger/
El procedimiento de instalación es extremadamente sencillo y solo necesita el comando perl, que ya está presente en un sistema GNU/Linux:
$ tar xf pgbadger-6.2.tar.gz
$ cd pgbadger-6.2
$ perl Makefile.PL
$ make && sudo make install 2. Análisis de los archivos de trazas
El archivo de trazas de actividad contiene un determinado número de información, según los ajustes realizados. La herramienta pgBadger puede entender el formato de los archivos de trazas y, por lo tanto, es sencillo de manipular, incluso si el tiempo de análisis de los archivos de trazas puede ser largo y consumir los recursos de la máquina en la que se ejecuta el análisis.
El siguiente comando permite lanzar el análisis y generar un archivo HTML que contiene el informe:
pgbadger /var/log/postgresql/postgresql-9.4-main.log...