Hello - First of all thanks for doing this. It's definitely a neat option to have. Unfortunately I haven't yet worked with ProstgreSQL 9.0. Could you please elaborate little bit more on how it works? What happens if master dies? Who is responsible for creating/deleting recovery.conf file?
Also please be more careful with quoting variables in your if statements. On Mon, Feb 7, 2011 at 5:19 AM, Takatoshi MATSUO <matsuo....@gmail.com> wrote: > Hello > > I wrote a patch for pgsql RA to manage PostgreSQL 9.0 streaming > replication(PGSR) > which is new feature in Postgres 9.0. > > I add new parameters, "rep_mode", "trigger_file" and "tmpdir". > > "rep_mode" means replication mode > Default is "none" which do the same thing as before. > You have to set "async" to use PGSR. > > "trigger_file" must be set same parameter of recovery.conf. > This file is created to promote hot standby to primary. > Default is /var/lib/pgsql/PGSQL.5432.trigger. > > "tmpdir" is temporary directory used for trigger_file and flag files. > Default is /var/lib/pgsql. > > > > * Details > > PGSR's transition differs from Pacemaker's one as follows. > > ******* transition of Pacemaker ****************************** > > start promote > ----------> ------------> > Stop Slave Master > <--------- <------------ > stop demote > > ************************************************************** > > ******* transition of PGSR *********************************** > > pg_ctl start > ------------------------------------------> > pg_ctl start create trigger_file > ---------------> ------------------------> > Stop Hot standby Primary > <---------------- > pg_ctl stop > <------------------------------------------ > pg_ctl stop > > Note > PostgreSQL developer says that it's not normal operation > to start primary through hot standby initially. > *************************************************************** > > Therefore this patch has 4 states as follows. > > STATE1 | STATE2 | STATE3 | STATE4 > Stop | Slave | Slave | Master <- Pacemaker's state > Stop | Stop | HotStandby | Primary <- PGSR's state > > > > The STATE2 is steppingstone to transit to the STATE4 > so primary's initial start transits as follows. > > STATE1 ---> STATE2 ---> STATE4 > start promote > > In the STATE2, PostgreSQL is stopping, so resource agent creates a flag > file($REPRESS_MONITOR) to cheat monitor operation, and waites for promote op. > > > * Method of starting > > You have to start only primary server's pacemaker with primary configuration > and waits for promote op (STATE4). > After that, you backup data from primary server and restore it > to hot standby server and starts hot standby server's pacemaker with > hot standby configuration. > > > * About repressing start flag file > > Hot standby server must be started with new restored data. > But if restored data is old, hot standby server fails to replication, > but resource > agent can't notice it. > At this time primary server is broken, hot standby server is promoted with > very > old data, so I bring in repressing start flag file($REPRESS_START) > to repress restarting PostgreSQL automatically with old data. > Therefore you have to backup and restore new data and remove this flag > before starting PostgreSQL if it exists. > > > How do you think these implementation ? > Any comment ? > > Regards, > Takatoshi MATSUO > Linux-HA Japan > > _______________________________________________________ > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ > > -- Serge Dubrouski. _______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
