sql >> Base de Datos >  >> RDS >> PostgreSQL

Pruebas automatizadas del proceso de actualización para PostgreSQL

La prueba es una tarea que requiere mucho tiempo, pero es imprescindible antes de cualquier proceso de actualización de cualquier tecnología. Dependiendo del tipo de actualización, podría ser más difícil o más fácil, pero siempre es necesario si desea asegurarse de que sus datos estén seguros. Existen diferentes enfoques para la actualización, según el negocio y la tolerancia al tiempo de inactividad. Por ejemplo, el proceso podría ser probar su aplicación en un entorno separado con la nueva versión, por lo que deberá crear un nuevo clúster para esto. Otra opción es clonar su entorno de producción actual y actualizarlo, lo que podría ser útil ya que puede emular todo el proceso de actualización y evitar sorpresas en el futuro.

Al realizar todo este proceso de prueba manualmente, existe una gran posibilidad de error humano y el proceso será lento, lo que podría afectar el objetivo de tiempo de recuperación (RTO). En este blog, veremos cómo automatizar las pruebas para actualizar sus bases de datos PostgreSQL usando ClusterControl.

Tipo de actualizaciones de la base de datos

Hay dos tipos de actualizaciones:actualizaciones menores y actualizaciones principales.

Actualizaciones menores

Es la actualización más común y segura y, en la mayoría de los casos, se realiza en el lugar. Como nada es 100% seguro, siempre debe tener copias de seguridad y nodos en espera, por lo que, en caso de que algo salga mal con la actualización, puede promocionar un nodo en espera en la versión anterior y sus sistemas pueden seguir funcionando sin interrupción.

Puede realizar este tipo de actualización mediante ClusterControl. Para ello, vaya a ClusterControl -> Seleccione su clúster de PostgreSQL -> Administrar -> Actualizaciones.

En cada nodo seleccionado, el procedimiento de actualización:

  • Detener nodo

  • Actualizar nodo

  • Nodo de inicio

El nodo maestro en una topología de PostgreSQL no se actualizará. Para actualizar el maestro, primero se debe promover otro nodo para que se convierta en el nuevo maestro.

Actualizaciones importantes

Para actualizaciones importantes, no se recomienda la actualización en el lugar, ya que el riesgo de que algo salga mal es demasiado alto para un entorno de producción. En lugar de esto, existen diferentes enfoques para realizar actualizaciones.

Puede clonar su clúster de base de datos actual, actualizarlo y probar su aplicación allí, y cuando termine, si todo salió bien, puede volver a crearlo para repetir el proceso y realizar la actualización real , o también puede crear un nuevo clúster en la nueva versión, probar su aplicación y cambiar el tráfico cuando esté listo, y hay más opciones... El uso de Load Balancers es útil aquí para mejorar la alta disponibilidad. El mejor enfoque depende de la tolerancia al tiempo de inactividad y del objetivo de tiempo de recuperación (RTO).

No puede realizar actualizaciones principales con ClusterControl directamente porque, como mencionamos, primero debe probar todo para asegurarse de que la actualización sea segura, pero puede usar diferentes funciones de ClusterControl para hacer esta tarea más fácil. Así que veamos algunas de estas características.

Implementación de un entorno de prueba

Para esto, no necesita crear todo desde cero. En lugar de esto, puede usar ClusterControl para hacerlo de forma manual o automatizada.

Restaurar copia de seguridad en host independiente

En la sección Copia de seguridad, elija una copia de seguridad y verá la opción "Restaurar y verificar en un host independiente" para restaurar una copia de seguridad en un nodo separado.

Aquí puede especificar si desea que ClusterControl instale el software en el nuevo y deshabilite el firewall o AppArmor/SELinux (según el sistema operativo). Para esto, necesita un host dedicado (o VM) que no sea parte del clúster.

Puede mantener el nodo en funcionamiento o ClusterControl puede cerrar la base de datos servicio hasta el próximo trabajo de restauración. Cuando finalice, verá la copia de seguridad restaurada/verificada en la lista de copias de seguridad marcada con una marca.

Si no desea realizar esta tarea manualmente, puede programar este proceso utilizando la función de verificación de copia de seguridad, para repetir este trabajo periódicamente en un trabajo de copia de seguridad. Veremos cómo hacerlo en la siguiente sección.

Verificación automática de copia de seguridad de ClusterControl

Para automatizar esta tarea, vaya a ClusterControl -> Seleccione su clúster de PostgreSQL -> Copia de seguridad -> Crear copia de seguridad y elija la opción Copia de seguridad programada. La función Verificar copia de seguridad automática solo está disponible para copias de seguridad programadas.

En el segundo paso, asegúrese de haber activado la opción Verificar copia de seguridad, y complete la información requerida.

Cuando finaliza el trabajo, puede ver el icono de verificación en el ClusterControl Sección de copia de seguridad, la misma que tendrás al hacer la verificación de forma manual, con la diferencia de que no necesitas preocuparte por la tarea de restauración. ClusterControl restaurará la copia de seguridad cada vez automáticamente y podrá probar su aplicación con los datos más recientes.

Crear clúster desde copia de seguridad

Otra forma de crear un entorno de prueba es crear un nuevo clúster a partir de una copia de seguridad de su clúster principal. Para esto, vaya a ClusterControl -> Seleccione su clúster de PostgreSQL -> Copia de seguridad. Allí, elija la copia de seguridad que desea restaurar de la lista y seleccione Restaurar -> Crear clúster desde la copia de seguridad.

Esta opción creará un nuevo clúster de PostgreSQL a partir de la copia de seguridad seleccionada.

Debe agregar las credenciales del SO y la base de datos y la información para implementar el nuevo racimo. Cuando finalice este trabajo, verá el nuevo clúster en la interfaz de usuario de ClusterControl.

Replicación de clúster a clúster

Desde ClusterControl 1.7.4 existe una característica llamada replicación de clúster a clúster. Le permite ejecutar una replicación entre dos clústeres autónomos.

Creación de una replicación de clúster a clúster

Vaya a ClusterControl -> Seleccione su clúster de PostgreSQL -> Acciones de clúster -> Crear clúster esclavo.

El clúster esclavo se creará mediante la transmisión de datos del clúster principal actual.

Debe especificar las credenciales y el puerto SSH, un nombre para su clúster esclavo, y si desea que ClusterControl instale el software y las configuraciones correspondientes por usted.

Después de configurar la información de acceso SSH, debe definir la versión de la base de datos, datadir, puerto y credenciales de administrador. Como usará la replicación de transmisión, asegúrese de usar la misma versión de la base de datos y las credenciales deben ser las mismas que usa el clúster principal.

En este paso, debe agregar el servidor al nuevo clúster esclavo . Para esta tarea, puede ingresar tanto la dirección IP como el nombre de host del nodo de la base de datos.

Puede monitorear el estado del trabajo en el monitor de actividad de ClusterControl. Una vez finalizada la tarea, puede ver el clúster en la pantalla principal de ClusterControl.

Recuperación automática y conmutación por error

Al tener habilitada la función de recuperación automática, en caso de falla, ClusterControl promoverá el nodo de reserva más avanzado a principal y le notificará el problema. También falla el resto de los nodos en espera para replicar desde el nuevo servidor principal.

Si hay Load Balancers en la topología, ClusterControl los reconfigurará para aplicar los cambios de topología.

También puede ejecutar una conmutación por error manualmente si es necesario. Vaya a ClusterControl -> Seleccione su clúster de PostgreSQL -> Nodos -> Seleccione el nodo a promocionar -> Acciones de nodo -> Promover esclavo.

De esta manera, si algo sale mal durante la actualización, puede usar ClusterControl para solucionarlo lo antes posible.

Automatización de cosas con ClusterControl CLI

ClusterControl CLI, también conocido como s9s, es una herramienta de línea de comandos introducida en ClusterControl versión 1.4.1 para interactuar, controlar y administrar clústeres de bases de datos mediante el sistema ClusterControl. ClusterControl CLI abre una puerta para la automatización de clústeres donde puede integrarla fácilmente con las herramientas de automatización de implementación existentes como Ansible, Puppet, Chef, etc. Veamos ahora algunos ejemplos de esta herramienta.

Actualizar

$ s9s cluster --cluster-id=9 \
--check-pkg-upgrades \
--log
$ s9s cluster --cluster-id=9 \
--available-upgrades \
--nodes=10.10.10.122 \
--log \
--print-json
$ s9s cluster --cluster-id=9 \
--upgrade-cluster \
--nodes=10.10.10.122 \
--log

Verificar copias de seguridad

$ s9s backup --verify \
--backup-id=2 \
--test-server=10.10.10.124 \
--cluster-id=9 \
--log

Replicación de clúster a clúster

$ s9s cluster --create \
--cluster-name=PostgreSQL-c2c \
--cluster-type=postgresql \
--provider-version=13 \
--nodes=10.10.10.125 \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--db-admin=admin \
--db-admin-passwd=********* \
--vendor=postgres \
--remote-cluster-id=9 \
--log

Promover nodo esclavo

$ s9s cluster --promote-slave \
--cluster-id=9 \
--nodes='10.10.10.122' \
--log

Conclusión

Las actualizaciones son tareas necesarias pero que requieren mucho tiempo, ya que necesita probar su aplicación para evitar problemas durante el proceso. Implementar un entorno de prueba cada vez que necesite actualizarlo y mantenerlo actualizado sin ninguna herramienta de automatización podría ser difícil.

ClusterControl le permite realizar actualizaciones menores desde la interfaz de usuario o CLI de ClusterControl, o incluso implementar el entorno de prueba para que la tarea de actualización sea más fácil y segura. También puede integrarlo con diferentes herramientas de automatización como Ansible, Puppet y más.