Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Linux-HA>
  3. Dev
pgsql and streaming replcation
sergeyfd at gmail
Dec 4, 2011, 2:11 PM
Post #1 of 20 (6975 views)
Permalink
Hello -

Takatoshi MATSUO did a tremendous job on implementing support for streaming
replication feature in pgsql RA. Also it looks like PostgeSQL 9.1 has all
necessary interfaces to successfully implement Pacemaker's M/S concept. So
I think it's time to start discussion on how to merge Takatoshi's work into
pgsql RA baseline. Here is the link to Takatoshi's GitHUB if somebody wants
to test his RA:

https://github.com/t-matsuo/

So far I tested it for backward compatibility in a standard non-replication
mode and also tested M/S model and found no real issues. Though it
definitely requires some more polishing and testing.

Takatoshi, here are some changes that I want to discuss with you:

1. Is it possible to add a check for PostgreSQL version and fail with
OCF_ERR_INSTALLED when one tries to start replication on version less than
9.1? A simple cat on PG_VERSION with some analysis would probably do.

2. I think that following lines should be moved from pgsql_start to
pgsql_validate_all

535 # Check whether tmpdir is readable by pgdba user
536 if ! runasowner "test -r $OCF_RESKEY_tmpdir"; then
537 ocf_log err "Directory $OCF_RESKEY_tmpdir is not readable by
$OCF_RESKEY_pgdba"
538 return $OCF_ERR_PERM
539 fi

3. I don't really like this part of pgsql_real_monitor:

775 if ! is_replication; then
776 OCF_RESKEY_monitor_sql=`escape_string
"$OCF_RESKEY_monitor_sql"`
777 runasowner -q $loglevel "$OCF_RESKEY_psql $psql_options -c
'$OCF_RESKEY_monitor_sql'"
778 rc=$?
779 else
780 output=`su $OCF_RESKEY_pgdba -c "cd $OCF_RESKEY_pgdata;
$OCF_RESKEY_psql $psql_options -Atc \"${CHECK_MS_SQL}\""`
781 rc=$?
782 fi


I think that functional monitor (the one that uses monitor_sql) should run
always independently of DB mode since its primary role is to check data and
fail if it's not correct or corrupted. In replication mode there should be
additional monitoring. Other way it misleads customer on a usage of
monitor_sql.

4. You already populate several attributes with crm_attribute. Does it make
sense to populate a name of a Master node in promote function and use it
later on instead of running crm_mon on each monitor command?

5. It also requires some changes in terms of a proper English but we can go
through it later.

And yet again thanks for a brilliant work.

Florian, Dejan how would you like to merge a patch when we are ready? The
patch will be rather big one and AFAIK you have some policy on the amount
of changes for one patch.


--
Serge Dubrouski.
Re: pgsql and streaming replcation [ In reply to ]
florian at hastexo
Dec 5, 2011, 12:22 AM
Post #2 of 20 (6916 views)
Permalink
On Sun, Dec 4, 2011 at 11:11 PM, Serge Dubrouski <sergeyfd@gmail.com> wrote:
> Florian, Dejan how would you like to merge a patch when we are ready? The
> patch will be rather big one and AFAIK you have some policy on the amount of
> changes for one patch.

If it's a big addition of functionality, then a big patch is expected.
However please make sure that you do one patch per functional change.
Also, don't mix functional changes with "cleanup" work like fixing
whitespace, correcting incorrectly advertised resource parameters,
etc. It's acceptable to mix those in with the same pull request, but
they should be in separate changesets so we can easily bisect any
arising issues.

Other than that, I guess Dejan will agree with me that your PostgreSQL
expertise is way better than his and mine. So if you greenlight the
feature addition functionally we're unlikely to second-guess you on
that.

Does this help?
Cheers,
Florian
_______________________________________________________
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/
Re: pgsql and streaming replcation [ In reply to ]
cbowlby at tenthpowertech
Dec 5, 2011, 4:40 AM
Post #3 of 20 (6920 views)
Permalink
Hi Florian/Serge,

I can offer any insights into PostgreSQL as well, as I've been actively
using and support it since 2001/2002.

On 12/05/2011 04:22 AM, Florian Haas wrote:
> On Sun, Dec 4, 2011 at 11:11 PM, Serge Dubrouski<sergeyfd@gmail.com> wrote:
>> Florian, Dejan how would you like to merge a patch when we are ready? The
>> patch will be rather big one and AFAIK you have some policy on the amount of
>> changes for one patch.
> If it's a big addition of functionality, then a big patch is expected.
> However please make sure that you do one patch per functional change.
> Also, don't mix functional changes with "cleanup" work like fixing
> whitespace, correcting incorrectly advertised resource parameters,
> etc. It's acceptable to mix those in with the same pull request, but
> they should be in separate changesets so we can easily bisect any
> arising issues.
>
> Other than that, I guess Dejan will agree with me that your PostgreSQL
> expertise is way better than his and mine. So if you greenlight the
> feature addition functionally we're unlikely to second-guess you on
> that.
>
> Does this help?
> Cheers,
> Florian
> _______________________________________________________
> 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/

_______________________________________________________
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/
Re: pgsql and streaming replcation [ In reply to ]
sergeyfd at gmail
Dec 5, 2011, 6:24 AM
Post #4 of 20 (6920 views)
Permalink
Chris -

The best way you can help us is to test new RA as much as possible and in
all possible modes. I mean regular and streaming replcation.

On Mon, Dec 5, 2011 at 5:40 AM, Chris Bowlby <cbowlby@tenthpowertech.com>wrote:

> Hi Florian/Serge,
>
> I can offer any insights into PostgreSQL as well, as I've been actively
> using and support it since 2001/2002.
>
> On 12/05/2011 04:22 AM, Florian Haas wrote:
> > On Sun, Dec 4, 2011 at 11:11 PM, Serge Dubrouski<sergeyfd@gmail.com>
> wrote:
> >> Florian, Dejan how would you like to merge a patch when we are ready?
> The
> >> patch will be rather big one and AFAIK you have some policy on the
> amount of
> >> changes for one patch.
> > If it's a big addition of functionality, then a big patch is expected.
> > However please make sure that you do one patch per functional change.
> > Also, don't mix functional changes with "cleanup" work like fixing
> > whitespace, correcting incorrectly advertised resource parameters,
> > etc. It's acceptable to mix those in with the same pull request, but
> > they should be in separate changesets so we can easily bisect any
> > arising issues.
> >
> > Other than that, I guess Dejan will agree with me that your PostgreSQL
> > expertise is way better than his and mine. So if you greenlight the
> > feature addition functionally we're unlikely to second-guess you on
> > that.
> >
> > Does this help?
> > Cheers,
> > Florian
> > _______________________________________________________
> > 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/
>
> _______________________________________________________
> 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.
Re: pgsql and streaming replcation [ In reply to ]
cbowlby at tenthpowertech
Dec 5, 2011, 6:29 AM
Post #5 of 20 (6917 views)
Permalink
Hi Serge,

As soon as I can get some time to do so I will see what I can drum up
in the way of some testing.

On 12/05/2011 10:24 AM, Serge Dubrouski wrote:
> Chris -
> The best way you can help us is to test new RA as much as possible and
> in all possible modes. I mean regular and streaming replcation.
>
> On Mon, Dec 5, 2011 at 5:40 AM, Chris Bowlby
> <cbowlby@tenthpowertech.com <mailto:cbowlby@tenthpowertech.com>> wrote:
>
> Hi Florian/Serge,
>
> I can offer any insights into PostgreSQL as well, as I've been
> actively
> using and support it since 2001/2002.
>
> On 12/05/2011 04:22 AM, Florian Haas wrote:
> > On Sun, Dec 4, 2011 at 11:11 PM, Serge
> Dubrouski<sergeyfd@gmail.com <mailto:sergeyfd@gmail.com>> wrote:
> >> Florian, Dejan how would you like to merge a patch when we are
> ready? The
> >> patch will be rather big one and AFAIK you have some policy on
> the amount of
> >> changes for one patch.
> > If it's a big addition of functionality, then a big patch is
> expected.
> > However please make sure that you do one patch per functional
> change.
> > Also, don't mix functional changes with "cleanup" work like fixing
> > whitespace, correcting incorrectly advertised resource parameters,
> > etc. It's acceptable to mix those in with the same pull request, but
> > they should be in separate changesets so we can easily bisect any
> > arising issues.
> >
> > Other than that, I guess Dejan will agree with me that your
> PostgreSQL
> > expertise is way better than his and mine. So if you greenlight the
> > feature addition functionally we're unlikely to second-guess you on
> > that.
> >
> > Does this help?
> > Cheers,
> > Florian
> > _______________________________________________________
> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> <mailto:Linux-HA-Dev@lists.linux-ha.org>
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> > Home Page: http://linux-ha.org/
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> <mailto: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.
Re: pgsql and streaming replcation [ In reply to ]
matsuo.tak at gmail
Dec 5, 2011, 8:15 PM
Post #6 of 20 (6971 views)
Permalink
Hello Serge

Serge Dubrouski <sergeyfd@gmail.com>:
> Hello -
>
> Takatoshi MATSUO did a tremendous job on implementing support for streaming
> replication feature in pgsql RA. Also it looks like PostgeSQL 9.1 has all
> necessary interfaces to successfully implement Pacemaker's M/S concept. So
> I think it's time to start discussion on how to merge Takatoshi's work into
> pgsql RA baseline. Here is the link to Takatoshi's GitHUB if somebody wants
> to test his RA:
>
> https://github.com/t-matsuo/
>
> So far I tested it for backward compatibility in a standard non-replication
> mode and also tested M/S model and found no real issues. Though it
> definitely requires some more polishing and testing.
>
> Takatoshi, here are some changes that I want to discuss with you:
>
> 1. Is it possible to add a check for PostgreSQL version and fail with
> OCF_ERR_INSTALLED when one tries to start replication on version less than
> 9.1? A simple cat on PG_VERSION with some analysis would probably do.

I'll add a check.

> 2. I think that following lines should be moved from pgsql_start to
> pgsql_validate_all
>
> 535 # Check whether tmpdir is readable by pgdba user
> 536 if ! runasowner "test -r $OCF_RESKEY_tmpdir"; then
> 537 ocf_log err "Directory $OCF_RESKEY_tmpdir is not readable by
> $OCF_RESKEY_pgdba"
> 538 return $OCF_ERR_PERM
> 539 fi

Thanks. I think so too.
I'll fix it.

> 3. I don't really like this part of pgsql_real_monitor:
>
> 775 if ! is_replication; then
> 776 OCF_RESKEY_monitor_sql=`escape_string > "$OCF_RESKEY_monitor_sql"`
> 777 runasowner -q $loglevel "$OCF_RESKEY_psql $psql_options -c > '$OCF_RESKEY_monitor_sql'"
> 778 rc=$?
> 779 else
> 780 output=`su $OCF_RESKEY_pgdba -c "cd $OCF_RESKEY_pgdata; > $OCF_RESKEY_psql $psql_options -Atc \"${CHECK_MS_SQL}\""`
> 781 rc=$?
> 782 fi
>
> I think that functional monitor (the one that uses monitor_sql) should run
> always independently of DB mode since its primary role is to check data and
> fail if it's not correct or corrupted. In replication mode there should be
> additional monitoring. Other way it misleads customer on a usage of
> monitor_sql.

All right.

Does it need to execute "select now();" if monitor_sql parameter is empty?
I think it's unnecessary.

> 4. You already populate several attributes with crm_attribute. Does it make
> sense to populate a name of a Master node in promote function and use it
> later on instead of running crm_mon on each monitor command?
>

Do you mean that you don't want to use crm_mon in monitor?

> 5. It also requires some changes in terms of a proper English but we can go
> through it later.

I hope your help.

>
> And yet again thanks for a brilliant work.
>
Thank you for the compliment.

> Florian, Dejan how would you like to merge a patch when we are ready? The
> patch will be rather big one and AFAIK you have some policy on the amount of
> changes for one patch.
>
>
> --
> Serge Dubrouski.

--
Regards,
Takatoshi MATSUO
_______________________________________________________
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/
Re: pgsql and streaming replcation [ In reply to ]
sergeyfd at gmail
Dec 7, 2011, 4:49 PM
Post #7 of 20 (6909 views)
Permalink
On Mon, Dec 5, 2011 at 9:15 PM, Takatoshi MATSUO <matsuo.tak@gmail.com>wrote:

> Hello Serge
>
> Serge Dubrouski <sergeyfd@gmail.com>:
> > Hello -
> >
> > Takatoshi MATSUO did a tremendous job on implementing support for
> streaming
> > replication feature in pgsql RA. Also it looks like PostgeSQL 9.1 has all
> > necessary interfaces to successfully implement Pacemaker's M/S concept.
> So
> > I think it's time to start discussion on how to merge Takatoshi's work
> into
> > pgsql RA baseline. Here is the link to Takatoshi's GitHUB if somebody
> wants
> > to test his RA:
> >
> > https://github.com/t-matsuo/
> >
> > So far I tested it for backward compatibility in a standard
> non-replication
> > mode and also tested M/S model and found no real issues. Though it
> > definitely requires some more polishing and testing.
> >
> > Takatoshi, here are some changes that I want to discuss with you:
> >
> > 1. Is it possible to add a check for PostgreSQL version and fail with
> > OCF_ERR_INSTALLED when one tries to start replication on version less
> than
> > 9.1? A simple cat on PG_VERSION with some analysis would probably do.
>
> I'll add a check.
>
> > 2. I think that following lines should be moved from pgsql_start to
> > pgsql_validate_all
> >
> > 535 # Check whether tmpdir is readable by pgdba user
> > 536 if ! runasowner "test -r $OCF_RESKEY_tmpdir"; then
> > 537 ocf_log err "Directory $OCF_RESKEY_tmpdir is not readable by
> > $OCF_RESKEY_pgdba"
> > 538 return $OCF_ERR_PERM
> > 539 fi
>
> Thanks. I think so too.
> I'll fix it.
>
>
On a second thought I'm not sure why we need that parameter and directory
at all. Why not to create rep_mode.conf, PGSQL.lock and xlog.note in
$OCF_RESKEY_pgdata ? What problems it can create? One more advantage to do
it in $OCF_RESKEY_pgdata is an ability to handle more than PostgreSQL
instance on the same server without a need for additional temp directories.

Also I think it would be good if RA was able to take care of adding
"include $WHATEVER_DIR/rep_mode.conf" in postgresql.conf. It will make the
RA self sustainable. In a current situation admin has add that directive
manually. RA though can something like this in a start function for
replication mode:

if ! grep -i "include $WHATEVER_DIR/rep_mode.conf" $OCF_RESKEY_config
then
echo "include $WHATEVER_DIR/rep_mode.conf" >> $OCF_RESKEY_config
fi

Don't know if it makes sense to remove it on stop.

> 3. I don't really like this part of pgsql_real_monitor:
> >
> > 775 if ! is_replication; then
> > 776 OCF_RESKEY_monitor_sql=`escape_string >
> "$OCF_RESKEY_monitor_sql"`
> > 777 runasowner -q $loglevel "$OCF_RESKEY_psql $psql_options -c
> > '$OCF_RESKEY_monitor_sql'"
> > 778 rc=$?
> > 779 else
> > 780 output=`su $OCF_RESKEY_pgdba -c "cd $OCF_RESKEY_pgdata; >
> $OCF_RESKEY_psql $psql_options -Atc \"${CHECK_MS_SQL}\""`
> > 781 rc=$?
> > 782 fi
> >
> > I think that functional monitor (the one that uses monitor_sql) should
> run
> > always independently of DB mode since its primary role is to check data
> and
> > fail if it's not correct or corrupted. In replication mode there should
> be
> > additional monitoring. Other way it misleads customer on a usage of
> > monitor_sql.
>
> All right.
>
> Does it need to execute "select now();" if monitor_sql parameter is empty?
> I think it's unnecessary.
>

For a case of an empty parameter you are right and running "select now()"
probably unnecessary, Non-empty monitro_sql shall be executed in my opinion.


>
> > 4. You already populate several attributes with crm_attribute. Does it
> make
> > sense to populate a name of a Master node in promote function and use it
> > later on instead of running crm_mon on each monitor command?
> >
>
> Do you mean that you don't want to use crm_mon in monitor?
>

I prefer to have as few dependencies on external programs as possible.
Using crm_attribute to communicate the name of a master node would be
consistent with the rest of the script since you already use it for
communicating state of the nodes. If you prefer using crm_mon than you have
to add a check that that binary exists on the server. In 99.99% of the case
it will but still the check is necessary I think.


>
> > 5. It also requires some changes in terms of a proper English but we can
> go
> > through it later.
>
> I hope your help.
>

Will do.


>
> >
> > And yet again thanks for a brilliant work.
> >
> Thank you for the compliment.
>
> > Florian, Dejan how would you like to merge a patch when we are ready? The
> > patch will be rather big one and AFAIK you have some policy on the
> amount of
> > changes for one patch.
> >
> >
> > --
> > Serge Dubrouski.
>
> --
> Regards,
> Takatoshi MATSUO
> _______________________________________________________
> 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.
Re: pgsql and streaming replcation [ In reply to ]
matsuo.tak at gmail
Dec 8, 2011, 9:04 PM
Post #8 of 20 (6951 views)
Permalink
Hello Serge

2011/12/8 Serge Dubrouski <sergeyfd@gmail.com>:
>
>
> On Mon, Dec 5, 2011 at 9:15 PM, Takatoshi MATSUO <matsuo.tak@gmail.com>
> wrote:
>>
>> Hello Serge
>>
>> Serge Dubrouski <sergeyfd@gmail.com>:
>> > Hello -
>> >
>> > Takatoshi MATSUO did a tremendous job on implementing support for
>> > streaming
>> > replication feature in pgsql RA. Also it looks like PostgeSQL 9.1 has
>> > all
>> > necessary interfaces to successfully implement Pacemaker's M/S concept.
>> > So
>> > I think it's time to start discussion on how to merge Takatoshi's work
>> > into
>> > pgsql RA baseline. Here is the link to Takatoshi's GitHUB if somebody
>> > wants
>> > to test his RA:
>> >
>> > https://github.com/t-matsuo/
>> >
>> > So far I tested it for backward compatibility in a standard
>> > non-replication
>> > mode and also tested M/S model and found no real issues. Though it
>> > definitely requires some more polishing and testing.
>> >
>> > Takatoshi, here are some changes that I want to discuss with you:
>> >
>> > 1. Is it possible to add a check for PostgreSQL version and fail with
>> > OCF_ERR_INSTALLED when one tries to start replication on version less
>> > than
>> > 9.1? A simple cat on PG_VERSION with some analysis would probably do.
>>
>> I'll add a check.

I added a check.
https://github.com/t-matsuo/resource-agents/commit/3ab7cfdcce118043cd149b348740e50e7a946eb3

>>
>> > 2. I think that following lines should be moved from pgsql_start to
>> > pgsql_validate_all
>> >
>> > 535 # Check whether tmpdir is readable by pgdba user
>> > 536 if ! runasowner "test -r $OCF_RESKEY_tmpdir"; then
>> > 537 ocf_log err "Directory $OCF_RESKEY_tmpdir is not readable
>> > by
>> > $OCF_RESKEY_pgdba"
>> > 538 return $OCF_ERR_PERM
>> > 539 fi
>>
>> Thanks. I think so too.
>> I'll fix it.
>>

I fixed it and I deleted a check for tmpdir existence
because the checking for permittion fills the role.
https://github.com/t-matsuo/resource-agents/commit/82d4939486bcca429e2deb804d7faf756099bb59


> On a second thought I'm not sure why we need that parameter and directory at
> all. Why not to create rep_mode.conf, PGSQL.lock and xlog.note in
> $OCF_RESKEY_pgdata ? What problems it can create?
>
> One more advantage to do
> it in $OCF_RESKEY_pgdata is an ability to handle more than PostgreSQL
> instance on the same server without a need for additional temp directories.

When backup is needed, customers may backup these files and restore it.
It may cause problems.
Specially PGSQL.lock causes an error on start.

I think that they should be treated as a separate thing.
because they are independent from PostgreSQL's data.


Incidentally I considered to handle more than PostgreSQL instance.
Initially I added port number to these filenames, but I deleted it
to simplify filenames.
https://github.com/t-matsuo/resource-agents/commit/b16faf2d797200048dc0fc07a45b6751cf5be190


> Also I think it would be good if RA was able to take care of adding "include
> $WHATEVER_DIR/rep_mode.conf" in postgresql.conf. It will make the RA self
> sustainable. In a current situation admin has add that directive manually.
> RA though can something like this in a start function for replication mode:
>
> if ! grep -i "include $WHATEVER_DIR/rep_mode.conf" $OCF_RESKEY_config
> then
> echo "include $WHATEVER_DIR/rep_mode.conf" >> $OCF_RESKEY_config
> fi

Sounds good.

> Don't know if it makes sense to remove it on stop.

I think it doesn't make sense to remove it,
because rep_mode.conf becomes empty on stop.


>> > 3. I don't really like this part of pgsql_real_monitor:
>> >
>> > 775 if ! is_replication; then
>> > 776 OCF_RESKEY_monitor_sql=`escape_string >
>> > "$OCF_RESKEY_monitor_sql"`
>> > 777 runasowner -q $loglevel "$OCF_RESKEY_psql $psql_options -c
>> > > '$OCF_RESKEY_monitor_sql'"
>> > 778 rc=$?
>> > 779 else
>> > 780 output=`su $OCF_RESKEY_pgdba -c "cd $OCF_RESKEY_pgdata; >
>> > $OCF_RESKEY_psql $psql_options -Atc \"${CHECK_MS_SQL}\""`
>> > 781 rc=$?
>> > 782 fi
>> >
>> > I think that functional monitor (the one that uses monitor_sql) should
>> > run
>> > always independently of DB mode since its primary role is to check data
>> > and
>> > fail if it's not correct or corrupted. In replication mode there should
>> > be
>> > additional monitoring. Other way it misleads customer on a usage of
>> > monitor_sql.
>>
>> All right.
>>
>> Does it need to execute "select now();" if monitor_sql parameter is empty?
>> I think it's unnecessary.
>
>
> For a case of an empty parameter you are right and running "select now()"
> probably unnecessary, Non-empty monitro_sql shall be executed in my opinion.
>
>>
>>
>> > 4. You already populate several attributes with crm_attribute. Does it
>> > make
>> > sense to populate a name of a Master node in promote function and use it
>> > later on instead of running crm_mon on each monitor command?
>> >
>>
>> Do you mean that you don't want to use crm_mon in monitor?
>
>
> I prefer to have as few dependencies on external programs as possible.

Agree.

> Using crm_attribute to communicate the name of a master node would be
> consistent with the rest of the script since you already use it for
> communicating state of the nodes. If you prefer using crm_mon than you have
> to add a check that that binary exists on the server. In 99.99% of the case
> it will but still the check is necessary I think.

I use crm_mon to check for node existence and node online too.
It is impossible to get it from attribute, so I prefer to using crm_mon.

Do I have to add a check for crm_master, crm_attribute, crm_failcount too?


>>
>>
>> > 5. It also requires some changes in terms of a proper English but we can
>> > go
>> > through it later.
>>
>> I hope your help.
>
>
> Will do.
>
>>
>>
>> >
>> > And yet again thanks for a brilliant work.
>> >
>> Thank you for the compliment.
>>
>> > Florian, Dejan how would you like to merge a patch when we are ready?
>> > The
>> > patch will be rather big one and AFAIK you have some policy on the
>> > amount of
>> > changes for one patch.


Regards,
Takatoshi MATSUO
_______________________________________________________
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/
Re: pgsql and streaming replcation [ In reply to ]
sergeyfd at gmail
Dec 11, 2011, 9:38 AM
Post #9 of 20 (6895 views)
Permalink
On Thu, Dec 8, 2011 at 10:04 PM, Takatoshi MATSUO <matsuo.tak@gmail.com>wrote:

> Hello Serge
>
> 2011/12/8 Serge Dubrouski <sergeyfd@gmail.com>:
> >
> >
> > On Mon, Dec 5, 2011 at 9:15 PM, Takatoshi MATSUO <matsuo.tak@gmail.com>
> > wrote:
> >>
> >> Hello Serge
> >>
> >> Serge Dubrouski <sergeyfd@gmail.com>:
> >> > Hello -
> >> >
> >> > Takatoshi MATSUO did a tremendous job on implementing support for
> >> > streaming
> >> > replication feature in pgsql RA. Also it looks like PostgeSQL 9.1 has
> >> > all
> >> > necessary interfaces to successfully implement Pacemaker's M/S
> concept.
> >> > So
> >> > I think it's time to start discussion on how to merge Takatoshi's work
> >> > into
> >> > pgsql RA baseline. Here is the link to Takatoshi's GitHUB if somebody
> >> > wants
> >> > to test his RA:
> >> >
> >> > https://github.com/t-matsuo/
> >> >
> >> > So far I tested it for backward compatibility in a standard
> >> > non-replication
> >> > mode and also tested M/S model and found no real issues. Though it
> >> > definitely requires some more polishing and testing.
> >> >
> >> > Takatoshi, here are some changes that I want to discuss with you:
> >> >
> >> > 1. Is it possible to add a check for PostgreSQL version and fail with
> >> > OCF_ERR_INSTALLED when one tries to start replication on version less
> >> > than
> >> > 9.1? A simple cat on PG_VERSION with some analysis would probably do.
> >>
> >> I'll add a check.
>
> I added a check.
>
> https://github.com/t-matsuo/resource-agents/commit/3ab7cfdcce118043cd149b348740e50e7a946eb3
>
> >>
> >> > 2. I think that following lines should be moved from pgsql_start to
> >> > pgsql_validate_all
> >> >
> >> > 535 # Check whether tmpdir is readable by pgdba user
> >> > 536 if ! runasowner "test -r $OCF_RESKEY_tmpdir"; then
> >> > 537 ocf_log err "Directory $OCF_RESKEY_tmpdir is not readable
> >> > by
> >> > $OCF_RESKEY_pgdba"
> >> > 538 return $OCF_ERR_PERM
> >> > 539 fi
> >>
> >> Thanks. I think so too.
> >> I'll fix it.
> >>
>
> I fixed it and I deleted a check for tmpdir existence
> because the checking for permittion fills the role.
>
> https://github.com/t-matsuo/resource-agents/commit/82d4939486bcca429e2deb804d7faf756099bb59
>
>
> > On a second thought I'm not sure why we need that parameter and
> directory at
> > all. Why not to create rep_mode.conf, PGSQL.lock and xlog.note in
> > $OCF_RESKEY_pgdata ? What problems it can create?
> >
> > One more advantage to do
> > it in $OCF_RESKEY_pgdata is an ability to handle more than PostgreSQL
> > instance on the same server without a need for additional temp
> directories.
>
> When backup is needed, customers may backup these files and restore it.
> It may cause problems.
> Specially PGSQL.lock causes an error on start.
>
> I think that they should be treated as a separate thing.
> because they are independent from PostgreSQL's data.
>

Ok. Then may be it should default to something like
${OCF_RESKEY_pgdata}/temp and RA should create it and set the right
ownership and permissions if it doesn't exist? And again may be in this
case we don't need that parameter?



>
> Incidentally I considered to handle more than PostgreSQL instance.
> Initially I added port number to these filenames, but I deleted it
> to simplify filenames.
>
> https://github.com/t-matsuo/resource-agents/commit/b16faf2d797200048dc0fc07a45b6751cf5be190
>
>
> > Also I think it would be good if RA was able to take care of adding
> "include
> > $WHATEVER_DIR/rep_mode.conf" in postgresql.conf. It will make the RA self
> > sustainable. In a current situation admin has add that directive
> manually.
> > RA though can something like this in a start function for replication
> mode:
> >
> > if ! grep -i "include $WHATEVER_DIR/rep_mode.conf" $OCF_RESKEY_config
> > then
> > echo "include $WHATEVER_DIR/rep_mode.conf" >> $OCF_RESKEY_config
> > fi
>
> Sounds good.
>
> > Don't know if it makes sense to remove it on stop.
>
> I think it doesn't make sense to remove it,
> because rep_mode.conf becomes empty on stop.
>

The only problem here if admin changes temp_dir parameter but doesn't
delete records from postgres.conf. We could end up with several include
records then or with records pointing to the non existing files.



> >> > 3. I don't really like this part of pgsql_real_monitor:
> >> >
> >> > 775 if ! is_replication; then
> >> > 776 OCF_RESKEY_monitor_sql=`escape_string >
> >> > "$OCF_RESKEY_monitor_sql"`
> >> > 777 runasowner -q $loglevel "$OCF_RESKEY_psql $psql_options
> -c
> >> > > '$OCF_RESKEY_monitor_sql'"
> >> > 778 rc=$?
> >> > 779 else
> >> > 780 output=`su $OCF_RESKEY_pgdba -c "cd $OCF_RESKEY_pgdata; >
> >> > $OCF_RESKEY_psql $psql_options -Atc \"${CHECK_MS_SQL}\""`
> >> > 781 rc=$?
> >> > 782 fi
> >> >
> >> > I think that functional monitor (the one that uses monitor_sql) should
> >> > run
> >> > always independently of DB mode since its primary role is to check
> data
> >> > and
> >> > fail if it's not correct or corrupted. In replication mode there
> should
> >> > be
> >> > additional monitoring. Other way it misleads customer on a usage of
> >> > monitor_sql.
> >>
> >> All right.
> >>
> >> Does it need to execute "select now();" if monitor_sql parameter is
> empty?
> >> I think it's unnecessary.
> >
> >
> > For a case of an empty parameter you are right and running "select now()"
> > probably unnecessary, Non-empty monitro_sql shall be executed in my
> opinion.
> >
> >>
> >>
> >> > 4. You already populate several attributes with crm_attribute. Does it
> >> > make
> >> > sense to populate a name of a Master node in promote function and use
> it
> >> > later on instead of running crm_mon on each monitor command?
> >> >
> >>
> >> Do you mean that you don't want to use crm_mon in monitor?
> >
> >
> > I prefer to have as few dependencies on external programs as possible.
>
> Agree.
>
> > Using crm_attribute to communicate the name of a master node would be
> > consistent with the rest of the script since you already use it for
> > communicating state of the nodes. If you prefer using crm_mon than you
> have
> > to add a check that that binary exists on the server. In 99.99% of the
> case
> > it will but still the check is necessary I think.
>
> I use crm_mon to check for node existence and node online too.
> It is impossible to get it from attribute, so I prefer to using crm_mon.
>
> Do I have to add a check for crm_master, crm_attribute, crm_failcount too?
>
>
That's a different interesting topic. What is the reason for doing this?

my_fail_count=`$CRM_FAILCOUNT -r $OCF_RESOURCE_INSTANCE -N $HOSTNAME -G -Q
| sed "s/INFINITY/1000000/g"`
if [ "$my_fail_count" != "0" ]; then
ocf_log info "I don't start PostgreSQL on post-demote because of my
fail-count=$my_fail_count."
return $OCF_SUCCESS
fi

Why not to leave pacemaker to do its job on managing failcounts?



>
> >>
> >>
> >> > 5. It also requires some changes in terms of a proper English but we
> can
> >> > go
> >> > through it later.
> >>
> >> I hope your help.
> >
> >
> > Will do.
> >
> >>
> >>
> >> >
> >> > And yet again thanks for a brilliant work.
> >> >
> >> Thank you for the compliment.
> >>
> >> > Florian, Dejan how would you like to merge a patch when we are ready?
> >> > The
> >> > patch will be rather big one and AFAIK you have some policy on the
> >> > amount of
> >> > changes for one patch.
>
>
> Regards,
> Takatoshi MATSUO
> _______________________________________________________
> 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.
Re: pgsql and streaming replcation [ In reply to ]
matsuo.tak at gmail
Dec 12, 2011, 3:28 AM
Post #10 of 20 (6894 views)
Permalink
Hello Serge

2011/12/12 Serge Dubrouski <sergeyfd@gmail.com>:
>
>
> On Thu, Dec 8, 2011 at 10:04 PM, Takatoshi MATSUO <matsuo.tak@gmail.com>
> wrote:
>>
>> Hello Serge
>>
>> 2011/12/8 Serge Dubrouski <sergeyfd@gmail.com>:
>> >
>> >
>> > On Mon, Dec 5, 2011 at 9:15 PM, Takatoshi MATSUO <matsuo.tak@gmail.com>
>> > wrote:
>> >>
>> >> Hello Serge
>> >>
>> >> Serge Dubrouski <sergeyfd@gmail.com>:
>> >> > Hello -
>> >> >
>> >> > Takatoshi MATSUO did a tremendous job on implementing support for
>> >> > streaming
>> >> > replication feature in pgsql RA. Also it looks like PostgeSQL 9.1 has
>> >> > all
>> >> > necessary interfaces to successfully implement Pacemaker's M/S
>> >> > concept.
>> >> > So
>> >> > I think it's time to start discussion on how to merge Takatoshi's
>> >> > work
>> >> > into
>> >> > pgsql RA baseline. Here is the link to Takatoshi's GitHUB if somebody
>> >> > wants
>> >> > to test his RA:
>> >> >
>> >> > https://github.com/t-matsuo/
>> >> >
>> >> > So far I tested it for backward compatibility in a standard
>> >> > non-replication
>> >> > mode and also tested M/S model and found no real issues. Though it
>> >> > definitely requires some more polishing and testing.
>> >> >
>> >> > Takatoshi, here are some changes that I want to discuss with you:
>> >> >
>> >> > 1. Is it possible to add a check for PostgreSQL version and fail with
>> >> > OCF_ERR_INSTALLED when one tries to start replication on version less
>> >> > than
>> >> > 9.1? A simple cat on PG_VERSION with some analysis would probably do.
>> >>
>> >> I'll add a check.
>>
>> I added a check.
>>
>> https://github.com/t-matsuo/resource-agents/commit/3ab7cfdcce118043cd149b348740e50e7a946eb3
>>
>> >>
>> >> > 2. I think that following lines should be moved from pgsql_start to
>> >> > pgsql_validate_all
>> >> >
>> >> > 535 # Check whether tmpdir is readable by pgdba user
>> >> > 536 if ! runasowner "test -r $OCF_RESKEY_tmpdir"; then
>> >> > 537 ocf_log err "Directory $OCF_RESKEY_tmpdir is not
>> >> > readable
>> >> > by
>> >> > $OCF_RESKEY_pgdba"
>> >> > 538 return $OCF_ERR_PERM
>> >> > 539 fi
>> >>
>> >> Thanks. I think so too.
>> >> I'll fix it.
>> >>
>>
>> I fixed it and I deleted a check for tmpdir existence
>> because the checking for permittion fills the role.
>>
>> https://github.com/t-matsuo/resource-agents/commit/82d4939486bcca429e2deb804d7faf756099bb59
>>
>>
>> > On a second thought I'm not sure why we need that parameter and
>> > directory at
>> > all. Why not to create rep_mode.conf, PGSQL.lock and xlog.note in
>> > $OCF_RESKEY_pgdata ? What problems it can create?
>> >
>> > One more advantage to do
>> > it in $OCF_RESKEY_pgdata is an ability to handle more than PostgreSQL
>> > instance on the same server without a need for additional temp
>> > directories.
>>
>> When backup is needed, customers may backup these files and restore it.
>> It may cause problems.
>> Specially PGSQL.lock causes an error on start.
>>
>> I think that they should be treated as a separate thing.
>> because they are independent from PostgreSQL's data.
>
>
> Ok. Then may be it should default to something like
> ${OCF_RESKEY_pgdata}/temp and RA should create it and set the right
> ownership and permissions if it doesn't exist? And again may be in this case
> we don't need that parameter?
>

I agree that RA creates it and sets the right ownership and permissions.
But considering backup using tar command, I think it's not better to create it
under $OCF_RESKEY_pgdata.

According to "Filesystem Hierarchy Standard"
it's better to use /var/lib/somewhere.

http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION,

Then I designed using /var/lig/[RA Name] (=/var/lib/pgsql).
What do you think?

>>
>>
>> Incidentally I considered to handle more than PostgreSQL instance.
>> Initially I added port number to these filenames, but I deleted it
>> to simplify filenames.
>>
>> https://github.com/t-matsuo/resource-agents/commit/b16faf2d797200048dc0fc07a45b6751cf5be190
>>
>>
>> > Also I think it would be good if RA was able to take care of adding
>> > "include
>> > $WHATEVER_DIR/rep_mode.conf" in postgresql.conf. It will make the RA
>> > self
>> > sustainable. In a current situation admin has add that directive
>> > manually.
>> > RA though can something like this in a start function for replication
>> > mode:
>> >
>> > if ! grep -i "include $WHATEVER_DIR/rep_mode.conf" $OCF_RESKEY_config
>> > then
>> > echo "include $WHATEVER_DIR/rep_mode.conf" >> $OCF_RESKEY_config
>> > fi
>>
>> Sounds good.
>>
>> > Don't know if it makes sense to remove it on stop.
>>
>> I think it doesn't make sense to remove it,
>> because rep_mode.conf becomes empty on stop.
>
>
> The only problem here if admin changes temp_dir parameter but doesn't delete
> records from postgres.conf. We could end up with several include records
> then or with records pointing to the non existing files.

Should we consider this situation?

If same parameters exist, PostgreSQL uses last parameter.
So I will implement it to add several include if temp_dir is changed.


>>
>> >> > 3. I don't really like this part of pgsql_real_monitor:
>> >> >
>> >> > 775 if ! is_replication; then
>> >> > 776 OCF_RESKEY_monitor_sql=`escape_string >
>> >> > "$OCF_RESKEY_monitor_sql"`
>> >> > 777 runasowner -q $loglevel "$OCF_RESKEY_psql $psql_options
>> >> > -c
>> >> > > '$OCF_RESKEY_monitor_sql'"
>> >> > 778 rc=$?
>> >> > 779 else
>> >> > 780 output=`su $OCF_RESKEY_pgdba -c "cd $OCF_RESKEY_pgdata;
>> >> > >
>> >> > $OCF_RESKEY_psql $psql_options -Atc \"${CHECK_MS_SQL}\""`
>> >> > 781 rc=$?
>> >> > 782 fi
>> >> >
>> >> > I think that functional monitor (the one that uses monitor_sql)
>> >> > should
>> >> > run
>> >> > always independently of DB mode since its primary role is to check
>> >> > data
>> >> > and
>> >> > fail if it's not correct or corrupted. In replication mode there
>> >> > should
>> >> > be
>> >> > additional monitoring. Other way it misleads customer on a usage of
>> >> > monitor_sql.
>> >>
>> >> All right.
>> >>
>> >> Does it need to execute "select now();" if monitor_sql parameter is
>> >> empty?
>> >> I think it's unnecessary.
>> >
>> >
>> > For a case of an empty parameter you are right and running "select
>> > now()"
>> > probably unnecessary, Non-empty monitro_sql shall be executed in my
>> > opinion.
>> >
>> >>
>> >>
>> >> > 4. You already populate several attributes with crm_attribute. Does
>> >> > it
>> >> > make
>> >> > sense to populate a name of a Master node in promote function and use
>> >> > it
>> >> > later on instead of running crm_mon on each monitor command?
>> >> >
>> >>
>> >> Do you mean that you don't want to use crm_mon in monitor?
>> >
>> >
>> > I prefer to have as few dependencies on external programs as possible.
>>
>> Agree.
>>
>> > Using crm_attribute to communicate the name of a master node would be
>> > consistent with the rest of the script since you already use it for
>> > communicating state of the nodes. If you prefer using crm_mon than you
>> > have
>> > to add a check that that binary exists on the server. In 99.99% of the
>> > case
>> > it will but still the check is necessary I think.
>>
>> I use crm_mon to check for node existence and node online too.
>> It is impossible to get it from attribute, so I prefer to using crm_mon.
>>
>> Do I have to add a check for crm_master, crm_attribute, crm_failcount too?
>>
>
> That's a different interesting topic. What is the reason for doing this?
>
> my_fail_count=`$CRM_FAILCOUNT -r $OCF_RESOURCE_INSTANCE -N $HOSTNAME -G -Q |
> sed "s/INFINITY/1000000/g"`
> if [ "$my_fail_count" != "0" ]; then
> ocf_log info "I don't start PostgreSQL on post-demote because of my
> fail-count=$my_fail_count."
> return $OCF_SUCCESS
> fi
>
> Why not to leave pacemaker to do its job on managing failcounts?

Because I want to make fail-over faster.
At any rate Pacemaker stops it?


Regards,
Takatoshi MATSUO
_______________________________________________________
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/
Re: pgsql and streaming replcation [ In reply to ]
sergeyfd at gmail
Dec 12, 2011, 5:31 PM
Post #11 of 20 (6889 views)
Permalink
On Mon, Dec 12, 2011 at 4:28 AM, Takatoshi MATSUO <matsuo.tak@gmail.com>wrote:

> Hello Serge
>
> 2011/12/12 Serge Dubrouski <sergeyfd@gmail.com>:
> >
> >
> > On Thu, Dec 8, 2011 at 10:04 PM, Takatoshi MATSUO <matsuo.tak@gmail.com>
> > wrote:
> >>
> >> Hello Serge
> >>
> >> 2011/12/8 Serge Dubrouski <sergeyfd@gmail.com>:
> >> >
> >> >
> >> > On Mon, Dec 5, 2011 at 9:15 PM, Takatoshi MATSUO <
> matsuo.tak@gmail.com>
> >> > wrote:
> >> >>
> >> >> Hello Serge
> >> >>
> >> >> Serge Dubrouski <sergeyfd@gmail.com>:
> >> >> > Hello -
> >> >> >
> >> >> > Takatoshi MATSUO did a tremendous job on implementing support for
> >> >> > streaming
> >> >> > replication feature in pgsql RA. Also it looks like PostgeSQL 9.1
> has
> >> >> > all
> >> >> > necessary interfaces to successfully implement Pacemaker's M/S
> >> >> > concept.
> >> >> > So
> >> >> > I think it's time to start discussion on how to merge Takatoshi's
> >> >> > work
> >> >> > into
> >> >> > pgsql RA baseline. Here is the link to Takatoshi's GitHUB if
> somebody
> >> >> > wants
> >> >> > to test his RA:
> >> >> >
> >> >> > https://github.com/t-matsuo/
> >> >> >
> >> >> > So far I tested it for backward compatibility in a standard
> >> >> > non-replication
> >> >> > mode and also tested M/S model and found no real issues. Though it
> >> >> > definitely requires some more polishing and testing.
> >> >> >
> >> >> > Takatoshi, here are some changes that I want to discuss with you:
> >> >> >
> >> >> > 1. Is it possible to add a check for PostgreSQL version and fail
> with
> >> >> > OCF_ERR_INSTALLED when one tries to start replication on version
> less
> >> >> > than
> >> >> > 9.1? A simple cat on PG_VERSION with some analysis would probably
> do.
> >> >>
> >> >> I'll add a check.
> >>
> >> I added a check.
> >>
> >>
> https://github.com/t-matsuo/resource-agents/commit/3ab7cfdcce118043cd149b348740e50e7a946eb3
> >>
> >> >>
> >> >> > 2. I think that following lines should be moved from pgsql_start to
> >> >> > pgsql_validate_all
> >> >> >
> >> >> > 535 # Check whether tmpdir is readable by pgdba user
> >> >> > 536 if ! runasowner "test -r $OCF_RESKEY_tmpdir"; then
> >> >> > 537 ocf_log err "Directory $OCF_RESKEY_tmpdir is not
> >> >> > readable
> >> >> > by
> >> >> > $OCF_RESKEY_pgdba"
> >> >> > 538 return $OCF_ERR_PERM
> >> >> > 539 fi
> >> >>
> >> >> Thanks. I think so too.
> >> >> I'll fix it.
> >> >>
> >>
> >> I fixed it and I deleted a check for tmpdir existence
> >> because the checking for permittion fills the role.
> >>
> >>
> https://github.com/t-matsuo/resource-agents/commit/82d4939486bcca429e2deb804d7faf756099bb59
> >>
> >>
> >> > On a second thought I'm not sure why we need that parameter and
> >> > directory at
> >> > all. Why not to create rep_mode.conf, PGSQL.lock and xlog.note in
> >> > $OCF_RESKEY_pgdata ? What problems it can create?
> >> >
> >> > One more advantage to do
> >> > it in $OCF_RESKEY_pgdata is an ability to handle more than PostgreSQL
> >> > instance on the same server without a need for additional temp
> >> > directories.
> >>
> >> When backup is needed, customers may backup these files and restore it.
> >> It may cause problems.
> >> Specially PGSQL.lock causes an error on start.
> >>
> >> I think that they should be treated as a separate thing.
> >> because they are independent from PostgreSQL's data.
> >
> >
> > Ok. Then may be it should default to something like
> > ${OCF_RESKEY_pgdata}/temp and RA should create it and set the right
> > ownership and permissions if it doesn't exist? And again may be in this
> case
> > we don't need that parameter?
> >
>
> I agree that RA creates it and sets the right ownership and permissions.
> But considering backup using tar command, I think it's not better to
> create it
> under $OCF_RESKEY_pgdata.
>
> According to "Filesystem Hierarchy Standard"
> it's better to use /var/lib/somewhere.
>
> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION
> ,
>
> Then I designed using /var/lig/[RA Name] (=/var/lib/pgsql).
> What do you think?
>

Ahh, I see now where confusion comes from. /var/lib/pgsql is actually taken
:-) It's used as default home directory in RedHat (at least) for postgres
user in PostgreSQL 8.XX. When they'll start start shipping version 9
they'll probably use it as well. OCF_RESKEY_pg_data defaults to
/var/lib/pgsql/data.

Then, /var/lib is usually used for non-temporary data, For temporary files
it's probably better to use /var/run or /var/tmp. If you still want to use
/var/lib/pgsql you probably need to use /var/lib/pgsql/temp or so.


> >>
> >>
> >> Incidentally I considered to handle more than PostgreSQL instance.
> >> Initially I added port number to these filenames, but I deleted it
> >> to simplify filenames.
> >>
> >>
> https://github.com/t-matsuo/resource-agents/commit/b16faf2d797200048dc0fc07a45b6751cf5be190
> >>
> >>
> >> > Also I think it would be good if RA was able to take care of adding
> >> > "include
> >> > $WHATEVER_DIR/rep_mode.conf" in postgresql.conf. It will make the RA
> >> > self
> >> > sustainable. In a current situation admin has add that directive
> >> > manually.
> >> > RA though can something like this in a start function for replication
> >> > mode:
> >> >
> >> > if ! grep -i "include $WHATEVER_DIR/rep_mode.conf" $OCF_RESKEY_config
> >> > then
> >> > echo "include $WHATEVER_DIR/rep_mode.conf" >> $OCF_RESKEY_config
> >> > fi
> >>
> >> Sounds good.
> >>
> >> > Don't know if it makes sense to remove it on stop.
> >>
> >> I think it doesn't make sense to remove it,
> >> because rep_mode.conf becomes empty on stop.
> >
> >
> > The only problem here if admin changes temp_dir parameter but doesn't
> delete
> > records from postgres.conf. We could end up with several include records
> > then or with records pointing to the non existing files.
>
> Should we consider this situation?
>
> If same parameters exist, PostgreSQL uses last parameter.
> So I will implement it to add several include if temp_dir is changed.
>

The problem happens when file gets deleted but reference to it still exists
in postgres.conf. They DB fails to start.


>
>
> >>
> >> >> > 3. I don't really like this part of pgsql_real_monitor:
> >> >> >
> >> >> > 775 if ! is_replication; then
> >> >> > 776 OCF_RESKEY_monitor_sql=`escape_string >
> >> >> > "$OCF_RESKEY_monitor_sql"`
> >> >> > 777 runasowner -q $loglevel "$OCF_RESKEY_psql
> $psql_options
> >> >> > -c
> >> >> > > '$OCF_RESKEY_monitor_sql'"
> >> >> > 778 rc=$?
> >> >> > 779 else
> >> >> > 780 output=`su $OCF_RESKEY_pgdba -c "cd
> $OCF_RESKEY_pgdata;
> >> >> > >
> >> >> > $OCF_RESKEY_psql $psql_options -Atc \"${CHECK_MS_SQL}\""`
> >> >> > 781 rc=$?
> >> >> > 782 fi
> >> >> >
> >> >> > I think that functional monitor (the one that uses monitor_sql)
> >> >> > should
> >> >> > run
> >> >> > always independently of DB mode since its primary role is to check
> >> >> > data
> >> >> > and
> >> >> > fail if it's not correct or corrupted. In replication mode there
> >> >> > should
> >> >> > be
> >> >> > additional monitoring. Other way it misleads customer on a usage of
> >> >> > monitor_sql.
> >> >>
> >> >> All right.
> >> >>
> >> >> Does it need to execute "select now();" if monitor_sql parameter is
> >> >> empty?
> >> >> I think it's unnecessary.
> >> >
> >> >
> >> > For a case of an empty parameter you are right and running "select
> >> > now()"
> >> > probably unnecessary, Non-empty monitro_sql shall be executed in my
> >> > opinion.
> >> >
> >> >>
> >> >>
> >> >> > 4. You already populate several attributes with crm_attribute. Does
> >> >> > it
> >> >> > make
> >> >> > sense to populate a name of a Master node in promote function and
> use
> >> >> > it
> >> >> > later on instead of running crm_mon on each monitor command?
> >> >> >
> >> >>
> >> >> Do you mean that you don't want to use crm_mon in monitor?
> >> >
> >> >
> >> > I prefer to have as few dependencies on external programs as
> possible.
> >>
> >> Agree.
> >>
> >> > Using crm_attribute to communicate the name of a master node would be
> >> > consistent with the rest of the script since you already use it for
> >> > communicating state of the nodes. If you prefer using crm_mon than you
> >> > have
> >> > to add a check that that binary exists on the server. In 99.99% of the
> >> > case
> >> > it will but still the check is necessary I think.
> >>
> >> I use crm_mon to check for node existence and node online too.
> >> It is impossible to get it from attribute, so I prefer to using crm_mon.
> >>
> >> Do I have to add a check for crm_master, crm_attribute, crm_failcount
> too?
> >>
> >
> > That's a different interesting topic. What is the reason for doing this?
> >
> > my_fail_count=`$CRM_FAILCOUNT -r $OCF_RESOURCE_INSTANCE -N $HOSTNAME -G
> -Q |
> > sed "s/INFINITY/1000000/g"`
> > if [ "$my_fail_count" != "0" ]; then
> > ocf_log info "I don't start PostgreSQL on post-demote because of my
> > fail-count=$my_fail_count."
> > return $OCF_SUCCESS
> > fi
> >
> > Why not to leave pacemaker to do its job on managing failcounts?
>
> Because I want to make fail-over faster.
> At any rate Pacemaker stops it?
>

I'm probably wrong here. Looks like you use this trick in case if slave's
data is newer than new master's data. In this case it makes sense to
disable such slave.


>
> Regards,
> Takatoshi MATSUO
> _______________________________________________________
> 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.
Re: pgsql and streaming replcation [ In reply to ]
matsuo.tak at gmail
Dec 13, 2011, 2:37 AM
Post #12 of 20 (6878 views)
Permalink
Hello Serge

2011/12/13 Serge Dubrouski <sergeyfd@gmail.com>:
>
>
> On Mon, Dec 12, 2011 at 4:28 AM, Takatoshi MATSUO <matsuo.tak@gmail.com>
> wrote:
>>
>> Hello Serge
>>
>> 2011/12/12 Serge Dubrouski <sergeyfd@gmail.com>:
>> >
>> >
>> > On Thu, Dec 8, 2011 at 10:04 PM, Takatoshi MATSUO <matsuo.tak@gmail.com>
>> > wrote:
>> >>
>> >> Hello Serge
>> >>
>> >> 2011/12/8 Serge Dubrouski <sergeyfd@gmail.com>:
>> >> >
>> >> >
>> >> > On Mon, Dec 5, 2011 at 9:15 PM, Takatoshi MATSUO
>> >> > <matsuo.tak@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hello Serge
>> >> >>
>> >> >> Serge Dubrouski <sergeyfd@gmail.com>:
>> >> >> > Hello -
>> >> >> >
>> >> >> > Takatoshi MATSUO did a tremendous job on implementing support for
>> >> >> > streaming
>> >> >> > replication feature in pgsql RA. Also it looks like PostgeSQL 9.1
>> >> >> > has
>> >> >> > all
>> >> >> > necessary interfaces to successfully implement Pacemaker's M/S
>> >> >> > concept.
>> >> >> > So
>> >> >> > I think it's time to start discussion on how to merge Takatoshi's
>> >> >> > work
>> >> >> > into
>> >> >> > pgsql RA baseline. Here is the link to Takatoshi's GitHUB if
>> >> >> > somebody
>> >> >> > wants
>> >> >> > to test his RA:
>> >> >> >
>> >> >> > https://github.com/t-matsuo/
>> >> >> >
>> >> >> > So far I tested it for backward compatibility in a standard
>> >> >> > non-replication
>> >> >> > mode and also tested M/S model and found no real issues. Though
>> >> >> > it
>> >> >> > definitely requires some more polishing and testing.
>> >> >> >
>> >> >> > Takatoshi, here are some changes that I want to discuss with you:
>> >> >> >
>> >> >> > 1. Is it possible to add a check for PostgreSQL version and fail
>> >> >> > with
>> >> >> > OCF_ERR_INSTALLED when one tries to start replication on version
>> >> >> > less
>> >> >> > than
>> >> >> > 9.1? A simple cat on PG_VERSION with some analysis would probably
>> >> >> > do.
>> >> >>
>> >> >> I'll add a check.
>> >>
>> >> I added a check.
>> >>
>> >>
>> >> https://github.com/t-matsuo/resource-agents/commit/3ab7cfdcce118043cd149b348740e50e7a946eb3
>> >>
>> >> >>
>> >> >> > 2. I think that following lines should be moved from pgsql_start
>> >> >> > to
>> >> >> > pgsql_validate_all
>> >> >> >
>> >> >> > 535 # Check whether tmpdir is readable by pgdba user
>> >> >> > 536 if ! runasowner "test -r $OCF_RESKEY_tmpdir"; then
>> >> >> > 537 ocf_log err "Directory $OCF_RESKEY_tmpdir is not
>> >> >> > readable
>> >> >> > by
>> >> >> > $OCF_RESKEY_pgdba"
>> >> >> > 538 return $OCF_ERR_PERM
>> >> >> > 539 fi
>> >> >>
>> >> >> Thanks. I think so too.
>> >> >> I'll fix it.
>> >> >>
>> >>
>> >> I fixed it and I deleted a check for tmpdir existence
>> >> because the checking for permittion fills the role.
>> >>
>> >>
>> >> https://github.com/t-matsuo/resource-agents/commit/82d4939486bcca429e2deb804d7faf756099bb59
>> >>
>> >>
>> >> > On a second thought I'm not sure why we need that parameter and
>> >> > directory at
>> >> > all. Why not to create rep_mode.conf, PGSQL.lock and xlog.note in
>> >> > $OCF_RESKEY_pgdata ? What problems it can create?
>> >> >
>> >> > One more advantage to do
>> >> > it in $OCF_RESKEY_pgdata is an ability to handle more than PostgreSQL
>> >> > instance on the same server without a need for additional temp
>> >> > directories.
>> >>
>> >> When backup is needed, customers may backup these files and restore it.
>> >> It may cause problems.
>> >> Specially PGSQL.lock causes an error on start.
>> >>
>> >> I think that they should be treated as a separate thing.
>> >> because they are independent from PostgreSQL's data.
>> >
>> >
>> > Ok. Then may be it should default to something like
>> > ${OCF_RESKEY_pgdata}/temp and RA should create it and set the right
>> > ownership and permissions if it doesn't exist? And again may be in this
>> > case
>> > we don't need that parameter?
>> >
>>
>> I agree that RA creates it and sets the right ownership and permissions.
>> But considering backup using tar command, I think it's not better to
>> create it
>> under $OCF_RESKEY_pgdata.
>>
>> According to "Filesystem Hierarchy Standard"
>> it's better to use /var/lib/somewhere.
>>
>>
>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION,
>>
>> Then I designed using /var/lig/[RA Name] (=/var/lib/pgsql).
>> What do you think?
>
>
> Ahh, I see now where confusion comes from. /var/lib/pgsql is actually taken
> :-) It's used as default home directory in RedHat (at least) for postgres
> user in PostgreSQL 8.XX. When they'll start start shipping version 9 they'll
> probably use it as well. OCF_RESKEY_pg_data defaults to
> /var/lib/pgsql/data.
>
> Then, /var/lib is usually used for non-temporary data, For temporary files
> it's probably better to use /var/run or /var/tmp. If you still want to use
> /var/lib/pgsql you probably need to use /var/lib/pgsql/temp or so.

Files under /var/run or /var/tmp are cleared by tmpwatch or at the beginning
of the boot process, aren't they?

Clearing PGSQL.lock file causes problem.


>
>>
>> >>
>> >>
>> >> Incidentally I considered to handle more than PostgreSQL instance.
>> >> Initially I added port number to these filenames, but I deleted it
>> >> to simplify filenames.
>> >>
>> >>
>> >> https://github.com/t-matsuo/resource-agents/commit/b16faf2d797200048dc0fc07a45b6751cf5be190
>> >>
>> >>
>> >> > Also I think it would be good if RA was able to take care of adding
>> >> > "include
>> >> > $WHATEVER_DIR/rep_mode.conf" in postgresql.conf. It will make the RA
>> >> > self
>> >> > sustainable. In a current situation admin has add that directive
>> >> > manually.
>> >> > RA though can something like this in a start function for replication
>> >> > mode:
>> >> >
>> >> > if ! grep -i "include $WHATEVER_DIR/rep_mode.conf" $OCF_RESKEY_config
>> >> > then
>> >> > echo "include $WHATEVER_DIR/rep_mode.conf" >> $OCF_RESKEY_config
>> >> > fi
>> >>
>> >> Sounds good.
>> >>
>> >> > Don't know if it makes sense to remove it on stop.
>> >>
>> >> I think it doesn't make sense to remove it,
>> >> because rep_mode.conf becomes empty on stop.
>> >
>> >
>> > The only problem here if admin changes temp_dir parameter but doesn't
>> > delete
>> > records from postgres.conf. We could end up with several include records
>> > then or with records pointing to the non existing files.
>>
>> Should we consider this situation?
>>
>> If same parameters exist, PostgreSQL uses last parameter.
>> So I will implement it to add several include if temp_dir is changed.
>
>
> The problem happens when file gets deleted but reference to it still exists
> in postgres.conf. They DB fails to start.


Start manually?
The RA manages some statuses using an attribute and PGSQL.lock file.
I don't recommend starting it manually in the first place.


How about just describing it in a document? meta-data?


>
>>
>>
>>
>> >>
>> >> >> > 3. I don't really like this part of pgsql_real_monitor:
>> >> >> >
>> >> >> > 775 if ! is_replication; then
>> >> >> > 776 OCF_RESKEY_monitor_sql=`escape_string >
>> >> >> > "$OCF_RESKEY_monitor_sql"`
>> >> >> > 777 runasowner -q $loglevel "$OCF_RESKEY_psql
>> >> >> > $psql_options
>> >> >> > -c
>> >> >> > > '$OCF_RESKEY_monitor_sql'"
>> >> >> > 778 rc=$?
>> >> >> > 779 else
>> >> >> > 780 output=`su $OCF_RESKEY_pgdba -c "cd
>> >> >> > $OCF_RESKEY_pgdata;
>> >> >> > >
>> >> >> > $OCF_RESKEY_psql $psql_options -Atc \"${CHECK_MS_SQL}\""`
>> >> >> > 781 rc=$?
>> >> >> > 782 fi
>> >> >> >
>> >> >> > I think that functional monitor (the one that uses monitor_sql)
>> >> >> > should
>> >> >> > run
>> >> >> > always independently of DB mode since its primary role is to check
>> >> >> > data
>> >> >> > and
>> >> >> > fail if it's not correct or corrupted. In replication mode there
>> >> >> > should
>> >> >> > be
>> >> >> > additional monitoring. Other way it misleads customer on a usage
>> >> >> > of
>> >> >> > monitor_sql.
>> >> >>
>> >> >> All right.
>> >> >>
>> >> >> Does it need to execute "select now();" if monitor_sql parameter is
>> >> >> empty?
>> >> >> I think it's unnecessary.
>> >> >
>> >> >
>> >> > For a case of an empty parameter you are right and running "select
>> >> > now()"
>> >> > probably unnecessary, Non-empty monitro_sql shall be executed in my
>> >> > opinion.
>> >> >
>> >> >>
>> >> >>
>> >> >> > 4. You already populate several attributes with crm_attribute.
>> >> >> > Does
>> >> >> > it
>> >> >> > make
>> >> >> > sense to populate a name of a Master node in promote function and
>> >> >> > use
>> >> >> > it
>> >> >> > later on instead of running crm_mon on each monitor command?
>> >> >> >
>> >> >>
>> >> >> Do you mean that you don't want to use crm_mon in monitor?
>> >> >
>> >> >
>> >> > I prefer to have as few dependencies on external programs as
>> >> > possible.
>> >>
>> >> Agree.
>> >>
>> >> > Using crm_attribute to communicate the name of a master node would be
>> >> > consistent with the rest of the script since you already use it for
>> >> > communicating state of the nodes. If you prefer using crm_mon than
>> >> > you
>> >> > have
>> >> > to add a check that that binary exists on the server. In 99.99% of
>> >> > the
>> >> > case
>> >> > it will but still the check is necessary I think.
>> >>
>> >> I use crm_mon to check for node existence and node online too.
>> >> It is impossible to get it from attribute, so I prefer to using
>> >> crm_mon.
>> >>
>> >> Do I have to add a check for crm_master, crm_attribute, crm_failcount
>> >> too?
>> >>
>> >
>> > That's a different interesting topic. What is the reason for doing
>> > this?
>> >
>> > my_fail_count=`$CRM_FAILCOUNT -r $OCF_RESOURCE_INSTANCE -N $HOSTNAME -G
>> > -Q |
>> > sed "s/INFINITY/1000000/g"`
>> > if [ "$my_fail_count" != "0" ]; then
>> > ocf_log info "I don't start PostgreSQL on post-demote because of
>> > my
>> > fail-count=$my_fail_count."
>> > return $OCF_SUCCESS
>> > fi
>> >
>> > Why not to leave pacemaker to do its job on managing failcounts?
>>
>> Because I want to make fail-over faster.
>> At any rate Pacemaker stops it?
>
>
> I'm probably wrong here. Looks like you use this trick in case if slave's
> data is newer than new master's data. In this case it makes sense to disable
> such slave.

Why do you think so ?
The check whether slave's data is newer than new master's one is here.

in pgsql_post_demote()
-------------------------------------------------------
886 is_slave_right || return $OCF_ERR_GENERIC
-------------------------------------------------------

This line is executed after this trick.



Regards,
Takatoshi MATSUO
_______________________________________________________
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/
Re: pgsql and streaming replcation [ In reply to ]
sergeyfd at gmail
Feb 5, 2012, 9:13 AM
Post #13 of 20 (6799 views)
Permalink
Takatoshi -

Please consider apllying attached patch to your version of pgsql RA. It's
all cosmetics: replacing tabs with spaces and improving English. Thanks for
implementing recommendations I expressed earlier.


On Tue, Dec 13, 2011 at 3:37 AM, Takatoshi MATSUO <matsuo.tak@gmail.com>wrote:

> Hello Serge
>
> 2011/12/13 Serge Dubrouski <sergeyfd@gmail.com>:
> >
> >
> > On Mon, Dec 12, 2011 at 4:28 AM, Takatoshi MATSUO <matsuo.tak@gmail.com>
> > wrote:
> >>
> >> Hello Serge
> >>
> >> 2011/12/12 Serge Dubrouski <sergeyfd@gmail.com>:
> >> >
> >> >
> >> > On Thu, Dec 8, 2011 at 10:04 PM, Takatoshi MATSUO <
> matsuo.tak@gmail.com>
> >> > wrote:
> >> >>
> >> >> Hello Serge
> >> >>
> >> >> 2011/12/8 Serge Dubrouski <sergeyfd@gmail.com>:
> >> >> >
> >> >> >
> >> >> > On Mon, Dec 5, 2011 at 9:15 PM, Takatoshi MATSUO
> >> >> > <matsuo.tak@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Hello Serge
> >> >> >>
> >> >> >> Serge Dubrouski <sergeyfd@gmail.com>:
> >> >> >> > Hello -
> >> >> >> >
> >> >> >> > Takatoshi MATSUO did a tremendous job on implementing support
> for
> >> >> >> > streaming
> >> >> >> > replication feature in pgsql RA. Also it looks like PostgeSQL
> 9.1
> >> >> >> > has
> >> >> >> > all
> >> >> >> > necessary interfaces to successfully implement Pacemaker's M/S
> >> >> >> > concept.
> >> >> >> > So
> >> >> >> > I think it's time to start discussion on how to merge
> Takatoshi's
> >> >> >> > work
> >> >> >> > into
> >> >> >> > pgsql RA baseline. Here is the link to Takatoshi's GitHUB if
> >> >> >> > somebody
> >> >> >> > wants
> >> >> >> > to test his RA:
> >> >> >> >
> >> >> >> > https://github.com/t-matsuo/
> >> >> >> >
> >> >> >> > So far I tested it for backward compatibility in a standard
> >> >> >> > non-replication
> >> >> >> > mode and also tested M/S model and found no real issues. Though
> >> >> >> > it
> >> >> >> > definitely requires some more polishing and testing.
> >> >> >> >
> >> >> >> > Takatoshi, here are some changes that I want to discuss with
> you:
> >> >> >> >
> >> >> >> > 1. Is it possible to add a check for PostgreSQL version and fail
> >> >> >> > with
> >> >> >> > OCF_ERR_INSTALLED when one tries to start replication on version
> >> >> >> > less
> >> >> >> > than
> >> >> >> > 9.1? A simple cat on PG_VERSION with some analysis would
> probably
> >> >> >> > do.
> >> >> >>
> >> >> >> I'll add a check.
> >> >>
> >> >> I added a check.
> >> >>
> >> >>
> >> >>
> https://github.com/t-matsuo/resource-agents/commit/3ab7cfdcce118043cd149b348740e50e7a946eb3
> >> >>
> >> >> >>
> >> >> >> > 2. I think that following lines should be moved from pgsql_start
> >> >> >> > to
> >> >> >> > pgsql_validate_all
> >> >> >> >
> >> >> >> > 535 # Check whether tmpdir is readable by pgdba user
> >> >> >> > 536 if ! runasowner "test -r $OCF_RESKEY_tmpdir"; then
> >> >> >> > 537 ocf_log err "Directory $OCF_RESKEY_tmpdir is not
> >> >> >> > readable
> >> >> >> > by
> >> >> >> > $OCF_RESKEY_pgdba"
> >> >> >> > 538 return $OCF_ERR_PERM
> >> >> >> > 539 fi
> >> >> >>
> >> >> >> Thanks. I think so too.
> >> >> >> I'll fix it.
> >> >> >>
> >> >>
> >> >> I fixed it and I deleted a check for tmpdir existence
> >> >> because the checking for permittion fills the role.
> >> >>
> >> >>
> >> >>
> https://github.com/t-matsuo/resource-agents/commit/82d4939486bcca429e2deb804d7faf756099bb59
> >> >>
> >> >>
> >> >> > On a second thought I'm not sure why we need that parameter and
> >> >> > directory at
> >> >> > all. Why not to create rep_mode.conf, PGSQL.lock and xlog.note in
> >> >> > $OCF_RESKEY_pgdata ? What problems it can create?
> >> >> >
> >> >> > One more advantage to do
> >> >> > it in $OCF_RESKEY_pgdata is an ability to handle more than
> PostgreSQL
> >> >> > instance on the same server without a need for additional temp
> >> >> > directories.
> >> >>
> >> >> When backup is needed, customers may backup these files and restore
> it.
> >> >> It may cause problems.
> >> >> Specially PGSQL.lock causes an error on start.
> >> >>
> >> >> I think that they should be treated as a separate thing.
> >> >> because they are independent from PostgreSQL's data.
> >> >
> >> >
> >> > Ok. Then may be it should default to something like
> >> > ${OCF_RESKEY_pgdata}/temp and RA should create it and set the right
> >> > ownership and permissions if it doesn't exist? And again may be in
> this
> >> > case
> >> > we don't need that parameter?
> >> >
> >>
> >> I agree that RA creates it and sets the right ownership and permissions.
> >> But considering backup using tar command, I think it's not better to
> >> create it
> >> under $OCF_RESKEY_pgdata.
> >>
> >> According to "Filesystem Hierarchy Standard"
> >> it's better to use /var/lib/somewhere.
> >>
> >>
> >>
> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION
> ,
> >>
> >> Then I designed using /var/lig/[RA Name] (=/var/lib/pgsql).
> >> What do you think?
> >
> >
> > Ahh, I see now where confusion comes from. /var/lib/pgsql is actually
> taken
> > :-) It's used as default home directory in RedHat (at least) for postgres
> > user in PostgreSQL 8.XX. When they'll start start shipping version 9
> they'll
> > probably use it as well. OCF_RESKEY_pg_data defaults to
> > /var/lib/pgsql/data.
> >
> > Then, /var/lib is usually used for non-temporary data, For temporary
> files
> > it's probably better to use /var/run or /var/tmp. If you still want to
> use
> > /var/lib/pgsql you probably need to use /var/lib/pgsql/temp or so.
>
> Files under /var/run or /var/tmp are cleared by tmpwatch or at the
> beginning
> of the boot process, aren't they?
>
> Clearing PGSQL.lock file causes problem.
>
>
> >
> >>
> >> >>
> >> >>
> >> >> Incidentally I considered to handle more than PostgreSQL instance.
> >> >> Initially I added port number to these filenames, but I deleted it
> >> >> to simplify filenames.
> >> >>
> >> >>
> >> >>
> https://github.com/t-matsuo/resource-agents/commit/b16faf2d797200048dc0fc07a45b6751cf5be190
> >> >>
> >> >>
> >> >> > Also I think it would be good if RA was able to take care of adding
> >> >> > "include
> >> >> > $WHATEVER_DIR/rep_mode.conf" in postgresql.conf. It will make the
> RA
> >> >> > self
> >> >> > sustainable. In a current situation admin has add that directive
> >> >> > manually.
> >> >> > RA though can something like this in a start function for
> replication
> >> >> > mode:
> >> >> >
> >> >> > if ! grep -i "include $WHATEVER_DIR/rep_mode.conf"
> $OCF_RESKEY_config
> >> >> > then
> >> >> > echo "include $WHATEVER_DIR/rep_mode.conf" >>
> $OCF_RESKEY_config
> >> >> > fi
> >> >>
> >> >> Sounds good.
> >> >>
> >> >> > Don't know if it makes sense to remove it on stop.
> >> >>
> >> >> I think it doesn't make sense to remove it,
> >> >> because rep_mode.conf becomes empty on stop.
> >> >
> >> >
> >> > The only problem here if admin changes temp_dir parameter but doesn't
> >> > delete
> >> > records from postgres.conf. We could end up with several include
> records
> >> > then or with records pointing to the non existing files.
> >>
> >> Should we consider this situation?
> >>
> >> If same parameters exist, PostgreSQL uses last parameter.
> >> So I will implement it to add several include if temp_dir is changed.
> >
> >
> > The problem happens when file gets deleted but reference to it still
> exists
> > in postgres.conf. They DB fails to start.
>
>
> Start manually?
> The RA manages some statuses using an attribute and PGSQL.lock file.
> I don't recommend starting it manually in the first place.
>
>
> How about just describing it in a document? meta-data?
>
>
> >
> >>
> >>
> >>
> >> >>
> >> >> >> > 3. I don't really like this part of pgsql_real_monitor:
> >> >> >> >
> >> >> >> > 775 if ! is_replication; then
> >> >> >> > 776 OCF_RESKEY_monitor_sql=`escape_string >
> >> >> >> > "$OCF_RESKEY_monitor_sql"`
> >> >> >> > 777 runasowner -q $loglevel "$OCF_RESKEY_psql
> >> >> >> > $psql_options
> >> >> >> > -c
> >> >> >> > > '$OCF_RESKEY_monitor_sql'"
> >> >> >> > 778 rc=$?
> >> >> >> > 779 else
> >> >> >> > 780 output=`su $OCF_RESKEY_pgdba -c "cd
> >> >> >> > $OCF_RESKEY_pgdata;
> >> >> >> > >
> >> >> >> > $OCF_RESKEY_psql $psql_options -Atc \"${CHECK_MS_SQL}\""`
> >> >> >> > 781 rc=$?
> >> >> >> > 782 fi
> >> >> >> >
> >> >> >> > I think that functional monitor (the one that uses monitor_sql)
> >> >> >> > should
> >> >> >> > run
> >> >> >> > always independently of DB mode since its primary role is to
> check
> >> >> >> > data
> >> >> >> > and
> >> >> >> > fail if it's not correct or corrupted. In replication mode there
> >> >> >> > should
> >> >> >> > be
> >> >> >> > additional monitoring. Other way it misleads customer on a usage
> >> >> >> > of
> >> >> >> > monitor_sql.
> >> >> >>
> >> >> >> All right.
> >> >> >>
> >> >> >> Does it need to execute "select now();" if monitor_sql parameter
> is
> >> >> >> empty?
> >> >> >> I think it's unnecessary.
> >> >> >
> >> >> >
> >> >> > For a case of an empty parameter you are right and running "select
> >> >> > now()"
> >> >> > probably unnecessary, Non-empty monitro_sql shall be executed in my
> >> >> > opinion.
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> > 4. You already populate several attributes with crm_attribute.
> >> >> >> > Does
> >> >> >> > it
> >> >> >> > make
> >> >> >> > sense to populate a name of a Master node in promote function
> and
> >> >> >> > use
> >> >> >> > it
> >> >> >> > later on instead of running crm_mon on each monitor command?
> >> >> >> >
> >> >> >>
> >> >> >> Do you mean that you don't want to use crm_mon in monitor?
> >> >> >
> >> >> >
> >> >> > I prefer to have as few dependencies on external programs as
> >> >> > possible.
> >> >>
> >> >> Agree.
> >> >>
> >> >> > Using crm_attribute to communicate the name of a master node would
> be
> >> >> > consistent with the rest of the script since you already use it for
> >> >> > communicating state of the nodes. If you prefer using crm_mon than
> >> >> > you
> >> >> > have
> >> >> > to add a check that that binary exists on the server. In 99.99% of
> >> >> > the
> >> >> > case
> >> >> > it will but still the check is necessary I think.
> >> >>
> >> >> I use crm_mon to check for node existence and node online too.
> >> >> It is impossible to get it from attribute, so I prefer to using
> >> >> crm_mon.
> >> >>
> >> >> Do I have to add a check for crm_master, crm_attribute, crm_failcount
> >> >> too?
> >> >>
> >> >
> >> > That's a different interesting topic. What is the reason for doing
> >> > this?
> >> >
> >> > my_fail_count=`$CRM_FAILCOUNT -r $OCF_RESOURCE_INSTANCE -N $HOSTNAME
> -G
> >> > -Q |
> >> > sed "s/INFINITY/1000000/g"`
> >> > if [ "$my_fail_count" != "0" ]; then
> >> > ocf_log info "I don't start PostgreSQL on post-demote because of
> >> > my
> >> > fail-count=$my_fail_count."
> >> > return $OCF_SUCCESS
> >> > fi
> >> >
> >> > Why not to leave pacemaker to do its job on managing failcounts?
> >>
> >> Because I want to make fail-over faster.
> >> At any rate Pacemaker stops it?
> >
> >
> > I'm probably wrong here. Looks like you use this trick in case if slave's
> > data is newer than new master's data. In this case it makes sense to
> disable
> > such slave.
>
> Why do you think so ?
> The check whether slave's data is newer than new master's one is here.
>
> in pgsql_post_demote()
> -------------------------------------------------------
> 886 is_slave_right || return $OCF_ERR_GENERIC
> -------------------------------------------------------
>
> This line is executed after this trick.
>
>
>
> Regards,
> Takatoshi MATSUO
> _______________________________________________________
> 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.

Attached Files:

Re: pgsql and streaming replcation [ In reply to ]
matsuo.tak at gmail
Feb 5, 2012, 6:42 PM
Post #14 of 20 (6794 views)
Permalink
Hi Serge

Thank you.
I applied it to my repository.


2012/2/6 Serge Dubrouski <sergeyfd@gmail.com>:
> Takatoshi -
>
> Please consider apllying attached patch to your version of pgsql RA. It's
> all cosmetics: replacing tabs with spaces and improving English. Thanks for
> implementing recommendations I expressed earlier.
>
>
> On Tue, Dec 13, 2011 at 3:37 AM, Takatoshi MATSUO <matsuo.tak@gmail.com>
> wrote:
>>
>> Hello Serge
>>
>> 2011/12/13 Serge Dubrouski <sergeyfd@gmail.com>:
>> >
>> >
>> > On Mon, Dec 12, 2011 at 4:28 AM, Takatoshi MATSUO <matsuo.tak@gmail.com>
>> > wrote:
>> >>
>> >> Hello Serge
>> >>
>> >> 2011/12/12 Serge Dubrouski <sergeyfd@gmail.com>:
>> >> >
>> >> >
>> >> > On Thu, Dec 8, 2011 at 10:04 PM, Takatoshi MATSUO
>> >> > <matsuo.tak@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hello Serge
>> >> >>
>> >> >> 2011/12/8 Serge Dubrouski <sergeyfd@gmail.com>:
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Dec 5, 2011 at 9:15 PM, Takatoshi MATSUO
>> >> >> > <matsuo.tak@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Hello Serge
>> >> >> >>
>> >> >> >> Serge Dubrouski <sergeyfd@gmail.com>:
>> >> >> >> > Hello -
>> >> >> >> >
>> >> >> >> > Takatoshi MATSUO did a tremendous job on implementing support
>> >> >> >> > for
>> >> >> >> > streaming
>> >> >> >> > replication feature in pgsql RA. Also it looks like PostgeSQL
>> >> >> >> > 9.1
>> >> >> >> > has
>> >> >> >> > all
>> >> >> >> > necessary interfaces to successfully implement  Pacemaker's M/S
>> >> >> >> > concept.
>> >> >> >> > So
>> >> >> >> > I think it's time to start discussion on how to merge
>> >> >> >> > Takatoshi's
>> >> >> >> > work
>> >> >> >> > into
>> >> >> >> > pgsql RA baseline. Here is the link to Takatoshi's GitHUB if
>> >> >> >> > somebody
>> >> >> >> > wants
>> >> >> >> > to test his RA:
>> >> >> >> >
>> >> >> >> > https://github.com/t-matsuo/
>> >> >> >> >
>> >> >> >> > So far I tested it for backward compatibility in a standard
>> >> >> >> > non-replication
>> >> >> >> > mode  and also tested M/S model and found no real issues.
>> >> >> >> > Though
>> >> >> >> > it
>> >> >> >> > definitely requires some more polishing and testing.
>> >> >> >> >
>> >> >> >> > Takatoshi, here are some changes that I want to discuss with
>> >> >> >> > you:
>> >> >> >> >
>> >> >> >> > 1. Is it possible to add a check for PostgreSQL version and
>> >> >> >> > fail
>> >> >> >> > with
>> >> >> >> > OCF_ERR_INSTALLED when one tries to start replication on
>> >> >> >> > version
>> >> >> >> > less
>> >> >> >> > than
>> >> >> >> > 9.1? A simple cat on PG_VERSION with some analysis would
>> >> >> >> > probably
>> >> >> >> > do.
>> >> >> >>
>> >> >> >> I'll add a check.
>> >> >>
>> >> >> I added a check.
>> >> >>
>> >> >>
>> >> >>
>> >> >> https://github.com/t-matsuo/resource-agents/commit/3ab7cfdcce118043cd149b348740e50e7a946eb3
>> >> >>
>> >> >> >>
>> >> >> >> > 2. I think that following lines should be moved from
>> >> >> >> > pgsql_start
>> >> >> >> > to
>> >> >> >> > pgsql_validate_all
>> >> >> >> >
>> >> >> >> >  535     # Check whether tmpdir is readable by pgdba user
>> >> >> >> >  536     if ! runasowner "test -r $OCF_RESKEY_tmpdir"; then
>> >> >> >> >  537         ocf_log err "Directory $OCF_RESKEY_tmpdir is not
>> >> >> >> > readable
>> >> >> >> > by
>> >> >> >> > $OCF_RESKEY_pgdba"
>> >> >> >> >  538         return $OCF_ERR_PERM
>> >> >> >> >  539     fi
>> >> >> >>
>> >> >> >> Thanks. I think so too.
>> >> >> >> I'll fix it.
>> >> >> >>
>> >> >>
>> >> >> I fixed it and I deleted a check for tmpdir existence
>> >> >> because the checking for permittion fills the role.
>> >> >>
>> >> >>
>> >> >>
>> >> >> https://github.com/t-matsuo/resource-agents/commit/82d4939486bcca429e2deb804d7faf756099bb59
>> >> >>
>> >> >>
>> >> >> > On a second thought I'm not sure why we need that parameter and
>> >> >> > directory at
>> >> >> > all. Why not to create rep_mode.conf, PGSQL.lock and xlog.note in
>> >> >> > $OCF_RESKEY_pgdata ? What problems it can create?
>> >> >> >
>> >> >> > One more advantage to do
>> >> >> > it in $OCF_RESKEY_pgdata is an ability to handle more than
>> >> >> > PostgreSQL
>> >> >> > instance on the same server without a need for additional temp
>> >> >> > directories.
>> >> >>
>> >> >> When backup is needed, customers may backup these files and restore
>> >> >> it.
>> >> >> It may cause problems.
>> >> >> Specially PGSQL.lock causes an error on start.
>> >> >>
>> >> >> I think that they should be treated as a separate thing.
>> >> >> because they are independent from PostgreSQL's data.
>> >> >
>> >> >
>> >> > Ok. Then may be it should default to something like
>> >> > ${OCF_RESKEY_pgdata}/temp and RA should create it and set the right
>> >> > ownership and permissions if it doesn't exist? And again may be in
>> >> > this
>> >> > case
>> >> > we don't need that parameter?
>> >> >
>> >>
>> >> I agree that RA creates it and sets the right ownership and
>> >> permissions.
>> >> But considering backup using tar command, I think it's not better to
>> >> create it
>> >> under $OCF_RESKEY_pgdata.
>> >>
>> >> According to "Filesystem Hierarchy Standard"
>> >> it's better to use /var/lib/somewhere.
>> >>
>> >>
>> >>
>> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION,
>> >>
>> >> Then I designed using /var/lig/[RA Name] (=/var/lib/pgsql).
>> >> What do you think?
>> >
>> >
>> > Ahh, I see now where confusion comes from. /var/lib/pgsql is actually
>> > taken
>> > :-) It's used as default home directory in RedHat (at least) for
>> > postgres
>> > user in PostgreSQL 8.XX. When they'll start start shipping version 9
>> > they'll
>> > probably use it as well. OCF_RESKEY_pg_data  defaults to
>> > /var/lib/pgsql/data.
>> >
>> > Then, /var/lib is usually used for non-temporary data, For temporary
>> > files
>> > it's probably better to use /var/run or /var/tmp. If you still want to
>> > use
>> > /var/lib/pgsql you probably need to use /var/lib/pgsql/temp or so.
>>
>> Files under /var/run or /var/tmp are cleared by tmpwatch or at the
>> beginning
>> of the boot process, aren't they?
>>
>> Clearing PGSQL.lock file causes problem.
>>
>>
>> >
>> >>
>> >> >>
>> >> >>
>> >> >> Incidentally I considered to handle more than PostgreSQL instance.
>> >> >> Initially I added port number to these filenames, but I deleted it
>> >> >> to simplify filenames.
>> >> >>
>> >> >>
>> >> >>
>> >> >> https://github.com/t-matsuo/resource-agents/commit/b16faf2d797200048dc0fc07a45b6751cf5be190
>> >> >>
>> >> >>
>> >> >> > Also I think it would be good if RA was able to take care of
>> >> >> > adding
>> >> >> > "include
>> >> >> > $WHATEVER_DIR/rep_mode.conf" in postgresql.conf. It will make the
>> >> >> > RA
>> >> >> > self
>> >> >> > sustainable. In a current situation admin has add that directive
>> >> >> > manually.
>> >> >> > RA though can something like this in a start function for
>> >> >> > replication
>> >> >> > mode:
>> >> >> >
>> >> >> > if ! grep -i "include $WHATEVER_DIR/rep_mode.conf"
>> >> >> > $OCF_RESKEY_config
>> >> >> > then
>> >> >> >      echo "include $WHATEVER_DIR/rep_mode.conf" >>
>> >> >> > $OCF_RESKEY_config
>> >> >> > fi
>> >> >>
>> >> >> Sounds good.
>> >> >>
>> >> >> > Don't know if it makes sense to remove it on stop.
>> >> >>
>> >> >> I think it doesn't make sense to remove it,
>> >> >> because rep_mode.conf becomes empty on stop.
>> >> >
>> >> >
>> >> > The only problem here if admin changes temp_dir parameter but doesn't
>> >> > delete
>> >> > records from postgres.conf. We could end up with several include
>> >> > records
>> >> > then or with records pointing to the non existing files.
>> >>
>> >> Should we consider this situation?
>> >>
>> >> If same parameters exist, PostgreSQL uses last parameter.
>> >> So I will implement it to add several include if temp_dir is changed.
>> >
>> >
>> > The problem happens when file gets deleted but reference to it still
>> > exists
>> > in postgres.conf. They DB fails to start.
>>
>>
>> Start manually?
>> The RA manages some statuses using an attribute and PGSQL.lock file.
>> I don't recommend starting it manually in the first place.
>>
>>
>> How about just describing it in a document? meta-data?
>>
>>
>> >
>> >>
>> >>
>> >>
>> >> >>
>> >> >> >> > 3. I don't really like this part of pgsql_real_monitor:
>> >> >> >> >
>> >> >> >> >  775     if ! is_replication; then
>> >> >> >> >  776         OCF_RESKEY_monitor_sql=`escape_string >
>> >> >> >> > "$OCF_RESKEY_monitor_sql"`
>> >> >> >> >  777         runasowner -q $loglevel "$OCF_RESKEY_psql
>> >> >> >> > $psql_options
>> >> >> >> > -c
>> >> >> >> > > '$OCF_RESKEY_monitor_sql'"
>> >> >> >> >  778         rc=$?
>> >> >> >> >  779     else
>> >> >> >> >  780         output=`su $OCF_RESKEY_pgdba -c "cd
>> >> >> >> > $OCF_RESKEY_pgdata;
>> >> >> >> > >
>> >> >> >> > $OCF_RESKEY_psql $psql_options -Atc \"${CHECK_MS_SQL}\""`
>> >> >> >> >  781         rc=$?
>> >> >> >> >  782     fi
>> >> >> >> >
>> >> >> >> > I think that functional monitor (the one that uses monitor_sql)
>> >> >> >> > should
>> >> >> >> > run
>> >> >> >> > always independently of DB mode since its primary role is to
>> >> >> >> > check
>> >> >> >> > data
>> >> >> >> > and
>> >> >> >> > fail if it's not correct or corrupted. In replication mode
>> >> >> >> > there
>> >> >> >> > should
>> >> >> >> > be
>> >> >> >> > additional monitoring. Other way it misleads customer on a
>> >> >> >> > usage
>> >> >> >> > of
>> >> >> >> > monitor_sql.
>> >> >> >>
>> >> >> >> All right.
>> >> >> >>
>> >> >> >> Does it need to execute "select now();" if monitor_sql parameter
>> >> >> >> is
>> >> >> >> empty?
>> >> >> >> I think it's unnecessary.
>> >> >> >
>> >> >> >
>> >> >> > For a case of an empty parameter you are right and running "select
>> >> >> > now()"
>> >> >> > probably unnecessary, Non-empty monitro_sql shall be executed in
>> >> >> > my
>> >> >> > opinion.
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> > 4. You already populate several attributes with crm_attribute.
>> >> >> >> > Does
>> >> >> >> > it
>> >> >> >> > make
>> >> >> >> > sense to populate a name of a Master node in promote function
>> >> >> >> > and
>> >> >> >> > use
>> >> >> >> > it
>> >> >> >> > later on instead of running crm_mon on each monitor command?
>> >> >> >> >
>> >> >> >>
>> >> >> >> Do you mean that you don't want to use crm_mon in monitor?
>> >> >> >
>> >> >> >
>> >> >> > I prefer to have as few dependencies  on external programs as
>> >> >> > possible.
>> >> >>
>> >> >> Agree.
>> >> >>
>> >> >> > Using crm_attribute to communicate the name of a master node would
>> >> >> > be
>> >> >> > consistent with the rest of the script since you already use it
>> >> >> > for
>> >> >> > communicating state of the nodes. If you prefer using crm_mon than
>> >> >> > you
>> >> >> > have
>> >> >> > to add a check that that binary exists on the server. In 99.99% of
>> >> >> > the
>> >> >> > case
>> >> >> > it will but still the check is necessary I think.
>> >> >>
>> >> >> I use crm_mon to check for node existence and node online too.
>> >> >> It is impossible to get it from attribute, so I prefer to using
>> >> >> crm_mon.
>> >> >>
>> >> >> Do I have to add a check for crm_master, crm_attribute,
>> >> >> crm_failcount
>> >> >> too?
>> >> >>
>> >> >
>> >> > That's a different  interesting topic. What is the reason for doing
>> >> > this?
>> >> >
>> >> > my_fail_count=`$CRM_FAILCOUNT -r $OCF_RESOURCE_INSTANCE -N $HOSTNAME
>> >> > -G
>> >> > -Q |
>> >> > sed "s/INFINITY/1000000/g"`
>> >> > if [ "$my_fail_count" != "0" ]; then
>> >> >       ocf_log info "I don't start PostgreSQL on post-demote because
>> >> > of
>> >> > my
>> >> > fail-count=$my_fail_count."
>> >> >       return $OCF_SUCCESS
>> >> > fi
>> >> >
>> >> > Why not to leave pacemaker to do its job on managing failcounts?
>> >>
>> >> Because I want to make fail-over faster.
>> >> At any rate Pacemaker stops it?
>> >
>> >
>> > I'm probably wrong here. Looks like you use this trick in case if
>> > slave's
>> > data is newer than new master's data. In this case it makes sense to
>> > disable
>> > such slave.
>>
>> Why do you think so ?
>> The check whether slave's data is newer than new master's one  is here.
>>
>> in pgsql_post_demote()
>> -------------------------------------------------------
>> 886 is_slave_right || return $OCF_ERR_GENERIC
>> -------------------------------------------------------
>>
>> This line is executed after this trick.
>>
>>
>>
>> Regards,
>> Takatoshi MATSUO
>>
>> _______________________________________________________
>> 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.
>

--
Takatoshi MATSUO
_______________________________________________________
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/
Re: pgsql and streaming replcation [ In reply to ]
matsuo.tak at gmail
Mar 6, 2012, 10:43 PM
Post #15 of 20 (6731 views)
Permalink
Hi Serge

I think about removing code of restarting PostgreSQL on demote.
Because almost restarts are failed to avoid data inconsistency.
In addition this check is complex.
PostgreSQL developer says that this occurrence is specific and
can't be fix immediately.

What do you think ?

Regards,
Takatoshi MATSUO

2012/2/6 Takatoshi MATSUO <matsuo.tak@gmail.com>:
> Hi Serge
>
> Thank you.
> I applied it to my repository.
>
>
> 2012/2/6 Serge Dubrouski <sergeyfd@gmail.com>:
>> Takatoshi -
>>
>> Please consider apllying attached patch to your version of pgsql RA. It's
>> all cosmetics: replacing tabs with spaces and improving English. Thanks for
>> implementing recommendations I expressed earlier.
>>
>>
>> On Tue, Dec 13, 2011 at 3:37 AM, Takatoshi MATSUO <matsuo.tak@gmail.com>
>> wrote:
>>>
>>> Hello Serge
>>>
>>> 2011/12/13 Serge Dubrouski <sergeyfd@gmail.com>:
>>> >
>>> >
>>> > On Mon, Dec 12, 2011 at 4:28 AM, Takatoshi MATSUO <matsuo.tak@gmail.com>
>>> > wrote:
>>> >>
>>> >> Hello Serge
>>> >>
>>> >> 2011/12/12 Serge Dubrouski <sergeyfd@gmail.com>:
>>> >> >
>>> >> >
>>> >> > On Thu, Dec 8, 2011 at 10:04 PM, Takatoshi MATSUO
>>> >> > <matsuo.tak@gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> Hello Serge
>>> >> >>
>>> >> >> 2011/12/8 Serge Dubrouski <sergeyfd@gmail.com>:
>>> >> >> >
>>> >> >> >
>>> >> >> > On Mon, Dec 5, 2011 at 9:15 PM, Takatoshi MATSUO
>>> >> >> > <matsuo.tak@gmail.com>
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> Hello Serge
>>> >> >> >>
>>> >> >> >> Serge Dubrouski <sergeyfd@gmail.com>:
>>> >> >> >> > Hello -
>>> >> >> >> >
>>> >> >> >> > Takatoshi MATSUO did a tremendous job on implementing support
>>> >> >> >> > for
>>> >> >> >> > streaming
>>> >> >> >> > replication feature in pgsql RA. Also it looks like PostgeSQL
>>> >> >> >> > 9.1
>>> >> >> >> > has
>>> >> >> >> > all
>>> >> >> >> > necessary interfaces to successfully implement  Pacemaker's M/S
>>> >> >> >> > concept.
>>> >> >> >> > So
>>> >> >> >> > I think it's time to start discussion on how to merge
>>> >> >> >> > Takatoshi's
>>> >> >> >> > work
>>> >> >> >> > into
>>> >> >> >> > pgsql RA baseline. Here is the link to Takatoshi's GitHUB if
>>> >> >> >> > somebody
>>> >> >> >> > wants
>>> >> >> >> > to test his RA:
>>> >> >> >> >
>>> >> >> >> > https://github.com/t-matsuo/
>>> >> >> >> >
>>> >> >> >> > So far I tested it for backward compatibility in a standard
>>> >> >> >> > non-replication
>>> >> >> >> > mode  and also tested M/S model and found no real issues.
>>> >> >> >> > Though
>>> >> >> >> > it
>>> >> >> >> > definitely requires some more polishing and testing.
>>> >> >> >> >
>>> >> >> >> > Takatoshi, here are some changes that I want to discuss with
>>> >> >> >> > you:
>>> >> >> >> >
>>> >> >> >> > 1. Is it possible to add a check for PostgreSQL version and
>>> >> >> >> > fail
>>> >> >> >> > with
>>> >> >> >> > OCF_ERR_INSTALLED when one tries to start replication on
>>> >> >> >> > version
>>> >> >> >> > less
>>> >> >> >> > than
>>> >> >> >> > 9.1? A simple cat on PG_VERSION with some analysis would
>>> >> >> >> > probably
>>> >> >> >> > do.
>>> >> >> >>
>>> >> >> >> I'll add a check.
>>> >> >>
>>> >> >> I added a check.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> https://github.com/t-matsuo/resource-agents/commit/3ab7cfdcce118043cd149b348740e50e7a946eb3
>>> >> >>
>>> >> >> >>
>>> >> >> >> > 2. I think that following lines should be moved from
>>> >> >> >> > pgsql_start
>>> >> >> >> > to
>>> >> >> >> > pgsql_validate_all
>>> >> >> >> >
>>> >> >> >> >  535     # Check whether tmpdir is readable by pgdba user
>>> >> >> >> >  536     if ! runasowner "test -r $OCF_RESKEY_tmpdir"; then
>>> >> >> >> >  537         ocf_log err "Directory $OCF_RESKEY_tmpdir is not
>>> >> >> >> > readable
>>> >> >> >> > by
>>> >> >> >> > $OCF_RESKEY_pgdba"
>>> >> >> >> >  538         return $OCF_ERR_PERM
>>> >> >> >> >  539     fi
>>> >> >> >>
>>> >> >> >> Thanks. I think so too.
>>> >> >> >> I'll fix it.
>>> >> >> >>
>>> >> >>
>>> >> >> I fixed it and I deleted a check for tmpdir existence
>>> >> >> because the checking for permittion fills the role.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> https://github.com/t-matsuo/resource-agents/commit/82d4939486bcca429e2deb804d7faf756099bb59
>>> >> >>
>>> >> >>
>>> >> >> > On a second thought I'm not sure why we need that parameter and
>>> >> >> > directory at
>>> >> >> > all. Why not to create rep_mode.conf, PGSQL.lock and xlog.note in
>>> >> >> > $OCF_RESKEY_pgdata ? What problems it can create?
>>> >> >> >
>>> >> >> > One more advantage to do
>>> >> >> > it in $OCF_RESKEY_pgdata is an ability to handle more than
>>> >> >> > PostgreSQL
>>> >> >> > instance on the same server without a need for additional temp
>>> >> >> > directories.
>>> >> >>
>>> >> >> When backup is needed, customers may backup these files and restore
>>> >> >> it.
>>> >> >> It may cause problems.
>>> >> >> Specially PGSQL.lock causes an error on start.
>>> >> >>
>>> >> >> I think that they should be treated as a separate thing.
>>> >> >> because they are independent from PostgreSQL's data.
>>> >> >
>>> >> >
>>> >> > Ok. Then may be it should default to something like
>>> >> > ${OCF_RESKEY_pgdata}/temp and RA should create it and set the right
>>> >> > ownership and permissions if it doesn't exist? And again may be in
>>> >> > this
>>> >> > case
>>> >> > we don't need that parameter?
>>> >> >
>>> >>
>>> >> I agree that RA creates it and sets the right ownership and
>>> >> permissions.
>>> >> But considering backup using tar command, I think it's not better to
>>> >> create it
>>> >> under $OCF_RESKEY_pgdata.
>>> >>
>>> >> According to "Filesystem Hierarchy Standard"
>>> >> it's better to use /var/lib/somewhere.
>>> >>
>>> >>
>>> >>
>>> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION,
>>> >>
>>> >> Then I designed using /var/lig/[RA Name] (=/var/lib/pgsql).
>>> >> What do you think?
>>> >
>>> >
>>> > Ahh, I see now where confusion comes from. /var/lib/pgsql is actually
>>> > taken
>>> > :-) It's used as default home directory in RedHat (at least) for
>>> > postgres
>>> > user in PostgreSQL 8.XX. When they'll start start shipping version 9
>>> > they'll
>>> > probably use it as well. OCF_RESKEY_pg_data  defaults to
>>> > /var/lib/pgsql/data.
>>> >
>>> > Then, /var/lib is usually used for non-temporary data, For temporary
>>> > files
>>> > it's probably better to use /var/run or /var/tmp. If you still want to
>>> > use
>>> > /var/lib/pgsql you probably need to use /var/lib/pgsql/temp or so.
>>>
>>> Files under /var/run or /var/tmp are cleared by tmpwatch or at the
>>> beginning
>>> of the boot process, aren't they?
>>>
>>> Clearing PGSQL.lock file causes problem.
>>>
>>>
>>> >
>>> >>
>>> >> >>
>>> >> >>
>>> >> >> Incidentally I considered to handle more than PostgreSQL instance.
>>> >> >> Initially I added port number to these filenames, but I deleted it
>>> >> >> to simplify filenames.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> https://github.com/t-matsuo/resource-agents/commit/b16faf2d797200048dc0fc07a45b6751cf5be190
>>> >> >>
>>> >> >>
>>> >> >> > Also I think it would be good if RA was able to take care of
>>> >> >> > adding
>>> >> >> > "include
>>> >> >> > $WHATEVER_DIR/rep_mode.conf" in postgresql.conf. It will make the
>>> >> >> > RA
>>> >> >> > self
>>> >> >> > sustainable. In a current situation admin has add that directive
>>> >> >> > manually.
>>> >> >> > RA though can something like this in a start function for
>>> >> >> > replication
>>> >> >> > mode:
>>> >> >> >
>>> >> >> > if ! grep -i "include $WHATEVER_DIR/rep_mode.conf"
>>> >> >> > $OCF_RESKEY_config
>>> >> >> > then
>>> >> >> >      echo "include $WHATEVER_DIR/rep_mode.conf" >>
>>> >> >> > $OCF_RESKEY_config
>>> >> >> > fi
>>> >> >>
>>> >> >> Sounds good.
>>> >> >>
>>> >> >> > Don't know if it makes sense to remove it on stop.
>>> >> >>
>>> >> >> I think it doesn't make sense to remove it,
>>> >> >> because rep_mode.conf becomes empty on stop.
>>> >> >
>>> >> >
>>> >> > The only problem here if admin changes temp_dir parameter but doesn't
>>> >> > delete
>>> >> > records from postgres.conf. We could end up with several include
>>> >> > records
>>> >> > then or with records pointing to the non existing files.
>>> >>
>>> >> Should we consider this situation?
>>> >>
>>> >> If same parameters exist, PostgreSQL uses last parameter.
>>> >> So I will implement it to add several include if temp_dir is changed.
>>> >
>>> >
>>> > The problem happens when file gets deleted but reference to it still
>>> > exists
>>> > in postgres.conf. They DB fails to start.
>>>
>>>
>>> Start manually?
>>> The RA manages some statuses using an attribute and PGSQL.lock file.
>>> I don't recommend starting it manually in the first place.
>>>
>>>
>>> How about just describing it in a document? meta-data?
>>>
>>>
>>> >
>>> >>
>>> >>
>>> >>
>>> >> >>
>>> >> >> >> > 3. I don't really like this part of pgsql_real_monitor:
>>> >> >> >> >
>>> >> >> >> >  775     if ! is_replication; then
>>> >> >> >> >  776         OCF_RESKEY_monitor_sql=`escape_string >
>>> >> >> >> > "$OCF_RESKEY_monitor_sql"`
>>> >> >> >> >  777         runasowner -q $loglevel "$OCF_RESKEY_psql
>>> >> >> >> > $psql_options
>>> >> >> >> > -c
>>> >> >> >> > > '$OCF_RESKEY_monitor_sql'"
>>> >> >> >> >  778         rc=$?
>>> >> >> >> >  779     else
>>> >> >> >> >  780         output=`su $OCF_RESKEY_pgdba -c "cd
>>> >> >> >> > $OCF_RESKEY_pgdata;
>>> >> >> >> > >
>>> >> >> >> > $OCF_RESKEY_psql $psql_options -Atc \"${CHECK_MS_SQL}\""`
>>> >> >> >> >  781         rc=$?
>>> >> >> >> >  782     fi
>>> >> >> >> >
>>> >> >> >> > I think that functional monitor (the one that uses monitor_sql)
>>> >> >> >> > should
>>> >> >> >> > run
>>> >> >> >> > always independently of DB mode since its primary role is to
>>> >> >> >> > check
>>> >> >> >> > data
>>> >> >> >> > and
>>> >> >> >> > fail if it's not correct or corrupted. In replication mode
>>> >> >> >> > there
>>> >> >> >> > should
>>> >> >> >> > be
>>> >> >> >> > additional monitoring. Other way it misleads customer on a
>>> >> >> >> > usage
>>> >> >> >> > of
>>> >> >> >> > monitor_sql.
>>> >> >> >>
>>> >> >> >> All right.
>>> >> >> >>
>>> >> >> >> Does it need to execute "select now();" if monitor_sql parameter
>>> >> >> >> is
>>> >> >> >> empty?
>>> >> >> >> I think it's unnecessary.
>>> >> >> >
>>> >> >> >
>>> >> >> > For a case of an empty parameter you are right and running "select
>>> >> >> > now()"
>>> >> >> > probably unnecessary, Non-empty monitro_sql shall be executed in
>>> >> >> > my
>>> >> >> > opinion.
>>> >> >> >
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> > 4. You already populate several attributes with crm_attribute.
>>> >> >> >> > Does
>>> >> >> >> > it
>>> >> >> >> > make
>>> >> >> >> > sense to populate a name of a Master node in promote function
>>> >> >> >> > and
>>> >> >> >> > use
>>> >> >> >> > it
>>> >> >> >> > later on instead of running crm_mon on each monitor command?
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >> Do you mean that you don't want to use crm_mon in monitor?
>>> >> >> >
>>> >> >> >
>>> >> >> > I prefer to have as few dependencies  on external programs as
>>> >> >> > possible.
>>> >> >>
>>> >> >> Agree.
>>> >> >>
>>> >> >> > Using crm_attribute to communicate the name of a master node would
>>> >> >> > be
>>> >> >> > consistent with the rest of the script since you already use it
>>> >> >> > for
>>> >> >> > communicating state of the nodes. If you prefer using crm_mon than
>>> >> >> > you
>>> >> >> > have
>>> >> >> > to add a check that that binary exists on the server. In 99.99% of
>>> >> >> > the
>>> >> >> > case
>>> >> >> > it will but still the check is necessary I think.
>>> >> >>
>>> >> >> I use crm_mon to check for node existence and node online too.
>>> >> >> It is impossible to get it from attribute, so I prefer to using
>>> >> >> crm_mon.
>>> >> >>
>>> >> >> Do I have to add a check for crm_master, crm_attribute,
>>> >> >> crm_failcount
>>> >> >> too?
>>> >> >>
>>> >> >
>>> >> > That's a different  interesting topic. What is the reason for doing
>>> >> > this?
>>> >> >
>>> >> > my_fail_count=`$CRM_FAILCOUNT -r $OCF_RESOURCE_INSTANCE -N $HOSTNAME
>>> >> > -G
>>> >> > -Q |
>>> >> > sed "s/INFINITY/1000000/g"`
>>> >> > if [ "$my_fail_count" != "0" ]; then
>>> >> >       ocf_log info "I don't start PostgreSQL on post-demote because
>>> >> > of
>>> >> > my
>>> >> > fail-count=$my_fail_count."
>>> >> >       return $OCF_SUCCESS
>>> >> > fi
>>> >> >
>>> >> > Why not to leave pacemaker to do its job on managing failcounts?
>>> >>
>>> >> Because I want to make fail-over faster.
>>> >> At any rate Pacemaker stops it?
>>> >
>>> >
>>> > I'm probably wrong here. Looks like you use this trick in case if
>>> > slave's
>>> > data is newer than new master's data. In this case it makes sense to
>>> > disable
>>> > such slave.
>>>
>>> Why do you think so ?
>>> The check whether slave's data is newer than new master's one  is here.
>>>
>>> in pgsql_post_demote()
>>> -------------------------------------------------------
>>> 886 is_slave_right || return $OCF_ERR_GENERIC
>>> -------------------------------------------------------
>>>
>>> This line is executed after this trick.
>>>
>>>
>>>
>>> Regards,
>>> Takatoshi MATSUO
>>>
>>> _______________________________________________________
>>> 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.
>>
>
> --
> Takatoshi MATSUO
_______________________________________________________
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/
Re: pgsql and streaming replcation [ In reply to ]
sergeyfd at gmail
Mar 7, 2012, 5:00 PM
Post #16 of 20 (6740 views)
Permalink
Hello, Takatoshi -

On one hand this is a good feature to have, but on another if it's not
stable, fails most of the time and brings to much of complexity to the RA
then drop it. It seems like Andrew has plans to include support for
stopping resources on demote in the future versions of Pacemaker.


On Tue, Mar 6, 2012 at 11:43 PM, Takatoshi MATSUO <matsuo.tak@gmail.com>wrote:

> Hi Serge
>
> I think about removing code of restarting PostgreSQL on demote.
> Because almost restarts are failed to avoid data inconsistency.
> In addition this check is complex.
> PostgreSQL developer says that this occurrence is specific and
> can't be fix immediately.
>
> What do you think ?
>
> Regards,
> Takatoshi MATSUO
>
> 2012/2/6 Takatoshi MATSUO <matsuo.tak@gmail.com>:
> > Hi Serge
> >
> > Thank you.
> > I applied it to my repository.
> >
> >
> > 2012/2/6 Serge Dubrouski <sergeyfd@gmail.com>:
> >> Takatoshi -
> >>
> >> Please consider apllying attached patch to your version of pgsql RA.
> It's
> >> all cosmetics: replacing tabs with spaces and improving English. Thanks
> for
> >> implementing recommendations I expressed earlier.
> >>
> >>
> >> On Tue, Dec 13, 2011 at 3:37 AM, Takatoshi MATSUO <matsuo.tak@gmail.com
> >
> >> wrote:
> >>>
> >>> Hello Serge
> >>>
> >>> 2011/12/13 Serge Dubrouski <sergeyfd@gmail.com>:
> >>> >
> >>> >
> >>> > On Mon, Dec 12, 2011 at 4:28 AM, Takatoshi MATSUO <
> matsuo.tak@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> Hello Serge
> >>> >>
> >>> >> 2011/12/12 Serge Dubrouski <sergeyfd@gmail.com>:
> >>> >> >
> >>> >> >
> >>> >> > On Thu, Dec 8, 2011 at 10:04 PM, Takatoshi MATSUO
> >>> >> > <matsuo.tak@gmail.com>
> >>> >> > wrote:
> >>> >> >>
> >>> >> >> Hello Serge
> >>> >> >>
> >>> >> >> 2011/12/8 Serge Dubrouski <sergeyfd@gmail.com>:
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > On Mon, Dec 5, 2011 at 9:15 PM, Takatoshi MATSUO
> >>> >> >> > <matsuo.tak@gmail.com>
> >>> >> >> > wrote:
> >>> >> >> >>
> >>> >> >> >> Hello Serge
> >>> >> >> >>
> >>> >> >> >> Serge Dubrouski <sergeyfd@gmail.com>:
> >>> >> >> >> > Hello -
> >>> >> >> >> >
> >>> >> >> >> > Takatoshi MATSUO did a tremendous job on implementing
> support
> >>> >> >> >> > for
> >>> >> >> >> > streaming
> >>> >> >> >> > replication feature in pgsql RA. Also it looks like
> PostgeSQL
> >>> >> >> >> > 9.1
> >>> >> >> >> > has
> >>> >> >> >> > all
> >>> >> >> >> > necessary interfaces to successfully implement Pacemaker's
> M/S
> >>> >> >> >> > concept.
> >>> >> >> >> > So
> >>> >> >> >> > I think it's time to start discussion on how to merge
> >>> >> >> >> > Takatoshi's
> >>> >> >> >> > work
> >>> >> >> >> > into
> >>> >> >> >> > pgsql RA baseline. Here is the link to Takatoshi's GitHUB if
> >>> >> >> >> > somebody
> >>> >> >> >> > wants
> >>> >> >> >> > to test his RA:
> >>> >> >> >> >
> >>> >> >> >> > https://github.com/t-matsuo/
> >>> >> >> >> >
> >>> >> >> >> > So far I tested it for backward compatibility in a standard
> >>> >> >> >> > non-replication
> >>> >> >> >> > mode and also tested M/S model and found no real issues.
> >>> >> >> >> > Though
> >>> >> >> >> > it
> >>> >> >> >> > definitely requires some more polishing and testing.
> >>> >> >> >> >
> >>> >> >> >> > Takatoshi, here are some changes that I want to discuss with
> >>> >> >> >> > you:
> >>> >> >> >> >
> >>> >> >> >> > 1. Is it possible to add a check for PostgreSQL version and
> >>> >> >> >> > fail
> >>> >> >> >> > with
> >>> >> >> >> > OCF_ERR_INSTALLED when one tries to start replication on
> >>> >> >> >> > version
> >>> >> >> >> > less
> >>> >> >> >> > than
> >>> >> >> >> > 9.1? A simple cat on PG_VERSION with some analysis would
> >>> >> >> >> > probably
> >>> >> >> >> > do.
> >>> >> >> >>
> >>> >> >> >> I'll add a check.
> >>> >> >>
> >>> >> >> I added a check.
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >>
> https://github.com/t-matsuo/resource-agents/commit/3ab7cfdcce118043cd149b348740e50e7a946eb3
> >>> >> >>
> >>> >> >> >>
> >>> >> >> >> > 2. I think that following lines should be moved from
> >>> >> >> >> > pgsql_start
> >>> >> >> >> > to
> >>> >> >> >> > pgsql_validate_all
> >>> >> >> >> >
> >>> >> >> >> > 535 # Check whether tmpdir is readable by pgdba user
> >>> >> >> >> > 536 if ! runasowner "test -r $OCF_RESKEY_tmpdir"; then
> >>> >> >> >> > 537 ocf_log err "Directory $OCF_RESKEY_tmpdir is
> not
> >>> >> >> >> > readable
> >>> >> >> >> > by
> >>> >> >> >> > $OCF_RESKEY_pgdba"
> >>> >> >> >> > 538 return $OCF_ERR_PERM
> >>> >> >> >> > 539 fi
> >>> >> >> >>
> >>> >> >> >> Thanks. I think so too.
> >>> >> >> >> I'll fix it.
> >>> >> >> >>
> >>> >> >>
> >>> >> >> I fixed it and I deleted a check for tmpdir existence
> >>> >> >> because the checking for permittion fills the role.
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >>
> https://github.com/t-matsuo/resource-agents/commit/82d4939486bcca429e2deb804d7faf756099bb59
> >>> >> >>
> >>> >> >>
> >>> >> >> > On a second thought I'm not sure why we need that parameter and
> >>> >> >> > directory at
> >>> >> >> > all. Why not to create rep_mode.conf, PGSQL.lock and xlog.note
> in
> >>> >> >> > $OCF_RESKEY_pgdata ? What problems it can create?
> >>> >> >> >
> >>> >> >> > One more advantage to do
> >>> >> >> > it in $OCF_RESKEY_pgdata is an ability to handle more than
> >>> >> >> > PostgreSQL
> >>> >> >> > instance on the same server without a need for additional temp
> >>> >> >> > directories.
> >>> >> >>
> >>> >> >> When backup is needed, customers may backup these files and
> restore
> >>> >> >> it.
> >>> >> >> It may cause problems.
> >>> >> >> Specially PGSQL.lock causes an error on start.
> >>> >> >>
> >>> >> >> I think that they should be treated as a separate thing.
> >>> >> >> because they are independent from PostgreSQL's data.
> >>> >> >
> >>> >> >
> >>> >> > Ok. Then may be it should default to something like
> >>> >> > ${OCF_RESKEY_pgdata}/temp and RA should create it and set the
> right
> >>> >> > ownership and permissions if it doesn't exist? And again may be in
> >>> >> > this
> >>> >> > case
> >>> >> > we don't need that parameter?
> >>> >> >
> >>> >>
> >>> >> I agree that RA creates it and sets the right ownership and
> >>> >> permissions.
> >>> >> But considering backup using tar command, I think it's not better to
> >>> >> create it
> >>> >> under $OCF_RESKEY_pgdata.
> >>> >>
> >>> >> According to "Filesystem Hierarchy Standard"
> >>> >> it's better to use /var/lib/somewhere.
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION
> ,
> >>> >>
> >>> >> Then I designed using /var/lig/[RA Name] (=/var/lib/pgsql).
> >>> >> What do you think?
> >>> >
> >>> >
> >>> > Ahh, I see now where confusion comes from. /var/lib/pgsql is actually
> >>> > taken
> >>> > :-) It's used as default home directory in RedHat (at least) for
> >>> > postgres
> >>> > user in PostgreSQL 8.XX. When they'll start start shipping version 9
> >>> > they'll
> >>> > probably use it as well. OCF_RESKEY_pg_data defaults to
> >>> > /var/lib/pgsql/data.
> >>> >
> >>> > Then, /var/lib is usually used for non-temporary data, For temporary
> >>> > files
> >>> > it's probably better to use /var/run or /var/tmp. If you still want
> to
> >>> > use
> >>> > /var/lib/pgsql you probably need to use /var/lib/pgsql/temp or so.
> >>>
> >>> Files under /var/run or /var/tmp are cleared by tmpwatch or at the
> >>> beginning
> >>> of the boot process, aren't they?
> >>>
> >>> Clearing PGSQL.lock file causes problem.
> >>>
> >>>
> >>> >
> >>> >>
> >>> >> >>
> >>> >> >>
> >>> >> >> Incidentally I considered to handle more than PostgreSQL
> instance.
> >>> >> >> Initially I added port number to these filenames, but I deleted
> it
> >>> >> >> to simplify filenames.
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >>
> https://github.com/t-matsuo/resource-agents/commit/b16faf2d797200048dc0fc07a45b6751cf5be190
> >>> >> >>
> >>> >> >>
> >>> >> >> > Also I think it would be good if RA was able to take care of
> >>> >> >> > adding
> >>> >> >> > "include
> >>> >> >> > $WHATEVER_DIR/rep_mode.conf" in postgresql.conf. It will make
> the
> >>> >> >> > RA
> >>> >> >> > self
> >>> >> >> > sustainable. In a current situation admin has add that
> directive
> >>> >> >> > manually.
> >>> >> >> > RA though can something like this in a start function for
> >>> >> >> > replication
> >>> >> >> > mode:
> >>> >> >> >
> >>> >> >> > if ! grep -i "include $WHATEVER_DIR/rep_mode.conf"
> >>> >> >> > $OCF_RESKEY_config
> >>> >> >> > then
> >>> >> >> > echo "include $WHATEVER_DIR/rep_mode.conf" >>
> >>> >> >> > $OCF_RESKEY_config
> >>> >> >> > fi
> >>> >> >>
> >>> >> >> Sounds good.
> >>> >> >>
> >>> >> >> > Don't know if it makes sense to remove it on stop.
> >>> >> >>
> >>> >> >> I think it doesn't make sense to remove it,
> >>> >> >> because rep_mode.conf becomes empty on stop.
> >>> >> >
> >>> >> >
> >>> >> > The only problem here if admin changes temp_dir parameter but
> doesn't
> >>> >> > delete
> >>> >> > records from postgres.conf. We could end up with several include
> >>> >> > records
> >>> >> > then or with records pointing to the non existing files.
> >>> >>
> >>> >> Should we consider this situation?
> >>> >>
> >>> >> If same parameters exist, PostgreSQL uses last parameter.
> >>> >> So I will implement it to add several include if temp_dir is
> changed.
> >>> >
> >>> >
> >>> > The problem happens when file gets deleted but reference to it still
> >>> > exists
> >>> > in postgres.conf. They DB fails to start.
> >>>
> >>>
> >>> Start manually?
> >>> The RA manages some statuses using an attribute and PGSQL.lock file.
> >>> I don't recommend starting it manually in the first place.
> >>>
> >>>
> >>> How about just describing it in a document? meta-data?
> >>>
> >>>
> >>> >
> >>> >>
> >>> >>
> >>> >>
> >>> >> >>
> >>> >> >> >> > 3. I don't really like this part of pgsql_real_monitor:
> >>> >> >> >> >
> >>> >> >> >> > 775 if ! is_replication; then
> >>> >> >> >> > 776 OCF_RESKEY_monitor_sql=`escape_string >
> >>> >> >> >> > "$OCF_RESKEY_monitor_sql"`
> >>> >> >> >> > 777 runasowner -q $loglevel "$OCF_RESKEY_psql
> >>> >> >> >> > $psql_options
> >>> >> >> >> > -c
> >>> >> >> >> > > '$OCF_RESKEY_monitor_sql'"
> >>> >> >> >> > 778 rc=$?
> >>> >> >> >> > 779 else
> >>> >> >> >> > 780 output=`su $OCF_RESKEY_pgdba -c "cd
> >>> >> >> >> > $OCF_RESKEY_pgdata;
> >>> >> >> >> > >
> >>> >> >> >> > $OCF_RESKEY_psql $psql_options -Atc \"${CHECK_MS_SQL}\""`
> >>> >> >> >> > 781 rc=$?
> >>> >> >> >> > 782 fi
> >>> >> >> >> >
> >>> >> >> >> > I think that functional monitor (the one that uses
> monitor_sql)
> >>> >> >> >> > should
> >>> >> >> >> > run
> >>> >> >> >> > always independently of DB mode since its primary role is to
> >>> >> >> >> > check
> >>> >> >> >> > data
> >>> >> >> >> > and
> >>> >> >> >> > fail if it's not correct or corrupted. In replication mode
> >>> >> >> >> > there
> >>> >> >> >> > should
> >>> >> >> >> > be
> >>> >> >> >> > additional monitoring. Other way it misleads customer on a
> >>> >> >> >> > usage
> >>> >> >> >> > of
> >>> >> >> >> > monitor_sql.
> >>> >> >> >>
> >>> >> >> >> All right.
> >>> >> >> >>
> >>> >> >> >> Does it need to execute "select now();" if monitor_sql
> parameter
> >>> >> >> >> is
> >>> >> >> >> empty?
> >>> >> >> >> I think it's unnecessary.
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > For a case of an empty parameter you are right and running
> "select
> >>> >> >> > now()"
> >>> >> >> > probably unnecessary, Non-empty monitro_sql shall be executed
> in
> >>> >> >> > my
> >>> >> >> > opinion.
> >>> >> >> >
> >>> >> >> >>
> >>> >> >> >>
> >>> >> >> >> > 4. You already populate several attributes with
> crm_attribute.
> >>> >> >> >> > Does
> >>> >> >> >> > it
> >>> >> >> >> > make
> >>> >> >> >> > sense to populate a name of a Master node in promote
> function
> >>> >> >> >> > and
> >>> >> >> >> > use
> >>> >> >> >> > it
> >>> >> >> >> > later on instead of running crm_mon on each monitor command?
> >>> >> >> >> >
> >>> >> >> >>
> >>> >> >> >> Do you mean that you don't want to use crm_mon in monitor?
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > I prefer to have as few dependencies on external programs as
> >>> >> >> > possible.
> >>> >> >>
> >>> >> >> Agree.
> >>> >> >>
> >>> >> >> > Using crm_attribute to communicate the name of a master node
> would
> >>> >> >> > be
> >>> >> >> > consistent with the rest of the script since you already use it
> >>> >> >> > for
> >>> >> >> > communicating state of the nodes. If you prefer using crm_mon
> than
> >>> >> >> > you
> >>> >> >> > have
> >>> >> >> > to add a check that that binary exists on the server. In
> 99.99% of
> >>> >> >> > the
> >>> >> >> > case
> >>> >> >> > it will but still the check is necessary I think.
> >>> >> >>
> >>> >> >> I use crm_mon to check for node existence and node online too.
> >>> >> >> It is impossible to get it from attribute, so I prefer to using
> >>> >> >> crm_mon.
> >>> >> >>
> >>> >> >> Do I have to add a check for crm_master, crm_attribute,
> >>> >> >> crm_failcount
> >>> >> >> too?
> >>> >> >>
> >>> >> >
> >>> >> > That's a different interesting topic. What is the reason for
> doing
> >>> >> > this?
> >>> >> >
> >>> >> > my_fail_count=`$CRM_FAILCOUNT -r $OCF_RESOURCE_INSTANCE -N
> $HOSTNAME
> >>> >> > -G
> >>> >> > -Q |
> >>> >> > sed "s/INFINITY/1000000/g"`
> >>> >> > if [ "$my_fail_count" != "0" ]; then
> >>> >> > ocf_log info "I don't start PostgreSQL on post-demote
> because
> >>> >> > of
> >>> >> > my
> >>> >> > fail-count=$my_fail_count."
> >>> >> > return $OCF_SUCCESS
> >>> >> > fi
> >>> >> >
> >>> >> > Why not to leave pacemaker to do its job on managing failcounts?
> >>> >>
> >>> >> Because I want to make fail-over faster.
> >>> >> At any rate Pacemaker stops it?
> >>> >
> >>> >
> >>> > I'm probably wrong here. Looks like you use this trick in case if
> >>> > slave's
> >>> > data is newer than new master's data. In this case it makes sense to
> >>> > disable
> >>> > such slave.
> >>>
> >>> Why do you think so ?
> >>> The check whether slave's data is newer than new master's one is here.
> >>>
> >>> in pgsql_post_demote()
> >>> -------------------------------------------------------
> >>> 886 is_slave_right || return $OCF_ERR_GENERIC
> >>> -------------------------------------------------------
> >>>
> >>> This line is executed after this trick.
> >>>
> >>>
> >>>
> >>> Regards,
> >>> Takatoshi MATSUO
> >>>
> >>> _______________________________________________________
> >>> 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.
> >>
> >
> > --
> > Takatoshi MATSUO
> _______________________________________________________
> 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.
Re: pgsql and streaming replcation [ In reply to ]
matsuo.tak at gmail
Mar 8, 2012, 5:07 PM
Post #17 of 20 (6728 views)
Permalink
Hello Serge

2012/3/8 Serge Dubrouski <sergeyfd@gmail.com>:
> Hello, Takatoshi -
>
> On one hand this is a good feature to have, but on another if it's not
> stable, fails most of the time and brings to much of complexity to the RA
> then drop it.
> It seems like Andrew has plans to include support for stopping
> resources on demote in the future versions of Pacemaker.

It's a good news.
I will remove code of restarting for the future.
Please accept a little complexity until future version is released.

>
> On Tue, Mar 6, 2012 at 11:43 PM, Takatoshi MATSUO <matsuo.tak@gmail.com>
> wrote:
>>
>> Hi Serge
>>
>> I think about removing code of restarting PostgreSQL on demote.
>> Because almost restarts are failed to avoid data inconsistency.
>> In addition this check is complex.
>> PostgreSQL developer says that this occurrence is specific and
>> can't be fix immediately.
>>
>> What do you think ?

Regards,
Takatoshi MATSUO
_______________________________________________________
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/
Re: pgsql and streaming replcation [ In reply to ]
matsuo.tak at gmail
Mar 13, 2012, 4:35 AM
Post #18 of 20 (6727 views)
Permalink
Hello Serge

2012/3/9 Takatoshi MATSUO <matsuo.tak@gmail.com>:
> Hello Serge
>
> 2012/3/8 Serge Dubrouski <sergeyfd@gmail.com>:
>> Hello, Takatoshi -
>>
>> On one hand this is a good feature to have, but on another if it's not
>> stable, fails most of the time and brings to much of complexity to the RA
>> then drop it.
>> It seems like Andrew has plans to include support for stopping
>> resources on demote in the future versions of Pacemaker.
>
> It's a good news.
> I will remove code of restarting for the future.
> Please accept a little complexity until future version is released.

I removed code of restarting
and I reconsider some checks of inconsistency.

In this change
PGSQL.lock file is created on promote
and it's removed on demote only if there is no Slave.
And I removed a complex check before start
such as checking Timeline ID , Checkpoint
because PGSQL.lock can means inconsistency.

I want to adopt a serious stance for merging by now.
Do you have any other comments ?
And what's the first step for merging ?

>>
>> On Tue, Mar 6, 2012 at 11:43 PM, Takatoshi MATSUO <matsuo.tak@gmail.com>
>> wrote:
>>>
>>> Hi Serge
>>>
>>> I think about removing code of restarting PostgreSQL on demote.
>>> Because almost restarts are failed to avoid data inconsistency.
>>> In addition this check is complex.
>>> PostgreSQL developer says that this occurrence is specific and
>>> can't be fix immediately.
>>>
>>> What do you think ?

Regartds,
Takatoshi MTSUO
_______________________________________________________
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/
Re: pgsql and streaming replcation [ In reply to ]
sergeyfd at gmail
Mar 13, 2012, 7:41 PM
Post #19 of 20 (6693 views)
Permalink
Takatoshi -

Please give me some time to review the latest version of RA and then we'll
submit a patch.

On Tue, Mar 13, 2012 at 5:35 AM, Takatoshi MATSUO <matsuo.tak@gmail.com>wrote:

> Hello Serge
>
> 2012/3/9 Takatoshi MATSUO <matsuo.tak@gmail.com>:
> > Hello Serge
> >
> > 2012/3/8 Serge Dubrouski <sergeyfd@gmail.com>:
> >> Hello, Takatoshi -
> >>
> >> On one hand this is a good feature to have, but on another if it's not
> >> stable, fails most of the time and brings to much of complexity to the
> RA
> >> then drop it.
> >> It seems like Andrew has plans to include support for stopping
> >> resources on demote in the future versions of Pacemaker.
> >
> > It's a good news.
> > I will remove code of restarting for the future.
> > Please accept a little complexity until future version is released.
>
> I removed code of restarting
> and I reconsider some checks of inconsistency.
>
> In this change
> PGSQL.lock file is created on promote
> and it's removed on demote only if there is no Slave.
> And I removed a complex check before start
> such as checking Timeline ID , Checkpoint
> because PGSQL.lock can means inconsistency.
>
> I want to adopt a serious stance for merging by now.
> Do you have any other comments ?
> And what's the first step for merging ?
>
> >>
> >> On Tue, Mar 6, 2012 at 11:43 PM, Takatoshi MATSUO <matsuo.tak@gmail.com
> >
> >> wrote:
> >>>
> >>> Hi Serge
> >>>
> >>> I think about removing code of restarting PostgreSQL on demote.
> >>> Because almost restarts are failed to avoid data inconsistency.
> >>> In addition this check is complex.
> >>> PostgreSQL developer says that this occurrence is specific and
> >>> can't be fix immediately.
> >>>
> >>> What do you think ?
>
> Regartds,
> Takatoshi MTSUO
> _______________________________________________________
> 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.
Re: pgsql and streaming replcation [ In reply to ]
sergeyfd at gmail
Mar 18, 2012, 9:05 AM
Post #20 of 20 (6696 views)
Permalink
I sent a patch to the mail list. It's your RA but in some places I split
long lines into several ones.

On Tue, Mar 13, 2012 at 8:41 PM, Serge Dubrouski <sergeyfd@gmail.com> wrote:

> Takatoshi -
>
> Please give me some time to review the latest version of RA and then we'll
> submit a patch.
>
> On Tue, Mar 13, 2012 at 5:35 AM, Takatoshi MATSUO <matsuo.tak@gmail.com>wrote:
>
>> Hello Serge
>>
>> 2012/3/9 Takatoshi MATSUO <matsuo.tak@gmail.com>:
>> > Hello Serge
>> >
>> > 2012/3/8 Serge Dubrouski <sergeyfd@gmail.com>:
>> >> Hello, Takatoshi -
>> >>
>> >> On one hand this is a good feature to have, but on another if it's not
>> >> stable, fails most of the time and brings to much of complexity to the
>> RA
>> >> then drop it.
>> >> It seems like Andrew has plans to include support for stopping
>> >> resources on demote in the future versions of Pacemaker.
>> >
>> > It's a good news.
>> > I will remove code of restarting for the future.
>> > Please accept a little complexity until future version is released.
>>
>> I removed code of restarting
>> and I reconsider some checks of inconsistency.
>>
>> In this change
>> PGSQL.lock file is created on promote
>> and it's removed on demote only if there is no Slave.
>> And I removed a complex check before start
>> such as checking Timeline ID , Checkpoint
>> because PGSQL.lock can means inconsistency.
>>
>> I want to adopt a serious stance for merging by now.
>> Do you have any other comments ?
>> And what's the first step for merging ?
>>
>> >>
>> >> On Tue, Mar 6, 2012 at 11:43 PM, Takatoshi MATSUO <
>> matsuo.tak@gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi Serge
>> >>>
>> >>> I think about removing code of restarting PostgreSQL on demote.
>> >>> Because almost restarts are failed to avoid data inconsistency.
>> >>> In addition this check is complex.
>> >>> PostgreSQL developer says that this occurrence is specific and
>> >>> can't be fix immediately.
>> >>>
>> >>> What do you think ?
>>
>> Regartds,
>> Takatoshi MTSUO
>> _______________________________________________________
>> 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.
>



--
Serge Dubrouski.

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal