[Pgpool-general] failback setup problem

[Tatsuo Ishii]

>>> >> I'm not sure what you are trying to do here. If "backup" means it was
>>> >> created by pg_dump_all, I don't think your approach works. Streaming
>>> >> replication requires a base backup(binary backup) which is managed by
>>> >> pg_start_backup/pg_stop_backup.
>>> >>
>>> >
>>> > Yes of course I have a backup created as described in
>>> >
>>> http://www.postgresql.org/docs/9.0/static/continuous-archiving.html#BACKUP-BASE-BACKUP
> 
> If you keep wal archives along with the base backup, then it should be
> possible to recover primary PostgreSQL from them of course. Question
> is, how to recover standbys. In my understanding you need to recreate
> them from the recovered primary anyway and it will require *new* base
> backup.
> 
>>> > My question is, what happens if both server failed somehow? Can I still
>>> use
>>> > pgpoolAdmin to recover a database server?
>>>
>>> No, pgpoolAdmin cannot recover a database server in this situation.
>>> You have to recover the database manualy.
>>>
>> Yes. I thought that of course.
>> So my question was, if you leave the whole restore process up to one called
>> recovery script - including optional checkpointing etc. pgpool would be more
>> flexible and simplier in terms of supporting different recovery procedures.
> 
> Good question. I will inspect current code if your idea is possible
> while updating docs.

Here are steps executed in recovery procedure (described in the updted
doc today). Note that CHECK POINT is not performed in the procedure.
If all PostgreSQL servers down case, you want to skip #1 and #2 and
want to execute #3, #4, #5 by ssh. What do you think?

   1. Pgpool-II connects to primary server's template1 database as
   user = recovery_user, password = recovery_password.

   2. Primary server executes pgpool_recovery function.

   3. pgpool_recovery function executes
   recovery_1st_stage_command. Note that PostgreSQL executes functions
   with database cluster as the current directory. Thus
   recovery_1st_stage_command is executed in the database cluster
   directory.

   4. Primary server executes pgpool_remote_start function. This
   function executes a script named "pgpool_remote_start" in the
   database cluster directory, and it executes pg_ctl command on the
   standby server to be recovered via ssh. pg_ctl will start
   postmaster in background. So we need to make sure that postmaster
   on the standby actually starts.

   5. pgpool-II tries to connect to the standby PostgreSQL as user =
   recovery_user and password = recovery_password. The database to be
   connected is "postgres" if possible. Otherwise "template1" is
   used. pgpool-II retries for recovery_timeout seconds. If success,
   go to next step.

   6. If failback_command is not empty, pgpool-II parent process
   executes the script.

   7. After failback_command finishes, pgpool-II restart all child
   processes.

>> By he way - where does pgpool actually store the information about
>> attached/detached servers?
> 
> On shared memory.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
> _______________________________________________
> Pgpool-general mailing list
> Pgpool-general at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/pgpool-general