Marian, a few more comments:
> mysql_notify() {
> if [ "$OCF_RESKEY_CRM_meta_notify_type" != 'post' ]; then
> return $OCF_SUCCESS
> fi
> case "$OCF_RESKEY_CRM_meta_notify_operation" in
> 'promote')
> if [ "$OCF_RESKEY_CRM_meta_notify_promote_uname" != "$HOSTNAME "
> ] &&
> ! is_slave 1; then
> mysql_demote 1
> fi
> ;;
Now wait a minute. You are being _notified_ that some other node just
got promoted. You can't demote yourself here now. It's Pacemaker's job
to decide that.
> 'demote')
> if [ "$OCF_RESKEY_CRM_meta_notify_promote_uname" = "$HOSTNAME " ]
> &&
> ! is_slave 1; then
> mysql_demote 1
> fi
Same thing here. You are just being _told_ that a demotion just
happened. That's no reason for demoting yourself.
Sorry for quoting myself here; I wrote this about promote/demote/notify
a few days ago and have yet to be corrected -- I wouldn't mind at all
being corrected, though. :)
> What you want to do, IMHO, is this:
>
> * promote operation:
> - Unset read-only mode.
> - Pacemaker will take care of notifying the slaves of the new master
>
> * demote operation:
> - essentially a no-op. During demote, you may not have a clue which
> box is the new master, in fact there may not be one in the cluster at
> all if the admin just typed in "crm resource demote <your_ms_resource>.
> So there's no point in reconfiguring a master as a slave during a
> demote. The only thing you may want to to is set it to read-only mode.
>
> * notify operation:
> - post-promote: you've just been informed of the new master. STOP SLAVE,
> SET MASTER TO, START SLAVE.
> - post-demote: you've just been informed that there currently is no
> master. STOP SLAVE. Keep running in read-only mode.
>
> * start operation:
> - Just like in a standalone MySQL resource, except that you set
> read-only mode.
Thoughts?
Cheers,
Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
