El equipo de Postgres.ai se complace en anunciar el lanzamiento de la versión 3.0 de Database Lab Engine (DLE). Se trata del más avanzado software de código abierto jamás lanzado que potencia los entornos de desarrollo, pruebas y resolución de problemas para proyectos de rápido crecimiento. Database Lab Engine 3.0 ofrece a las empresas una ventaja en términos de competitividad, gracias a la aplicación del enfoque «Shift-left testing» en el desarrollo de software.

Database Lab Engine es una tecnología de código abierto que permite la creación de clones de tamaño reducido. Este tipo de clones son excepcionalmente útiles cuando se necesita escalar el proceso de desarrollo. DLE puede gestionar en una sola máquina docenas de clones independientes de una base de datos, permitiendo a cada ingeniero o proceso de automatización trabajar con su propia base de datos aprovisionada en cuestión de segundos y sin costes adicionales.

Entre los principales cambios de DLE 3.0 figuran:

• UI (interfaz de usuario) incluida en el core, permite trabajar con una sola instancia de DLE,
• clones persistentes: los clones ahora se conservan tras el reinicio de DLE (o VM),
• modo de aprovisionamiento de datos «lógico»: posibilidad de cambiar el estado del clon restablecido utilizando una instantánea de un pool o conjunto de datos diferente,
• mejor registro y simplicidad de configuración,
• mejoras para los casos en los que se ejecutan varios DLE en una misma máquina,
• Soporte para PostgreSQL 14.

A partir de la versión 3.0.0, DLE recoge datos telemétricos que no suponen la identificación del usuario. Aunque esta característica está activada por defecto, es posible desactivarla. Para más información, consulten la documentación de DLE. Mantener la telemetría activada puede considerarse una contribución al desarrollo de DLE, puesto que ayuda a tomar decisiones relacionadas con el desarrollo del producto de código abierto.

A continuación, mencionaremos los cambios más solicitados implementados en DLE 3.0, basados en la experiencia real de los usuarios y en los valiosos comentarios de la creciente comunidad de usuarios y contribuidores.

Cabe destacar

• ¿Les gusta Database Lab? Dennos una estrella de GitHub: https://github.com/postgres-ai/database-lab.
• Acción necesaria para migrar desde una versión anterior. Si están ejecutando DLE 2.5 o versiones anteriores, lean detenidamente y apliquen lo indicado en las notas para la migración.
• Para obtener ayuda, contáctense con el equipo de Postgres.ai y con la creciente comunidad de usuarios y contribuidores de Database Lab: https://postgres.ai/contact.

DLE UI: clonar en segundos y directamente en el navegador bases de datos de gran tamaño

Al ser un software de código abierto, DLE siempre ha estado dotado de API y CLI. En cuanto a la UI, al principio estaba disponible únicamente en forma de SaaS – Database Lab Platform que se ejecutaba en Postgres.ai.

En respuesta a las numerosas peticiones de los usuarios de DLE, la UI ha sido integrada en el core de DLE 3.0. Este cambio hace que este software de código abierto sea aún más atractivo para los usuarios, ya que ofrece una mayor facilidad de uso y simplifica la adopción por parte de empresas en rápido crecimiento.

Vean un breve vídeo explicativo sobre la UI de DLE.

Algunos usuarios han comentado que, al contar con una UI, es mucho más fácil explicar a sus colegas varios casos de uso en los que DLE puede resultar muy útil. Si les gusta Database Lab, por favor, aprovechen este cambio: utilicen la UI, demuestren a los demás cómo clonar bases de datos de gran tamaño en pocos segundos, y comenten cómo puede influir en su desarrollo de software, en los procesos de prueba, así como en la resolución de problemas y en la optimización de SQL.

Clones persistentes: seguir trabajando con clones de bases de datos Postgres durante el mantenimiento

Otra característica añadida a DLE 3.0 también ha sido muy solicitada por los usuarios de DLE. Antes de la versión 3.0, cualquier reinicio de DLE suponía la pérdida de todos los clones creados. Esto hacía que las actualizaciones de DLE, los reinicios de máquinas virtuales e incluso la simple reconfiguración de DLE necesitaran contar siempre con una ventana de mantenimiento, la cual interrumpía el trabajo.

Una solución parcial a este problema era la posibilidad de reconfigurar DLE sin reinicios, introducida en DLE 2.0. Sin embargo, esta opción no resultaba útil en caso de actualización de DLE o de reinicio de la máquina virtual. Ahora, con DLE 3.0, este problema queda totalmente resuelto:

• Si se está ejecutando DLE 2.5 o una versión anterior, es necesario planificar una última ventana de mantenimiento para realizar actualizaciones. Todas las actualizaciones posteriores mantendrán los clones existentes.
• En caso de falla de la VM (lo cual no es infrecuente en los entornos en la nube), tras su recuperación, los clones serán recreados, preservando el estado de la base de datos.

Por supuesto, en caso de reinicio de la VM, las conexiones a la base de datos se perderán y tendrán que ser recreadas. Sin embargo, si es necesario reiniciar solamente DLE, todos los contenedores clonados seguirán funcionando y los usuarios podrán seguir utilizándolos incluso durante el reinicio de DLE, sin ninguna interrupción del trabajo.

Restablecer de forma avanzada en modo «lógico»

En DLE 2.5, se implementó la capacidad de restablecer a cualquier instantánea disponible: una manera conveniente para que los clones viajen rápidamente en el tiempo. No obstante, en la versión 2.5, esta opción sólo se admitía para el modo de aprovisionamiento «físico» (restaurando el directorio de datos, PGDATA, desde respaldos físicos, u obteniéndolo de la fuente mediante pg_basebackup). En otras palabras, sólo podía funcionar si el usuario administraba Postgres por sí mismo y podía copiar PGDATA o establecer una conexión de replicación física con sus bases de datos. Algo que no está disponible para los usuarios de RDS y otros servicios Postgres gestionados.

Para ejecutar DLE en el modo de aprovisionamiento de datos «lógico» (basado en el volcado/restauración – la única opción para la mayoría de las ofertas gestionadas de Postgres en la nube, como Amazon RDS), la versión 2.5 implementó la capacidad de operar con múltiples copias de PGDATA, lo cual permitía realizar una actualización completa sin tiempo de inactividad. Sin embargo, si los usuarios de DLE estaban ejecutando clones con la «antigua» versión de PGDATA, necesitaban volver a crearlos para desbloquear la siguiente actualización completa, lo cual resultaba incómodo debido a que la asignación de puertos era bastante impredecible.

En DLE 3.0, ahora es posible restablecer el estado de un clon a cualquier versión de la base de datos (instantánea), incluso si esa versión es proporcionada por otra copia de PGDATA que se ejecuta en un pool o conjunto de datos diferente. Esto significa que los usuarios pueden mantener su clon funcionando en el mismo puerto durante mucho tiempo, disponiendo de credenciales estables de la base de datos (incluyendo el puerto). Cuando sea necesario, una vez terminada la actualización completa, podrán cambiar en pocos segundos a la versión más actualizada de la base de datos. Esto hace que la experiencia de trabajar con el aprovisionamiento de datos «lógico» esté casi a la par con el «físico».

Ejecutar varios DLE en una sola máquina

Originalmente, DLE fue diseñado para ejecutarse en una máquina dedicada, física o virtual. Sin embargo, a muchos usuarios esto les resultaba incómodo. En ciertos casos, los entornos de desarrollo y pruebas están sujetos a optimizaciones de presupuesto, por lo que puede tener mucho sentido ejecutar varios DLE en una sola máquina, especialmente si la organización dispone de muchas bases de datos más pequeñas (algo típico en el caso de quienes se ocupan de arquitecturas de microservicios).

DLE 3.0 incorpora varias mejoras que simplifican la ejecución de múltiples DLE en una misma máquina. En particular, la nueva opción de configuración selectedPool permite disponer de un único pool ZFS y ejecutar múltiples DLE en forma tal que cada uno de ellos tenga su propio conjunto de datos. Esto simplifica considerablemente la gestión del espacio libre en el disco. En lugar de lidiar con una asignación de espacio fragmentada y con una gran cantidad de números de «espacio libre en el disco», el administrador de DLE ahora tiene que controlar un solo número y ajustar el tamaño del disco con mucha menos frecuencia.

Estamos pensando tratar los aspectos de la ejecución de múltiples DLE en una sola máquina en un artículo separado.

Más información

• Notas de la versión 3.0 de DLE
• Documentación de Database Lab
• Tutorial para todo tipo de bases de datos
• Tutorial para Amazon RDS
• Tutorial interactivo (Katacoda)

Solicitud de comentarios y contribuciones

Agradecemos enormemente cualquier comentario o contribución:

• Slack de la Comunidad de Database Lab
• Rastreador de problemas de DLE y DB Migration Checker
• Rastreador de problemas del módulo Terraform para Database Lab