migrazione preliminare VM Hyper-V a VM proxmox QEMU (e fix relativi)
creazione 3 nodi LXC che saranno il futuro cluster, con storage dedicato a DB montato in /var/lib/mysql nell'LXC
test di migrazione senza interruzione di servizio
inserimento layer keepalived (solo sul nodo VM originale) per scambio IP fisico / virtual IP (utilizzato in seguito)
install prerequisiti sui nodi
- ubuntu 24.04
- mariadb
- galera
- tools vari
- keepalived
preparazione di un nodo (db03) per i test
script di migrazione (a caldo e da fare poi a insert bloccati)
interruzione servizio (blocco virtual IP)
migrazione vera dei dati (old --> db03)
fix utenti
riavvio Virtual IP su nuovo nodo
avvio del nuovo cluster sul primo nodo
join dei 2 nodi sul cluster
dismissione vecchia VM
fix e correzioni varie (es problema ID utenti proxmox x mount --> subfolder)

Appunti configurazione

Sono allegati ma si lascia in appunto al conf saliente di MariaDb (50-server.cnf e 60-galera.cnf) impiegata nonché x keepalived

Suddivisione cartelle: configurazioni speciali, gestione utils, gestione migrazione.

Si è provato wssrep con mariadb-backup all'inizio ma non ne ha voluto sapere, usato rsync (da rivalutare in futuro alternativa).

Applicativi necessari

Elenco applicativi installati

apt update && apt upgrade -y
apt install vim mc htop dstat ncdu curl
apt install mariadb-server galera-4 mariadb-backup keepalived

Uso script migrazione DB VM --> LXC

Per eseguire gli helper script di migrazione si sono usati alcuni accorgimenti:

lo script va eseguito sul nodo donor attuale
db03.eqn è cablato in /etc/hosts verso nodo receiver
lo script può essere provato live, ma va eseguito a insert disabilitati per una conversione pulita (per farlo con virtual IP si è spento keepalived)

Uso script fix DB su nuovo cluster

Per l'impiego deglis cript sql di fix dei dati nel db migrato (in particolare x i campi not nullable senza default e problemi di collation) si è usato questo approccio

mysql < scriptDaEseguire.sql > resultFile.sql

dove il primo script scriptDaEseguire.sql è quello operativo, mentre resultFile.sql è il risultato che si può poi impiegare

anzi in particolare per evitare intestazioni colonne ed altri campi non necessari

mysql -s -N < scriptDaEseguire.sql > resultFile.sql

Gli script sono serviti in particolare per

sistemare null senza default
sistemare collation (facendo 10-20 alter alla volta perché il cluster era running e non si voleva impattare eccessivamente)

Appunti a latere

Per impiegare i 3 noidi in modo bilanciato si è installato haproxy direttametne sugli FE in modo che ogni fe, chiamando localmente sulla prota 3306, venga instradato su uno dei 3 nodi in modo trasparente.