Tenemos una base de datos Postgres de volumen relativamente bajo con archivado continuo configurado para comprimir cada segmento WAL y enviarlo a S3. Debido a que es un sistema de bajo volumen, alcanza archive_timeout
aproximadamente cada 10 minutos y archiva el segmento WAL en su mayoría no utilizado, que solía comprimir muy bien, ya que en su mayoría solo eran ceros.
Sin embargo, Postgres recicla sus segmentos WAL para evitar el costo de asignar nuevos archivos en cada conmutador WAL, lo cual es útil en una situación de alta carga, pero significa que después de una explosión de actividad más pesada de lo normal, nuestros archivos de segmentos WAL ahora están llenos de basura de segmentos anteriores y no se comprimen muy bien en absoluto. Estamos almacenando muchas copias de toda esta basura.
¿Hay alguna manera de reducir la cantidad de espacio que estamos usando para mantener nuestro archivo WAL? Algunas posibilidades subóptimas:
Evite que Postgres recicle los segmentos WAL de alguna manera, por lo que comienza con un archivo a cero cada vez. Los documentos no indican que hay una opción para hacer esto, pero podría haberla perdido.
Haga que Postgres ponga a cero el archivo del segmento WAL cuando comience / termine de usarlo. Una vez más, los documentos no parecen sugerir que esto sea posible.
Externamente cero o elimine algunos de los archivos del segmento WAL mientras no están en uso. ¿Hay alguna forma segura de determinar qué archivos es este?
Ponga a cero la parte no utilizada del segmento antes de archivarlo utilizando la salida de
pg_xlogdump
para encontrar dónde comienza la basura. Posible, aunque no me gusta. Al menos haciendo esto en el comando de archivo puede estar seguro de que Postgres no va a reutilizar el archivo.Solo archive la parte utilizada del archivo de segmento, nuevamente interpretando la salida de
pg_xlogdump
alguna manera, y luego rellene con ceros durante la restauración. También suena posible, aunque realmente no me gusta.
fuente
Respuestas:
A partir de la versión 9.4, ahora pone a cero automáticamente el final del archivo WAL. (En realidad, es principalmente cero, hay algunos encabezados de bloque que no se ponen a cero, pero aún así el resultado es muy compresible).
En la versión 9.2, hay un programa llamado
pg_clearxlogtail
que puede usar. Puede agregarlo a su archivo_comando antes del paso de compresión.Si está utilizando 9.3, no tiene suerte.
Tenga en cuenta que los puntos de control no causan inherentemente cambios en el archivo de registro. Probablemente sea archive_timeout lo que está causando los cambios.
fuente
archive_timeout
que causa los cambios. Corregido el OP, gracias.