Cuando nuestras bases de datos van creciendo, ya sea en número de tablas, en número de registros, o ambas cosas, es muy común que empecemos a apreciar una degradación en el tiempo de ejecución de las queries de lectura, especialmente si éstas son complejas y tienen que coger datos de diferentes tablas.

Por suerte, MySQL ofrece opciones para acelerar (optimizar) estas consultas.

Pero antes de pasar a explicar este proceso, vamos a empezar por comprender un concepto básico: ¿cómo elige InnoDB (el motor de almacenamiento que utiliza MySQL) el mejor camino a seguir a la hora de recoger datos? La respuesta es: sirviéndose del contenido almacenado en la tabla statistics.

Esta tabla, que se encuentra en la base de datos information_schema, almacena información sobre los índices de todas las tablas del conjunto entero de las bases de datos.

Todos conocemos (o deberíamos conocer) la recomendación de cambiar nuestras contraseñas cada cierto tiempo.

Sobre todo en entornos empresariales, esta sugerencia se extiende no sólo al cambio de contraseña de usuario, sino también de claves RSA para accesos SSH, cifrados, etc.

En este caso, venimos a hablaros de una necesidad de cambio de claves distinta, pero igualmente importante para nosotros. 

En STR Sistemas, intentamos automatizar el 100% de las infraestructuras (terraform) y configuración de Sistemas (ansible). En dichas automatizaciones, en ocasiones, es necesario incluir información sensible (contraseñas, certificados SSL, RSA's de usuarios, etc), la cual siempre ciframos para evitar tener en código/repositorio contraseñas en texto plano.

Dicho esto, en STR nos topamos con una situación la cual, una vez más, nos llevó a pensar en la automatización o en una solución programada.

Hoy hablamos de seccomProfile, (acrónimo elegido de Secure Computing), que implementa parte de la seguridad  de los procesos Linux, para filtrar las llamadas al sistema de los contenedores en función de las reglas definidas. Se introdujo en la versión v1.19 a través de la definición de los securityContext, desactivado por defecto para dar compatibilidad a versiones anteriores.

Los tipos de profiles disponibles son:

• Unconfined (por defecto): seccomp desactivado.
• RuntimeDefault: seccomp activado con opciones por defecto.
• Localhost: seccomp en modo local indicando el path a utilizar <kubelet-root-dir>/seccomp en kubelet.

En esta tercera parte de nuestra serie sobre la alta disponibilidad en PostgreSQL con Patroni, vamos a ver cómo configurar un servicio de HAproxy para acceder al cluster de Patroni y a obtener más información sobre su API y patronictl.

Si no has visto la primera y la segunda parte de esta serie, te recomendamos que lo hagas para ver por qué estamos utilizando Patroni, y cómo hemos configurado el servicio.

Al finalizar el anterior artículo ya contábamos con un cluster funcional de Patroni, pero para conectar al servicio, lo teníamos que hacer nodo a nodo. Esto no es funcional ya que en caso de fallo de alguno de los nodos, deberíamos elegir el nuevo leader para conectar.

En el anterior artículo de esta serie, describimos nuestra solución de Patroni con etcd y haproxy para desplegar un servicio de PostgreSQL en alta disponibilidad.

Ha llegado el momento de configurar los servicios planificados. En este artículo configuraremos todo lo relacionado con el cluster de PostgreSQL y, en el próximo, finalizaremos con la configuración de HAproxy para acceder al cluster de forma transparente.

PostgreSQL es el segundo sistema de gestión de base de datos más popular y el más querido por los desarrolladores según la encuesta anual de StackOverflow en 2022. Además está muy vinculado con el desarrollo en python.

En este artículo vamos a configurar un cluster de PostgreSQL con alta disponibilidad.

Para contar con alta disponibilidad en un sistema de base de datos son necesarios dos puntos: replicación entre instancias y un failover automático.

En su momento, cuando comenzamos a trabajar con Ansible como una de nuestras herramientas principales para la gestión de los sistemas y configuraciones de nuestros clientes, también implementamos el uso de repositorios para contener esta información. Así, nuestro equipo podría trabajar de forma dinámica con Ansible teniendo un control de versiones de los diferentes cambios que se iban realizando.

A pesar de ello, una parte importante de la información con la que trabajamos en nuestro día a día es delicada, ya sean contraseñas, certificados o ficheros con datos sensibles, y no podrían tratarse de cualquier forma.

A todos nos ha pasado que levantamos un pod y, cuando revisamos su estado en el dashboard de Kubernetes, vemos que tanto el liveness probe como el readiness probe están fallando:

Y ahora, ¿qué?