Descrivere la registrazione write-ahead

  • 3 minuti

Quando si apportano modifiche nel database, ad esempio inserimenti o eliminazioni, queste modifiche vengono prima scritte in un log e solo dopo vengono scritte nei file dei dati sul disco. Questa operazione viene chiamata registrazione write-ahead perché le modifiche vengono scritte nel log prima che ne venga eseguito il commit sui file dei dati. Se si verifica un problema, ad esempio la perdita di alimentazione, il log conserva sempre i dati più recenti e può essere usato per assicurarsi che il database sia in uno stato coerente.

Un secondo vantaggio consiste nel fatto che, scrivendo le modifiche prima nel log, le modifiche a tabelle e a indici possono essere scritte in batch anziché singolarmente. Questo processo riduce il numero di scritture su disco necessarie per mantenere aggiornati gli indici e le tabelle. Le scritture nel log sono veloci perché vengono eseguite in sequenza. Le scritture nelle tabelle e negli indici, che sono più lente, possono essere eseguite in batch poiché 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 della registrazione write-ahead e di ottimizzarla per il carico di lavoro:

  • commit_delay: il ritardo tra il commit delle transazioni e lo scaricamento del log su disco.
  • wal_buffers: il numero di buffer di pagine del disco nella memoria condivisa per la registrazione write-ahead (WAL).
  • max_wal_size: la dimensione massima che può raggiungere il log write-ahead (WAL) prima di attivare un checkpoint automatico.
  • wal_writer_delay: intervallo di tempo tra gli scaricamenti del log write-ahead eseguiti dal writer WAL.
  • wal_compression: se le scritture di pagina completa nel file del log write-ahead sono compresse o meno.
  • wal_level: determina la quantità di informazioni scritte nel log write-ahead. I valori consentiti sono REPLICA o LOGICAL.

Ripristino temporizzato

Lo scopo principale del log write-ahead (WAL) è garantire la coerenza e la durabilità del database in caso di arresto anomalo. Con la versione locale di PostgreSQL è possibile usare il log come archivio in quanto consente di eseguire il ripristino in un momento preciso del 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 di un determinato momento. I backup vengono pianificati automaticamente e vengono eseguiti una volta al giorno. In caso di ripristino, è possibile ripristinare fino al numero di giorni specificati per la conservazione dei backup, per un massimo di 35 giorni. Per specificare il periodo di conservazione dei backup:

  1. Nel portale di Azure passare al server flessibile di Database di Azure per PostgreSQL.
  2. Nella sezione Panoramica selezionare Configurazione.
  3. In Backup trovare Periodo di conservazione backup (in giorni). La barra del dispositivo di scorrimento consente di selezionare il numero di giorni per cui si desidera conservare i backup.
  4. Selezionare Salva per rendere permanenti le modifiche.