[Pacemaker] crm_master triggering assert section != NULL

[Yves Trudeau]

What about referring to the git repository here:

http://www.clusterlabs.org/wiki/Get_Pacemaker#Building_from_Source

I obviously missed the Repo move to... entry in the agents repository.

Regards,

Yves

On 11-10-12 07:30 PM, Lars Ellenberg wrote:
> On Thu, Oct 13, 2011 at 01:21:46AM +0200, Lars Ellenberg wrote:
>> On Wed, Oct 12, 2011 at 05:09:45PM -0400, Yves Trudeau wrote:
>>> Hi Florian,
>>>
>>> On 11-10-12 04:09 PM, Florian Haas wrote:
>>>> On 2011-10-12 21:46, Yves Trudeau wrote:
>>>>> Hi Florian,
>>>>>    sure, let me state the requirements.  If those requirements can be
>>>>> met, pacemaker will be much more used to manage MySQL replication.
>>>>> Right now, although at Percona I deal with many large MySQL deployments,
>>>>> none are using the current agent.   Another tool, MMM is currently used
>>>>> but it is currently orphan and suffers from many pretty fundamental
>>>>> flaws (while implement about the same logic as below).
>>>>>
>>>>> Consider a pool of N identical MySQL servers.  In that case we need:
>>>>> - N replication resources (it could be the MySQL RA)
>>>>> - N Reader_vip
>>>>> - 1 Writer_vip
>>>>>
>>>>> Reader vips are used by the application to run queries that do not
>>>>> modify data, usually accessed is round-robin fashion.  When the
>>>>> application needs to write something, it uses the writer_vip.  That's
>>>>> how read/write splitting is implement in many many places.
>>>>>
>>>>> So, for the agent, here are the requirements:
>>>>>
>>>>> - No need to manage MySQL itself
>>>>>
>>>>> The resource we are interested in is replication, MySQL itself is at
>>>>> another level.  If the RA is to manage MySQL, it must not interfere.
>>>>>
>>>>> - the writer_vip must be assigned only to the master, after it is promoted
>>>>>
>>>>> This, is easy with colocation
>>>> Agreed.
>>>>
>>>>> - After the promotion of a new master, all slaves should be allowed to
>>>>> complete the application of their relay logs prior to any change master
>>>>>
>>>>> The current RA does not do that but it should be fairly easy to implement.
>>>> That's a use case for a pre-promote and post-promote notification. Like
>>>> the mysql RA currently does.
>>>>
>>>>> - After its promotion and before allowing writes to it, a master should
>>>>> publish its current master file and position.   I am using resource
>>>>> parameters in the CIB for these (I am wondering if transient attributes
>>>>> could be used instead)
>>>> They could, and you should. Like the mysql RA currently does.
>>>>
>>> The RA I downloaded following instruction of the wiki stating it is
>>> the latest sources:
>>>
>>> wget -O resource-agents.tar.bz2
>>> http://hg.linux-ha.org/agents/archive/tip.tar.bz2
>> Has moved to github.
>> I'll try to make that more obvious at the website,
> Hm. That I had already done,
> not sure what else I could do there.
>
>> but that won't help for "direct download" hg archive links.
> Now, those I simply disabled,
> so people will notice ;-)
>
>> http://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/mysql
>>
>> raw download:
>> http://raw.github.com/ClusterLabs/resource-agents/master/heartbeat/mysql
>>
>> Also see this pull request:
>> https://github.com/ClusterLabs/resource-agents/pull/28
>