Descrivere la registrazione write-ahead
Quando vengono apportate modifiche nel database, ad esempio INSERTS o DELETES, tali modifiche vengono prima scritte in un log e quindi scritte solo nei file di dati su disco. Questa operazione viene chiamata log write-ahead, perché le modifiche vengono scritte nel log, prima di eseguirne il commit nei file di dati. Se si verifica un problema, ad esempio la perdita di energia, il log contiene sempre i dati più recenti e può essere usato per garantire che il database sia in uno stato coerente.
Un secondo vantaggio è che scrivendo prima le modifiche apportate al log, le modifiche alle tabelle e agli indici possono essere scritte in batch, anziché singolarmente. Questo processo riduce il numero di scritture su disco necessarie per mantenere aggiornate le tabelle e gli indici. Le scritture nel log sono veloci perché vengono eseguite in sequenza. Le scritture più lente in tabelle e indici possono essere eseguite in batch, perché tutti i dati possono essere recuperati dal log. Per i carichi di lavoro che in genere coinvolgono molti aggiornamenti di piccole dimensioni, le prestazioni sono migliorate.
Nota
Per le implementazioni locali di PostgreSQL, il file di log viene archiviato nella directory pg_wal. Database di Azure per PostgreSQL non fornisce l'accesso al file system, quindi non è necessario preoccuparsi dell'archiviazione fisica del file di log.
Esistono diversi parametri del server che consentono di controllare il funzionamento del log di scrittura anticipata e di ottimizzarlo per il tuo carico di lavoro.
- commit_delay: ritardo tra il commit della transazione e lo scaricamento del log su disco.
- wal_buffers: numero di buffer di pagine del disco nella memoria condivisa per la registrazione write-ahead (WAL).
- max_wal_size - dimensione massima consentita per la crescita del WAL prima che attivi il checkpoint automatico.
- wal_writer_delay : intervallo di tempo tra gli scaricamenti WAL eseguiti dal writer WAL.
- wal_compression : indica se le scritture a pagina intera nel file WAL sono compresse.
- wal_level : determina la quantità di informazioni scritte nel wal. I valori consentiti sono REPLICA o LOGICAL.
Ripristino temporizzato
Lo scopo principale del log di write-ahead (WAL) è garantire la consistenza e la durabilità del database in caso di arresto anomalo. La versione locale di PostgreSQL consente di usare il log come archivio, consentendo di eseguire il ripristino a un punto nel tempo usando le impostazioni di configurazione archive_mode e archive_command.
Database di Azure per PostgreSQL è un servizio gestito che non consente l'accesso al file system sottostante. Include tuttavia backup completi automatici del server, inclusi tutti i database. Questo backup consente di ricreare i dati in un momento specifico. I backup vengono pianificati automaticamente e vengono eseguiti una volta al giorno. Se è necessario eseguire il ripristino, è possibile ripristinare fino al numero di giorni specificati per la conservazione dei backup, fino al massimo di 35 giorni. Per specificare per quanto tempo devono essere conservati i backup:
- Nel portale di Azure, passa al tuo server flessibile di Azure Database per PostgreSQL.
- Nella sezione la Panoramica, selezionare la Configurazione.
- In Backup trovare periodo di conservazione dei backup (in giorni). La barra del dispositivo di scorrimento consente di selezionare il numero di giorni in cui si desidera conservare i backup.
- Selezionare Salva per conservare le modifiche.