Hola

Creo que este es el grupo mas adecuado para plantear esta cuestión. He estado mirando/preguntando, pero no encuentro una respuesta válida. A ver si me podéis orientar un poco

Tenemos que migrar un MySQL (v5.1) a algo más actual. Actualmente es una réplica Maestro-Esclavo, pero se quiere ver si podría ser más adecuado algún otro tipo de arquitecturacomo cluster MariaDB/Percona...

No tengo mucha experiencia en BBDD y quería conocer un poco vuestro punto de vista a tenor de la experiencia que podáis haber tenido con estos tipos de arquitecturas. Lo ideal es que sea lo más robusta posible.

De cara a la migración, estamos contemplando herramientas de Percona como xtrabackup y pt-table-sync, aunque no las conocemos, y la verdad es que dado el nº de versiones a actualizar, casi diría que mejor un volcado completo (aunque sea por partes). Pero claro, requeriría arranque/parada, y eso podría ser un lujo que nos penalizaría.

Bueno, sin más, es ver un poco vuestra opinión al respecto, porque yo veo bastante negro este tipo de migraciones (a poder ser sin parada)
Si es mucho rollo lo que he planteado, al menos saber qué os parece mejor, réplica maestro esclavo o cluster Galera (Percona o MariaDB). Desde el punto de vista de robustez

Venga chicos, un saludo y gracias anticipadas.

--- Claws Mail 4.1.0 (GTK 3.24.34; x86_64-pc-linux-gnu)
* Origin: From the Eye Of The Beholder BBS (NNTP Gateway) (2:343/107.997)

Hola Oscar,

Tenemos que migrar un MySQL (v5.1) a algo más actual. Actualmente es una réplica Maestro-Esclavo, pero se quiere ver si podría ser más adecuado algún otro tipo de arquitecturacomo cluster MariaDB/Percona...

Veo que tu viejo problema volvió... :-)

Es un pollo gargantuesco, porque tendrás paros en algún momento, o cortes de servicio en las tareas de migración de componentes.

Tal como lo planteas, una idea podría ser ampliar tu cluster MySQL 5.1 con un nuevo nodo que sería MariaDB 5.1 Server. Ahí trabajarías los errores del cambio tecnológico, teniendo en cuenta las conversiones de MyISAM a InnoDB, entre otras. A partir de ahí, puedes ir probando a subir de versión en versión el MariaDB, puliendo errores. Y cuando estés seguro, switchover, y pasas el servicio al nodo replicado de MariaDB. Y si no explota nada ahí montas el cluster de MariaDB (Galera mismo). Ahí, el problema es que mientras en una situación de Replicado sólo tienes un nodo dando servicio y es más fácil asegurar la integridad, en uno de CLuster todos los nodos te dan servicio de manera simultánea y distribuída. Todo se complica. :-)

¿Qué te parece?

A reveure!!
Enric


--- BBBS/Li6 v4.10 Toy-5
* Origin: Eye Of The Beholder BBS - The Fidonet's Corsair (2:343/107)

Hola Oscar,

Venga chicos, un saludo y gracias anticipadas.

Y como me ha picado la curiosidad y aprovechando que ahora está de moda, le he preguntado a ChatGPT cómo lo haría "él", primero sin especificarlo, y luego aclarando que debería ir sin pérdida de servicio:

Describe the procedure for migrating a MySQL 5.1 replica with one master and

one slave to a MariaDB Galera.

Migrating a MySQL 5.1 replica with one master and one slave to a MariaDB Galera cluster involves the following steps:

Verify compatibility: Before starting the migration, ensure that your application is compatible with MariaDB Galera. This is important because Galera has some limitations and differences from standard MySQL, so it may require some application-level changes.

Upgrade MySQL to MariaDB: Upgrade MySQL 5.1 to MariaDB on both the master and the slave. This is necessary because Galera requires MariaDB instead of MySQL.

Install MariaDB Galera: Install MariaDB Galera on all nodes of the cluster. Ensure that the Galera version matches the MariaDB version.

Configure the Galera cluster: Modify the configuration files on all the nodes of the cluster to enable Galera replication. Specify the IP addresses of all the nodes in the wsrep_cluster_address parameter.

Prepare the MySQL master: Stop the MySQL master and take a backup of the database. This backup will be used to populate the Galera cluster.

Prepare the Galera nodes: Stop the MariaDB Galera on all nodes and clean up the existing database files. Restore the database backup from the MySQL master to one of the nodes of the cluster.

Bootstrap the cluster: Start the MariaDB Galera on the node where the database has been restored. This will create a new Galera cluster. Once the cluster is formed, start the Galera on the other nodes and join them to the cluster.

Replicate the data: After the cluster is formed, data from the original MySQL master can be replicated to the Galera cluster using standard MySQL replication tools.

Verify the replication: Once the data replication is complete, verify the replication by comparing the data in the original MySQL master with the data in the Galera cluster.

Update the application: Update the application to use the new Galera cluster instead of the original MySQL master-slave setup.

By following these steps, you can successfully migrate a MySQL 5.1 replica with one master and one slave to a MariaDB Galera cluster. openia@kishpa.com
Describe the procedure for migrating a MySQL 5.1 Replication with one master and one slave to a MariaDB Galera without outage.

Migrating a MySQL 5.1 Replication with one master and one slave to a MariaDB

Galera without an outage involves the following steps:

Verify compatibility: Before starting the migration, ensure that your application is compatible with MariaDB Galera. This is important because Galera has some limitations and differences from standard MySQL, so it may require some application-level changes.

Install and configure MariaDB Galera: Install MariaDB Galera on all nodes of the cluster. Ensure that the Galera version matches the MariaDB version. Modify the configuration files on all the nodes of the cluster to enable Galera replication. Specify the IP addresses of all the nodes in the wsrep_cluster_address parameter.

Prepare the Galera nodes: Stop the MariaDB Galera on all nodes and clean up the existing database files. Take a backup of the database on the MySQL slave server.

Restore database backup to one node: Restore the database backup from the MySQL slave to one of the nodes of the Galera cluster.

Bootstrap the cluster: Start the MariaDB Galera on the node where the database has been restored. This will create a new Galera cluster. Once the cluster is formed, start the Galera on the other nodes and join them to the cluster.

Set up replication from the MySQL master to the Galera cluster: Configure the MySQL master to replicate data to the Galera cluster. This can be done by adding the Galera node as a slave in MySQL.

Verify the replication: Once the data replication is complete, verify the replication by comparing the data in the original MySQL master with the data in the Galera cluster.

Update the application: Update the application to use the new Galera cluster instead of the original MySQL master-slave setup.

By following these steps, you can successfully migrate a MySQL 5.1 Replication with one master and one slave to a MariaDB Galera without any outage. The application can continue to use the old MySQL master-slave setup during the migration, and the data will be replicated in the background to the new Galera cluster. Once the replication is complete, the application can be switched over to the new Galera cluster.


Por tanto, mi aproximación no parece ir desencaminada... :-D Mucha suerte, maestro!

PS.- Por cierto, veo que ClawsMail ya te setea el "All" en los mensajes salientes?

A reveure!!
Enric

--- BBBS/Li6 v4.10 Toy-5
* Origin: Eye Of The Beholder BBS - The Fidonet's Corsair (2:343/107)

Hola Enric

Veo que tu viejo problema volvió... :-)

Si, se habia parado, pero ahora golpea de nuevo. Y mas que han ordenado actualizad toda la infraestructura a lo último

Es un pollo gargantuesco, porque tendrás paros en algún momento, o
cortes de servicio en las tareas de migración de componentes.

Si que lo es. Encontré un método que hibridaba ambos sistemas (maestro-esclavo y cluster), pero había que probarlo. Había llegado hasta que la parte mestro-esclavo fuese circular (añadiendo un tercer nodo) y con alguna herramienta de Percona que permitía sincronización sin pérdida de servicio, de manera que pudiera partir de maestro-esclavo sincronizados correctamente (no estaba la misma información en ambos nodos). De ahí sacar ese tercer nodo, hacerlo circular y luego ir pasando a cluster.
Pero esa herramienta (bueno, había 2) también tenía sus limitaciones, asi que al final, también se complicaba.
Lo bueno era que al menos ya tenía pensada la estrategia, y "sobre el papel" podía funcionar
Pero me quedé ahi. Surgieron otras cosas urgentes y se volvió a aparcar.. Y ahora, con la exigencia de actualizar todo, se ha retomado y no hay vuelta atrás.
Ante mi insistencia en buscar una migración algo mas normal, el jefe de proyecto ha conseguido ver una manera en la que se puedan migrar los datos sin que les afecte (o sea mínimo), pudiendo hacer la migracíon por partes.
Asi que ahora ya es otra cosa. He montado un cluster Percona y vamos a pasar 2 BBDD (inicialmente) para ver qué tal, y si va bien, iremos poco a poco con otras que tendrán una migración más complicada, llevándose a cabo por partes
En fin, que ahora tiene mejor pinta. Aunque había encontrado una solución (al menos en teoria), y me llevó mi esfuerzo, prefiero tirar por esta otra. No considero tiempo perdido. Siempre se aprenden cosas

Ya os contaré qué tal va. Menudo rollo os he soltado. Pero me ha servido como desahogo :-D

Venga, un saludo

--- Claws Mail 4.1.1 (GTK 3.24.37; x86_64-pc-linux-gnu)
* Origin: From the Eye Of The Beholder BBS (NNTP Gateway) (2:343/107.997)

:-) Lo importante es que ya estéis todas las partes alineadas y se te permita abordar el proyecto de una manera paulatina y faseada.
Sí, ya contarás cómo va. ¡¡Suerte!!

Pues de momento ahí sigue la cosa, aunque se va a abordar por partes, lo cual, si no se quiere parada es más lógico.
De hecho, ya hay una pequeña parte funcionando en producción y de momento muy bien
Ya os contaré qué tal finaliza, porque de momento se aparcan todos los proyectos para dedicarnos a una parte de securización a la que nos han obligado

Un saludo

--- Claws Mail 4.1.1 (GTK 3.24.37; x86_64-pc-linux-gnu)
* Origin: From the Eye Of The Beholder BBS (NNTP Gateway) (2:343/107.997)

Hola

Ya os contaré qué tal finaliza, porque de momento se aparcan todos los
proyectos para dedicarnos a una parte de securización a la que nos han obligad

"Os han obligado"? Eso quiere decir que os han hackeado... :-/ A
vosotros, o a alguien cercano de vuestra competencia...

Realmente es un tema de seguros. Se ha querido contratar un seguro que cubra todo tipo de problemas, y por lo que me ha comentado la chica que lleva la contabilidad, a un precio de risa, asi que las compañías de seguros se han negado. Excepto la que lleva trabajando con nosotros muchos años, al parecer por compromiso. Pero ha impuesto unas condiciones muy severas, ya que ultimamente los ataques han aumentado exponencialmente. Realmente no quieren asegurarnos

Y supongo que lo del seguro ha surgido (aunque aquí no lo puedo asegurar) porque una empresa perteneciente a los dueños (no es de nuestro grupo, simplemente estos dueños tienen varios grupos de empresas) ha debido tener un ataque de Ramsonware, y quieren que todas las empresas que cuelgan de ellos estén aseguradas

Pero sí, me interesará saber cómo lo habéis hecho al final... ¡Gracias!

Os voy contando :)

--- Claws Mail 4.1.1 (GTK 3.24.37; x86_64-pc-linux-gnu)
* Origin: From the Eye Of The Beholder BBS (NNTP Gateway) (2:343/107.997)

Hola Oscar,

Y supongo que lo del seguro ha surgido (aunque aquí no lo puedo asegurar) porque una empresa perteneciente a los dueños (no es de nuestro grupo,

Preguntaré cómo lo tenemos montado nosotros (lo del seguro de ciberamenazas) y te digo...

A reveure!!
Enric

--- BBBS/Li6 v4.10 Toy-6
* Origin: Pursuit Special - The last of the V8 Interceptors (2:343/107.1)