I would like to develop function for 'Online base backup from the
hot-standby' in PostgreSQL 9.2.

Todo : Allow hot file system backups on standby servers

 * Make pg_basebackup to execute to the hot-standby server 
   and acquire online-base-backup .
     - pg_basebackup can be executed to only primary server in 
       PostgreSQL 9.1 .
     - But physical-copy(etc) under processing of pg_basebackup
       raises the load of primary server .
     - Therefore , this function is necessary .

(There is the following problems when hot-standby acquires 
 online-base-backup like executing pg_basebackup to the primary 
 server .)
 * pg_start_backup() and pg_stop_backup() can't be executed to the 
   hot-standby server .
     - hot-standby can't insert backup-end record to WAL-files and 
       can't operate CHECKPOINT .
        - Because hot-standby can't write anything in WAL-files .
 * hot-standby can't send WAL-files to archive server.
     - when pg_stop_backup() is executed to the primary server , 
       it waits for completing sending wal to archive server ,  
       but hot-standby can't do it.

(I create with the following Policy .)
     * This function doesn't affect primary server . 
        - I don't adopt the way which "hot-standby requests primary to
          execute pg_basebackup" , because I think about many standbys 
          is connected with a primary .

 * When pg_basebackup is executed to the hot-standby server , it 
   executes RESTARTPOINT instead of CHECKPOINT . 
   backup_label is made from the RESTARTPOINT's results , and is sent 
   to the designated backup server using pg_basebackup connection .
 * Instead of inserting backup-end record , hot-standby writes 
   backup-end-position in backup-history-file and sends to the 
   designated backup server using pg_basebackup connection .
    - In 9.1 , startup process knows backup-end-position from only 
      backup-end record . In addition to its logic, startup process 
      can know backup-end-position from backup-history-file . 
      As a result , startup process can recovery certainly 
      without backup-end record .

(As a result of the above-mentioned Policy and Approach , there is 
 the following restrictions .)
     * Immediately after backup starting of WAL must contain 
       full page writes . But the above-mentioned Approach can't satisfy 
       the restriction according to circumstances . Because 
       full_page_writes of primary might equal 'off' .
       When standby recovery WAL which is removed full page writes by pg_lesslog
       , it is the same .
     * Because recovery starts from last CHECKPOINT , it becomes long .
     * I has not thought new process that become taking the place of 
       waiting for completing sending wal to archive server , yet.

[Working Step]
 STEP1: Make startup process to acquire backup-end-position from 
        not only backup-end record but also backup-history-file .
          * startup process allows to acquire backup-end-position 
            from backup-history-file .
          * When pg_basebackup is executed , backup-history-file is 
            sent to the designated backup server .
 STEP2: Make pg_start_backup() and pg_stop_backup() to be executed 
        by the hot-standby server.
[Action until The first CommitFest (on June 15)]
I will create a patch to STEP1 .
(The patch will be able to settle a problem of Omnipitr-backup-slave.)
(a problem of Omnipitr-backup-slave : 
  * Shedule of creating STEP2 is the next CommitFest (in September 15) 

Jun Ishizuka
NTT Software Corporation
E-Mail: ishizuka....@po.ntts.co.jp

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to