<div dir="ltr"><div><div><div><div><div>Hi, Bartosz<br><br></div>First of all, we are using openstack-dev for such discussions.<br><br></div>Second, there is also Percona's RA for Percona XtraDB Cluster, which looks like pretty similar, although it is written in Perl. May be we could derive something useful from it.<br>
</div><div><br></div>Next, if you are working on this stuff, let's make it as open for the community as possible. There is a blueprint for Galera OCF script: <a href="https://blueprints.launchpad.net/fuel/+spec/reliable-galera-ocf-script">https://blueprints.launchpad.net/fuel/+spec/reliable-galera-ocf-script</a>. It would be awesome if you wrote down the specification and sent  newer galera ocf code change request to fuel-library gerrit.<br>
<br></div>Speaking of crm_attribute stuff. I am very surprised that you are saying that node attributes are altered by crm shadow commit. We are using similar approach in our scripts and have never faced this issue.<br><br>
</div>Corosync 2.x support is in our roadmap, but we are not sure that we will use Corosync 2.x earlier than 6.x release series start.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 27, 2014 at 3:08 PM, Bartosz Kupidura <span dir="ltr"><<a href="mailto:bkupidura@mirantis.com" target="_blank">bkupidura@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello guys!<br>
I would like to start discussion on a new resource agent for galera/pacemaker.<br>
<br>
Main features:<br>
* Support cluster boostrap<br>
* Support reboot any node in cluster<br>
* Support reboot whole cluster<br>
* To determine which node have latest DB version, we should use galera GTID (Global Transaction ID)<br>
* Node with latest GTID is galera PC (primary component) in case of reelection<br>
* Administrator can manually set node as PC<br>
<br>
GTID:<br>
* get GTID from mysqld --wsrep-recover or SQL query 'SHOW STATUS LIKE ‚wsrep_local_state_uuid''<br>
* store GTID as crm_attribute for node (crm_attribute --node $HOSTNAME --lifetime $LIFETIME --name gtid --update $GTID)<br>
* on every monitor/stop/start action update GTID for given node<br>
* GTID can have 3 format:<br>
 - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX:123 - standard cluster-id:commit-id<br>
 - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX:-1 - standard non initialized cluster, 00000000-0000-0000-0000-000000000000:-1<br>
 - XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX:INF - commit-id manually set to INF, force RA to create new cluster, with master on given node<br>
<br>
Check if reelection of PC is needed:<br>
* (node is located in partition with quorum OR we have only 1 node configured in cluster) AND galera resource is not running on any node<br>
* GTID is manually set to INF on given node<br>
<br>
Check if given node is PC:<br>
* have highest GTID in cluster, in case we have more than one node with „highest” GTID, we use CRC32 to choose proper PC.<br>
* GTID is manually set to INF<br>
* in case node with highest GTID will not come back after cluster reboot (for example disk failure) administrator should set GTID to INF on other node<br>
<br>
I have almost ready RA: <a href="http://zynzel.spof.pl/mysql-wss" target="_blank">http://zynzel.spof.pl/mysql-wss</a><br>
<br>
Tested with vanila centos galera/pacemaker/corosync - OK<br>
Tested with Fuel 4.1 - Fail<br>
<br>
<br>
Fuel 4.1 with that RA will not deploy correctly, because we use crm_attribute to store GTID, and in manifest we use cs_shadow/cs_commit for every pacemaker resource.<br>
This lead to cs_commit problem with different configuration in shadow copy and running configuration (running config changed by RA).<br>
"Could not commit shadow instance [..] to the CIB: Application of an update diff failed”<br>
<br>
To solve this we can go in 2 ways:<br>
1) dont use cs_commit/cs_shadow in manifests<br>
2) store GTID in other way than crm_attribute<br>
<br>
IMHO 2) is better (less invasive) and we can store GTID in corosync CMAP (<a href="http://www.polarhome.com/service/man/generic.php?qf=corosync-cmapctl" target="_blank">http://www.polarhome.com/service/man/generic.php?qf=corosync-cmapctl</a>), but this require corosync 2.X<br>

<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Mailing list: <a href="https://launchpad.net/~fuel-dev" target="_blank">https://launchpad.net/~fuel-dev</a><br>
Post to     : <a href="mailto:fuel-dev@lists.launchpad.net">fuel-dev@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~fuel-dev" target="_blank">https://launchpad.net/~fuel-dev</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>
45bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div>

</div>