Un cliente necesitaba actualizar su Aurora RDS Postgres de v13 a v16 debido al EOL de v13. Este es un requisito común y, hasta ahora, un proceso directo.
La complejidad surgió cuando necesitaron actualizar su modelo de aplicación, lo cual estaba tomando mucho tiempo debido a que la mayoría de las tablas requerían una reescritura completa.
La migración de Django estaba tomando varias horas en ejecutarse, lo que hacía inviable una actualización blue/green y la posterior ejecución de la migración debido al largo tiempo de inactividad que causaría.
Aunque no está documentado en la documentación oficial, es posible evitar almacenar archivos en configuraciones de PGBackRest. En ciertos escenarios, puedes querer ignorar el almacenamiento de archivos para reducir costos, especialmente si estás usando almacenamiento en la nube para tus backups.
Esas situaciones podrían ser:
Entornos de pruebas, ya sea que ejecutes pruebas intensivas pero no necesitas o te importa PITR (Point in Time Recovery).
Bases de datos Postgres altamente actualizadas, donde puedes recuperar cambios por otros medios, como scraping o restaurando desde fuentes externas.
⚠️
No almacenar archivos puede llevarte a pérdida de datos si no tienes una estrategia adecuada para manejar los deltas.
Todavía necesitas almacenar archivos durante la ejecución del backup si quieres backups online. De lo contrario, no serán recuperables.
Si no quieres almacenar archivos en absoluto, necesitas ejecutar el backup offline. Es decir, deteniendo tu instancia y ejecutando pgbackrest backup.
A partir de hoy, PGCat soporta 2 mecanismos de sharding a través de sintaxis extendida:
Estableciendo el shard explícitamente: SET SHARD TO '<index>';, lo que te permite hacer sharding determinístico, ya sea que elijas
tu shard de acuerdo a una regla, como una búsqueda, región, grupo de clientes, etc.
Esto es genial si tienes uno de esos bien delimitados o una distribución uniforme. Pero, sigue siendo un buen enfoque y algo escalable.
No nos enfocaremos en esta estrategia en este post, ya que su implementación depende de requisitos personalizados.
Estableciendo sharding_function para usar una de las funciones disponibles: pg_bigint_hash y sha1. La sintaxis extendida SET SHARDING KEY TO '<value>'; calculará el índice. No está muy claro en la documentación cómo se usa la función sha1, así que este post se enfocará en el caso de pg_bigint_hash.
Shard por hash es una estrategia audaz, particularmente si esperas tener una carga de trabajo grande, y necesitas tener suficiente cómputo en todos los shards.
Esta sintaxis extendida se puede hacer a través de comentarios, consulta la documentación de Sharding de pgcat.
En este laboratorio, nos enfocaremos en la función pg_bigint_hash. No está claro en la documentación de PGCat cómo debería implementarse sha1, pero extenderé el laboratorio para cubrirlo – eso es, si supero mis problemas de habilidad :P .
En este punto, puedes estar consciente de las complejidades de implementar sharding, y qué limitaciones esperamos del enfoque de hashing.
Ten en cuenta que esta característica de PGCat está vinculada a la partición de Postgres, basada en la misma HASH_PARTITION_SEED.
Consulta también pgcat hash seed.
ℹ️
El laboratorio para este post se puede encontrar en babelfishpg-lab.
⚠️
En este post cubrimos la versión 4.2.0. Hay una ligera diferencia en la configuración y formato de logging desde 4.1.1.
Aunque BabelfishPG es una variante de Postgres, la configuración se hace a través de sus extensiones (babelfish_tds y babelfish_tsql). En este post, nos enfocamos en cómo registrar tiempos de consulta y habilitar mostrar planes de consulta.
En la documentación de pgbouncer se establece que el query_timeout debería configurarse ligeramente
más alto que el statement_timeout de Postgres. Aunque esto aplica en la mayoría de los casos, depende
de los requisitos del negocio.
Generalmente, el statement_timeout debería configurarse al percentil 99 de la duración de tus statements.
Sin embargo, hay casos donde ciertos statements requieren timeouts más largos, debido a particularidades como
un conjunto grande de clientes, o campos más grandes, como en casos de compresión TOAST.
Algunas cosas pasan una vez en la vida, y la historia alrededor de esto es bastante particular.
Un cliente requirió algo que al principio sonaba contraintuitivo: migrar una base de datos Postgres existente a BabelfishPG.
La cosa era que la aplicación era un núcleo crítico del negocio, con una gran cantidad de código que requeriría años para migrar completamente para soportar otra estrategia de almacenamiento. Pero la razón real era que su cliente no quería apegarse a ningún modelo de licenciamiento privado, y requería usar soluciones Open Source.
El siguiente post cubrirá pruebas de rendimiento usando tdspool.
Arquitectura de conexión de BabelfishPG
Heredada de la arquitectura de conexión de Postgres, cada conexión a través del puerto TDS instanciará un backend de Postgres. Como en Postgres, BabelfishPG necesita un middleware para canalizar
conexiones a través del puerto TDS para evitar quedarse sin conexiones y capacidad de procesamiento
en el servidor de base de datos.
Para Postgres, tenemos muchas opciones, como PGBouncer, Odyssey, pgcat, nómbralo.
Para T-SQL (léase como lenguaje compatible con MSSQL), no hay muchas soluciones de código abierto.
