RDS e database Ocmis¶
Panoramica¶
L'infrastruttura database di Ocmis e' ospitata su Amazon RDS (PostgreSQL). La presente pagina raccoglie le caratteristiche delle istanze, la configurazione operativa, le procedure di ripristino Point-In-Time (PITR) e le procedure di restore da dump per i due database applicativi: ocmis e portalcfg (farmfront_portalcfg).
| Componente | Tipologia | Note |
|---|---|---|
| Istanza RDS | PostgreSQL su AWS | Backup automatici + transaction logs |
| DB ocmis | Database applicativo | Utenti: www_ocmis_readonly, web_ocmis_rw |
| DB portalcfg | Database configurazione portale | Utenti: portal_cfg_readonly_user, portal_cfg_user |
Impostazioni del database¶
| Parametro | Valore |
|---|---|
| Finestra di manutenzione aggiornamenti | Ogni domenica alle 06:00 UTC, durata prevista 30 minuti |
| Retention dei log del database | 7 giorni |
| Retention dei backup del database | 30 giorni |
| Backup giornaliero | Programmato alle 22:00 UTC, durata stimata 30 minuti (effettiva ~10 minuti) |
Ripristino Point-In-Time (PITR)¶
Amazon RDS permette di ripristinare il database a uno specifico punto nel tempo utilizzando un sistema basato su backup incrementali e log delle transazioni.
Funzionamento generale¶
- Al momento della configurazione del database o della creazione di una snapshot automatica programmata, viene eseguito un backup completo iniziale.
- Dopo il backup completo, RDS raccoglie e archivia continuamente i log delle transazioni incrementali. Questi log registrano ogni modifica effettuata al database e sono salvati regolarmente su Amazon S3.
Procedura di ripristino¶
| Fase | Descrizione |
|---|---|
| Backup come base | AWS utilizza l'ultimo backup completo disponibile |
| Log delle transazioni | Applica le modifiche successive contenute nei transaction logs fino all'orario esatto specificato |
| Output | Viene creata una nuova istanza del database coerente con lo stato al momento selezionato |
Limitazioni temporali¶
- E' possibile tornare indietro fino a 5 minuti prima dell'ora attuale.
- La retention configurata (7 giorni) consente di selezionare un punto temporale specifico all'interno di questo intervallo.
Modalita' di ripristino¶
| Aspetto | Dettaglio |
|---|---|
| Sovrascrittura non possibile | Su AWS non e' consentito sovrascrivere un database esistente con un ripristino. Ogni operazione di PITR genera una nuova istanza |
| Processo di integrazione | Dopo il ripristino e' necessario aggiornare i puntamenti delle applicazioni al nuovo database (modifica dell'endpoint) |
| Persistenza delle configurazioni | La nuova istanza eredita automaticamente Security Group, Subnet e altre configurazioni di rete |
Dati da test effettuati: il restore ha impiegato circa 12 minuti. Le configurazioni risultavano corrette e il nuovo DB era la copia del precedente, fatta eccezione per il nome DNS del nuovo DB RDS.
Ripristino da dump (emergenza)¶
Per il ripristino delle Snapshot in caso di emergenza consultare la guida apposita su ClickUp (documento privato).
Per il ripristino del dump in caso di emergenza:
Prerequisito: PostgreSQL 17 via Docker¶
Per effettuare una prova rapida serve un'installazione PostgreSQL versione 17. La via piu' rapida e' Docker.
Scaricare l'immagine (versione 17.2):
docker pull postgres:17.2
Creare il container:
docker run --name postgres -e POSTGRES_PASSWORD=password -d -p 5432:5432 postgres:17.2
Collegarsi al DB tramite PgAdmin.
Considerazioni sul restore¶
Provando ad effettuare il restore viene segnalato un errore durante l'esecuzione: il restore va a buon fine ma, dato che non esistono gli utenti e i gruppi, i permessi sulle tabelle non vengono applicati. Questa e' la situazione tipica nel restore su nuovo ambiente. L'errore, eseguendo il restore su un DB gia' esistente, non si manifesterebbe perche' utenti e gruppi esisterebbero gia'.
I privilegi di accesso sui database e sulle tabelle sono visibili direttamente dallo schema del database esportato. Quando si esegue l'importazione del dump in un nuovo ambiente, tutti i privilegi associati alle tabelle vengono automaticamente reimportati, preservando le impostazioni originali.
L'elemento cruciale e' l'ordine di creazione degli oggetti nel dump: gli elementi referenziati (tabelle o colonne utilizzate da viste o procedure) devono essere creati prima degli oggetti che dipendono da essi, per evitare errori durante l'importazione.
DB Ocmis¶
Utenti e gruppi¶
| Utente | Gruppi a cui appartiene | Lettura | Scrittura |
|---|---|---|---|
| www_ocmis_readonly | ocmis_readonly_group | si | |
| web_ocmis_rw | ocmis_readwrite_group | si | si |
Procedura di configurazione¶
1. Creazione gruppi
-- Crea il gruppo per gli utenti di sola lettura
CREATE ROLE ocmis_readonly_group;
-- Crea il gruppo per gli utenti di lettura e scrittura
CREATE ROLE ocmis_readwrite_group;
2. Creazione utenti
-- Crea l'utente con login
CREATE ROLE www_ocmis_readonly WITH LOGIN PASSWORD 'p1';
-- Crea l'utente con login
CREATE ROLE web_ocmis_rw WITH LOGIN PASSWORD 'p2';
3. Assegnazione utenti ai gruppi
-- Assegna l'utente "www_ocmis_readonly" al gruppo "ocmis_readonly_group"
GRANT ocmis_readonly_group TO www_ocmis_readonly;
-- Assegna l'utente "web_ocmis_rw" al gruppo "ocmis_readwrite_group"
GRANT ocmis_readwrite_group TO web_ocmis_rw;
4. Creazione del DB ocmis
5. Importazione del dump
DB Portalcfg¶
Utenti e gruppi¶
| Utente | Gruppi a cui appartiene | Lettura | Scrittura |
|---|---|---|---|
| portal_cfg_readonly_user | portal_cfg_group_readonly, portalcfg_readonly_group | si | |
| portal_cfg_user | portal_cfg_group, portalcfg_readwrite_group | si | si |
Procedura di configurazione¶
1. Creazione gruppi
-- Crea il gruppo per gli utenti di sola lettura
CREATE ROLE portal_cfg_group_readonly;
CREATE ROLE portalcfg_readonly_group;
-- Crea il gruppo per gli utenti di lettura e scrittura
CREATE ROLE portal_cfg_group;
CREATE ROLE portalcfg_readwrite_group;
2. Creazione utenti
-- Crea l'utente con login
CREATE ROLE portal_cfg_readonly_user WITH LOGIN PASSWORD 'p1';
-- Crea l'utente con login
CREATE ROLE portal_cfg_user WITH LOGIN PASSWORD 'p2';
3. Assegnazione utenti ai gruppi
-- Assegna l'utente "portal_cfg_readonly_user" al gruppo "portal_cfg_group_readonly"
GRANT portal_cfg_group_readonly TO portal_cfg_readonly_user;
-- Assegna l'utente "portal_cfg_readonly_user" al gruppo "portalcfg_readonly_group"
GRANT portalcfg_readonly_group TO portal_cfg_readonly_user;
-- Assegna l'utente "portal_cfg_user" al gruppo "portal_cfg_group"
GRANT portal_cfg_group TO portal_cfg_user;
-- Assegna l'utente "portal_cfg_user" al gruppo "portalcfg_readwrite_group"
GRANT portalcfg_readwrite_group TO portal_cfg_user;
4. Creazione del DB portalcfg
5. Importazione del dump
Sequenza operativa completa¶
Seguendo l'ordine stabilito il restore su un nuovo ambiente viene eseguito correttamente. Nel test di riferimento era stato creato un container Docker nuovo e sono state eseguite le seguenti operazioni:
| Passo | Attivita' |
|---|---|
| 1 | Scaricati i dump da S3 creati dallo script automatico |
| 2 | Eseguite le query di creazione degli utenti e dei gruppi (query sopra riportate) |
| 3 | Creati i due DB ocmis e portalcfg |
| 4 | Restore del dump sui due DB |