Sync AWS → Locale

Pulsante manuale per aggiornare il DB locale con i dati più recenti da AWS

Scopo

L'app originale di Diego gira su AWS (IP 35.180.208.200). Ogni giorno viene usata dal laboratorio per nuove analisi. La nostra copia locale (server aaPanel) è un "punto nel tempo" statico.

Per allineare la nostra copia ai dati freschi, l'admin clicca un pulsante nel gestionale: lo script dumpa il DB AWS e lo re-importa in locale.

⚠ Sync distruttiva

Il sync è drop+recreate del DB locale. Perdi eventuali modifiche fatte sul nostro server. Questo è OK perché il nostro server è solo read-only consultazione — il lavoro vero è su AWS. Prima del drop facciamo un backup gzip automatico.

Stato attuale dopo ultima sync

Apri il file germ_old_sync.php?action=status per vedere:

Counts attuali (analisi, lotti, ultima analisi, ultimo lotto)
Ultime 30 righe di log
Ultima sync: timestamp + risultato

Architettura

┌─ Browser utente ──────────────────────────────────┐
│  tab "Germinabilità OLD" → bottone "⬇ Sincronizza"│
└────────────────────┬──────────────────────────────┘
                     │  POST /germ_old_sync.php?action=run
                     ▼
┌─ PHP endpoint (aaPanel, user=www) ────────────────┐
│  exec('sudo /usr/local/bin/semiorto_sync.sh …')   │
│  (permesso NOPASSWD in /etc/sudoers.d/semiorto)   │
└────────────────────┬──────────────────────────────┘
                     │
                     ▼
┌─ Shell script /usr/local/bin/semiorto_sync.sh ────┐
│                                                   │
│  1. mysqldump da 35.180.208.200:3300 (AWS)        │
│     docker exec semiorto_germ_db sh -c            │
│       "mysqldump -h35.180.208.200 -P3300          │
│         -uroot -piron666M semiorto > /tmp/…"      │
│                                                   │
│  2. Backup gzip DB locale pre-sync                │
│     mysqldump semiorto | gzip > pre_{TS}.sql.gz   │
│                                                   │
│  3. Drop + ricrea DB locale                       │
│     DROP DATABASE semiorto;                       │
│     CREATE DATABASE semiorto CHARACTER SET latin1;│
│                                                   │
│  4. Import dal dump AWS                           │
│     mysql semiorto < /tmp/semiorto_aws.sql        │
│                                                   │
│  5. Verifica counters + log                       │
│  6. Pulizia (mantieni ultimi 7 backup pre-sync)   │
└───────────────────────────────────────────────────┘

Tempi tipici

mysqldump AWS: 15-20 sec (30 MB)
Backup locale gzip: 5 sec
Drop + recreate: 1 sec
Import: 10-15 sec
Totale: ~40-60 secondi

Log

File: /var/log/semiorto_sync.log (permessi 664, owner www). Esempio:

=== [2026-04-20_17-19-27] Sync AWS -> locale starting ===
[2026-04-20_17-19-27] Dump AWS OK: 30301398 bytes
[2026-04-20_17-19-27] Sync OK: 61998 analisi, ultima 2026-04-20
[2026-04-20_17-19-27] Done.

=== [2026-04-21_09-02-15] Sync AWS -> locale starting ===
[2026-04-21_09-02-15] Dump AWS OK: 30302891 bytes
[2026-04-21_09-02-15] Sync OK: 62047 analisi, ultima 2026-04-21
[2026-04-21_09-02-15] Done.

(49 nuove analisi in un giorno — tipico carico lab)

Sicurezza

Lo script viene invocato da PHP via sudo solo per quel comando specifico. Configurazione in /etc/sudoers.d/semiorto_sync:

www ALL=(root) NOPASSWD: /usr/local/bin/semiorto_sync.sh

Questo permette al PHP-FPM user (www) di eseguire solo quel script, non altri. Verificato con visudo -c.

Configurazione che NON facciamo (e perché)

Cron automatico

Prima versione aveva un cron giornaliero alle 04:00. L'utente ha chiesto esplicitamente di rimuoverlo: la sync deve essere on-demand, non schedulata. Motivo: durante la sync il DB è temporaneamente inutilizzabile (~40 sec) e l'admin preferisce scegliere quando fare l'operazione.

Replica master-slave MySQL

Tecnicamente migliore (real-time, no downtime), ma richiede:

Abilitare binlog su AWS MySQL (richiede SUPER privilege — da negoziare con Diego)
Configurazione replication su MySQL locale
Gestione lag, conflitti, break di replica

Troppo complesso per un use-case "read-only consultazione". Il pulsante manuale è più pragmatico.

Sync incrementale (solo nuovi record)

Possibile: WHERE data > '{ultima_data_locale}' su semiorto_analisi. Ma:

Non tutte le tabelle hanno un campo timestamp affidabile
Le conte non hanno campo data
I lotti si aggiornano (esaurito) senza timestamp

Il full dump gzip è ~30 MB: troppo piccolo per giustificare la complessità dell'incrementale.

Troubleshooting

Sync fallisce con "Connection refused"

AWS firewall potrebbe aver chiuso la porta 3300 per il nostro IP. Verifica:

nc -zv -w3 35.180.208.200 3300

Se failed: contattare chi gestisce AWS Security Group per aprire 3300 al nostro IP outbound.

Import fallisce per charset

Se emergono errori "Unknown character" nei log, il dump AWS potrebbe avere charset inconsistent. Ritenta con:

mysqldump --default-character-set=latin1 ...

Disk full

Il container MySQL locale salva i backup in /tmp/semiorto_local_pre_*.sql.gz. Pulisci manualmente se serve:

docker exec semiorto_germ_db sh -c "rm /tmp/semiorto_local_pre_*.sql.gz"