<p dir="ltr"><br>
On 01/03/2016 3:08 AM, "Eric Robinson" <<a href="mailto:eric.robinson@psmnv.com">eric.robinson@psmnv.com</a>> wrote:<br>
><br>
> >> That approach does not really work because if you stop resource<br>
> >> p_mysql_002 (for example) then all the other resources in the group stop too!<br>
> >><br>
> > Still dont understand whats your problem with that.<br>
><br>
> Each mysql instance is for a different customer. If I need to stop or restart one customer's database, or remove the resource from the group (perhaps because I lost the customer or I need to move their database to a different server for load distribution), then I don't all the other customers' databases going down too!</p>
<p dir="ltr">It's just a matter of design, the way you have it setup atm will not work of course. If you have them set as in my example:</p>
<p dir="ltr">group g_drbd0 p_lvm_drbd0 p_fs_clust1 p_vip_clust1 p_mysql_001<br>
group g_drbd1 p_lvm_drbd1 p_fs_clust2 p_vip_clust2 p_mysql_002<br>
.<br>
.<br>
.<br>
group g_drbd99 p_lvm_drbd99 p_fs_clust100 p_vip_clust100 p_mysql_100</p>
<p dir="ltr">then each mysql instance gets its own VIP instead of shared one as in your case. Then during migration you move the group and the backing drbd device will get promoted to master on the other node and the whole group will follow.</p>
<p dir="ltr">There are many ways to skin the cat.</p>
<p dir="ltr">><br>
> --Eric<br>
</p>