Procedimientos recomendados para pg_dump y pg_restore en Azure Database for PostgreSQL: servidor flexible
SE APLICA A: Azure Database for PostgreSQL con servidor flexible
En este artículo se revisan las opciones y los procedimientos recomendados para acelerar pg_dump y pg_restore. También se explican las mejores configuraciones del servidor para llevar a cabo pg_restore.
Procedimientos recomendados para pg_dump
Puede usar la utilidad pg_dump para extraer una base de datos de servidor flexible de Azure Database for PostgreSQL en un archivo de script o archivo de archivado. En las secciones siguientes se muestran algunas de las opciones de línea de comandos que puede usar para reducir el tiempo de volcado total mediante pg_dump.
Formato de directorio (-Fd)
Esta opción genera un archivo de formato de directorio que puede insertarse en pg_restore. De forma predeterminada, la salida está comprimida.
Trabajos en paralelo (-j)
Con pg_dump, puede ejecutar trabajos de volcado de manera simultánea mediante la opción de trabajos paralelos. Esta opción reduce el tiempo total del volcado, pero también aumenta la carga del servidor de bases de datos. Se recomienda llegar a un valor de trabajo paralelo después de supervisar detenidamente las métricas del servidor de origen, como el uso de CPU, memoria e IOPS (operaciones de entrada y salida por segundo).
Al establecer un valor para la opción de trabajos paralelos, pg_dump requiere lo siguiente:
- El número de conexiones debe ser igual al número de trabajos paralelos +1, así que asegúrese de establecer el valor
max_connections
en consecuencia. - El número de trabajos paralelos debe ser menor o igual que el número de vCPU asignadas al servidor de bases de datos.
Compresión (-Z0)
Esta opción especifica el nivel de compresión que se va a usar. Cero significa que no hay compresión. La compresión cero durante el proceso pg_dump podría ayudar a mejorar el rendimiento.
Sobredimensionamiento y vaciado de tablas
Antes de iniciar el proceso pg_dump, considere si es necesario el vaciado de las tablas. El sobredimensionamiento en las tablas aumenta significativamente los tiempos de pg_dump. Ejecute la consulta siguiente para identificar el sobredimensionamiento de las tablas:
select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;
La columna dead_pct
de esta consulta es el porcentaje de tuplas inactivas en comparación con las tuplas activas. Un valor de dead_pct
alto para una tabla podría apuntar a que la tabla no se vacía correctamente. Para más información, consulte Ajuste del vaciado automático de Azure Database for PostgreSQL: servidor flexible.
Por cada tabla que identifique, puede realizar un análisis de vaciado manual mediante la ejecución de lo siguiente:
vacuum(analyze, verbose) <table_name>
Uso de un servidor de restauración a un momento dado
Puede realizar una proceso pg_dump en un servidor en línea o activo. Las copias de seguridad que se realizan son coherentes incluso si se está usando la base de datos. No se impide que otros usuarios usen la base de datos. Antes de iniciar este proceso, tenga en cuenta el tamaño de la base de datos y otras necesidades empresariales o del cliente. Las bases de datos pequeñas pueden ser buenas candidatas para realizar un proceso pg_dump en el servidor de producción.
En el caso de bases de datos de gran tamaño, puede crear un servidor de recuperación a un momento dado desde el servidor de producción y llevar a cabo en él el proceso pg_dump. La ejecución de pg_dump en un servidor PITR sería un proceso de ejecución en frío. La ventaja de este enfoque es que no es necesario preocuparse por el uso adicional de CPU, memoria y E/S que conlleva un proceso pg_dump que se ejecuta en el servidor de producción real. Puede ejecutar pg_dump en un servidor de recuperación a un momento dado y quitar este una vez completado el proceso.
Sintaxis de pg_dump
Use la sintaxis siguiente para pg_dump:
pg_dump -h <hostname> -U <username> -d <databasename> -Fd -j <Num of parallel jobs> -Z0 -f sampledb_dir_format
Procedimientos recomendados para pg_restore
Puede usar la utilidad pg_restore para restaurar una base de datos de servidor flexible de Azure Database for PostgreSQL a partir de un archivo creado por pg_dump. En las secciones siguientes se muestran algunas opciones de línea de comandos para reducir el tiempo de restauración general.
Restauración en paralelo
Con varios trabajos simultáneos, puede reducir el tiempo de restauración de una base de datos grande en un servidor de destino de varios núcleos virtuales. El número de trabajos puede ser igual o menor que el número de vCPU asignadas al servidor de destino.
Parámetros del servidor
Si va a restaurar datos en un nuevo servidor o en un servidor que no es de producción, puede optimizar los siguientes parámetros de servidor antes de ejecutar pg_restore.
work_mem
= 32 MB
max_wal_size
= 65536 (64 GB)
checkpoint_timeout
= 3600 #60min
maintenance_work_mem
= 2097151 (2 GB)
autovacuum
= desactivado
wal_compression
= activado
Una vez completada la restauración, asegúrese de que todos los parámetros mencionados anteriormente se actualicen correctamente según los requisitos de la carga de trabajo.
Nota
Siga las recomendaciones anteriores solo si hay suficiente memoria y espacio en disco. Si tiene un servidor pequeño con 2, 4 u 8 núcleos virtuales, establezca los parámetros en consecuencia.
Otras consideraciones
- Antes de ejecutar pg_restore, deshabilite la alta disponibilidad [HA].
- Una vez completada la restauración, analice todas las tablas que se migran.
Sintaxis de pg_restore
Use la sintaxis siguiente para pg_restore:
pg_restore -h <hostname> -U <username> -d <db name> -Fd -j <NUM> -C <dump directory>
-Fd
: el formato de directorio.-j
: el número de trabajos.-C
: comience la salida con un comando para crear la propia base de datos y volver a ella.
Este es un ejemplo de cómo puede ser esta sintaxis:
pg_restore -h <hostname> -U <username> -j <Num of parallel jobs> -Fd -C -d <databasename> sampledb_dir_format
Consideraciones para varias máquinas
Cree una máquina virtual en la misma región y zona de disponibilidad, preferiblemente donde tenga los servidores de origen y destino. O bien, como mínimo, cree la máquina virtual lo más cerca posible al servidor de origen o a un servidor de destino. Se recomienda usar Azure Virtual Machines con un SSD local de alto rendimiento.
Para más información sobre las SKU, consulte: