Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Mon, Feb 29, 2016 at 7:52 AM, Igor Cicimov <icicimov at gmail.com> wrote: > > On 28/02/2016 1:19 PM, "Eric Robinson" <eric.robinson at psmnv.com> wrote: > > > > > That's exactly what this configuration gives you right? Each group is > collocated > > > with one and only one drbd device on the master node. Regarding > starting/stopping of > > > the resources tied up together in the same group. I guess after adding > MySQL > > > the user case would be: > > > > >group g_drbd0 p_lvm_drbd0 p_fs_clust17 p_vip_clust17 p_mysql_001 > p_mysql_002 ... > > > > That approach does not really work because if you stop resource > p_mysql_002 (for example) then all the other resources in the group stop > too! > > > Still dont understand whats your problem with that. > > > >> And what was wrong with my constraints? > > > You had left the Filesystem out of the picture. > > > > You're right. I added the filesystem back into the picture and now it > works either way, with my original constraints or yours, at least for drbd, > lvm, the filesystem, and the VIP. However, it still does not work for the > mysql resources. As soon as I add the mysql resources, then when I fail > over, everything goes to crap. > > > > On my other clusters, my constrains look like the following and they > work great. I can stop and start any mysql resource without affecting any > other resource, but all the mysql resources are still dependent on the > underlying ones (drbd, fs, vip). > > > > Here's a working sample from one of my other clusters... > > > > colocation c_clust10 inf: ( p_mysql_001 p_mysql_003 p_mysql_043 > p_mysql_075 p_mysql_092 ) p_vip_clust10 p_fs_clust10 ms_drbd0:Master > Ah the VIP of course as I suspected, yep you can't use groups in this case. > > colocation c_clust11 inf: ( p_mysql_124 p_mysql_098 p_mysql_287 > p_mysql_346 p_mysql_685 ) p_vip_clust11 p_fs_clust11 ms_drbd1:Master > > order o_clust10 inf: ms_drbd0:promote p_fs_clust10 p_vip_clust10 ( > p_mysql_001 p_mysql_003 p_mysql_043 p_mysql_075 p_mysql_092 ) > > order o_clust11 inf: ms_drbd1:promote p_fs_clust11 p_vip_clust11 ( > p_mysql_124 p_mysql_098 p_mysql_287 p_mysql_346 p_mysql_685 ) > > > > However, that did not work with this newer cluster. It looks like there > has been a syntactical change in the CRM. The following approach does work. > Note the different usage of parenthesis. > > > > colocation c_clust17 inf: ( p_mysql_557 p_mysql_690 p_vip_clust17 > p_fs_clust17 p_lvm_drbd0 ) ms_drbd0:Master > > colocation c_clust18 inf: ( p_vip_clust18 p_fs_clust18 p_lvm_drbd1 ) > ms_drbd1:Master > > order o_clust17 inf: ms_drbd0:promote ( p_lvm_drbd0:start ) ( > p_fs_clust17 p_vip_clust17 ) ( p_mysql_557 p_mysql_690 ) > > order o_clust18 inf: ms_drbd1:promote ( p_lvm_drbd1:start ) ( > p_fs_clust18 p_vip_clust18 ) > > > > --Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20160229/d275d861/attachment.htm>