Descrivere, in un'unica sequenza operativa, come utilizzare i due repository per ricreare su un database di destinazione la struttura e i dati dei 29 database presenti sul server MariaDB del portale aziendale WebTool.
Il codice contenuto nei repository database_migration_tools_structure e database_migration_tools_data è stato realizzato per consentire la creazione di una copia coerente dei 29 database presenti sul server MariaDB del portale aziendale WebTool. La procedura separa volutamente la migrazione in due attività: prima l'allineamento della struttura, quindi la copia dei dati.
Benché configurati per l'ambiente WebTool, gli strumenti sono riutilizzabili anche in altri contesti MariaDB/MySQL, purché vengano adattati correttamente i file di configurazione, le connessioni, l'elenco dei database e le eventuali tabelle da escludere.
Per qualsiasi collegamento al server di produzione utilizzare sempre e soltanto un'utenza con permessi di sola lettura.
L'utenza di produzione non deve possedere permessi di INSERT, UPDATE, DELETE, CREATE, ALTER, DROP o altri privilegi di modifica.
I comandi che modificano o cancellano dati devono essere eseguiti esclusivamente sul database di destinazione o clone locale.
Prima delle operazioni distruttive verificare host, porta, nome database e utenza configurata; quando possibile, disattivare anche VPN o altri accessi alla produzione.
database_migration_tools_structure: Gestisce la struttura tramite Skeema: tabelle, colonne, indici, vincoli e altre definizioni SQL.
https://alm.alstom.com/git/servicecontrolroom/service-engineering-team/database_migration_tools_structure.git
database_migration_tools_data: Gestisce l'ordine delle tabelle, l'esportazione, la cancellazione sul clone e la successiva importazione dei record.
https://alm.alstom.com/git/servicecontrolroom/service-engineering-team/database_migration_tools_structure.git
database_migration_tools_structure.database_migration_tools_data.sudo apt update
sudo apt install -y curl ca-certificates
curl -LO https://app.skeema.io/community/v1/skeema_amd64.deb
sudo apt install ./skeema_amd64.deb
Verificare quindi l'installazione:
which skeema
skeema version
skeema help
database_migration_tools_structure.webtool_db/.skeema.example.webtool_db/.skeema.cp webtool_db/.skeema.example webtool_db/.skeema
webtool_db/.skeema inserendo le connessioni necessarie.
.skeema contiene informazioni credenziali: non deve essere versionato né pubblicato.Per ricreare localmente i file SQL della struttura, eseguire il pull dal profilo sorgente configurato, ad esempio:
skeema pull production_100
Il comando legge la struttura dei database dalla sorgente e aggiorna i file SQL sotto webtool_db. Non deve modificare la produzione; il profilo deve comunque usare un'utenza di sola lettura.
skeema diff production_clone_local
Per produrre anche un file contenente le differenze SQL:
skeema diff production_clone_local --allow-unsafe > diff_local.sql 2>&1
Esaminare sempre il contenuto del diff prima di applicarlo. La presenza di operazioni distruttive può essere normale quando si vuole ottenere una copia esatta, ma deve essere verificata con particolare attenzione.
skeema push production_clone_local
Il push deve essere indirizzato esclusivamente al profilo del clone locale. Non eseguire mai un push verso production_100 o verso qualsiasi profilo che punti alla produzione.
skeema diff production_clone_local
Il risultato atteso è "No differences found" per tutti i database gestiti. Solo dopo questo controllo è opportuno procedere con la migrazione dei dati.
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
Gli script del repository database_migration_tools_data utilizzano i file presenti nella cartella config. Prima dell'esecuzione, rinominare o copiare i file .example forniti dal repository nei corrispondenti file effettivi di configurazione e compilare con estrema attenzione i parametri di connessione.
.env (derivato da .env.example): Parametri di connessione ai database sorgente e di destinazione (host, porta, credenziali, ecc.). La connessione verso l'ambiente di produzione deve utilizzare esclusivamente un utente con permessi di sola lettura. La connessione di destinazione deve invece puntare al clone locale (o altro ambiente autorizzato), sul quale verranno eseguite le operazioni di cancellazione e reimportazione dei dati.databases.txt: Elenco dei database da elaborare, uno per riga. Nel caso del portale WebTool il file contiene attualmente i 29 database oggetto della procedura.excluded_tables.txt: Elenco delle tabelle da escludere dalla migrazione, nel formato database.tabella, una per riga. È normalmente utilizzato per escludere backup, log, tabelle obsolete o qualsiasi contenuto che non debba essere migrato.Passo 1 - Generazione dell'ordine delle tabelle
python generate_database_import_delete_order.py
Lo script analizza le FOREIGN KEY dichiarate nei database e genera gli ordini necessari: importazione (tabelle padre → tabelle figlie) e cancellazione (tabelle figlie → tabelle padre). I file risultanti vengono salvati nella cartella output.
Passo 2 - Esportazione dei dati dalla sorgente
python export_database_data.py
Per ciascuna tabella prevista viene prodotto un file SQL contenente gli INSERT necessari a ricostruire i dati. La connessione sorgente deve usare solo l'utenza di produzione in sola lettura.
Passo 3 - Cancellazione dei dati sul database di destinazione
CONTROLLO OBBLIGATORIO PRIMA DELL'ESECUZIONE: Verificare che la destinazione configurata sia il clone locale. Questo passaggio elimina i dati esistenti e non deve mai essere eseguito sulla produzione.
python delete_database_data.py
La cancellazione segue l'ordine figlie → padre per evitare violazioni dei vincoli referenziali.
Passo 4 - Importazione dei dati sul database di destinazione
python import_database_data.py
L'importazione segue l'ordine padre → figlie. Al termine, il database di destinazione deve contenere una copia coerente dei dati sorgente, escluse le tabelle esplicitamente indicate in excluded_tables.txt.
Gli script rilevano automaticamente le relazioni dichiarate mediante FOREIGN KEY. Le relazioni applicative non dichiarate nel database (es. collegamenti mantenuti solo dal codice dell'applicazione) non possono essere rilevate automaticamente, ma se vengono migrate tutte le tabelle interessate e gli identificativi originali restano invariati, tali relazioni logiche vengono normalmente preservate.
skeema diff sul clone e verificare che non vi siano differenze strutturali inattese.databases.txt.