You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Christian Hilgers <Ch...@consol.de> on 2012/02/01 17:57:04 UTC
Re: ActiveMQ Master/slave with MySQLCluster backend
Am 31.01.2012 14:13, schrieb Gary Tully:
> This need some work.
> On 5.6, a single broker can deal with a failover of the jdbc store.
> The difficulty is locking in the master/slave case, or peer cluster case.
>
> The current lock impl (who's job it is to get an exclusive lock on the
> store) treats failure of a lock as a fatal event and stops the broker.
>
> What would be great if you could describe how you think it should
> work, or how you would like it to work.
>
> I think this is something we can/should support.
I agree, this should be supported as this is the only way to build continental
clusters.
The current implementation does single
Locking Query is SELECT * FROM ACTIVEMQ_LOCK FOR UPDATE
to determine who is Master.
As this lock is restricted to one specific node, I now understand why AMQ
does the restart.
My suggestion to get out here is:
selected Master does perodically (eg. each second)
SELECT * FROM ACTIVEMQ_LOCK FOR UPDATE
UPDATE UPDATE ACTIVEMQ_LOCK SET TIME=$NOW,BROKER_NAME=$NAME WHERE ID = 1
COMMIT
analog to the idea from
http://mail-archives.apache.org/mod_mbox/activemq-users/201012.mbox/%3CC1CF8737-DD57-49F2-BA6C-3A859EEB6ED3@osterman.com%3E
Slaves do read the timestamp and check it it changes/increases. As long as
it increased, do nothing.
If it does not change for a configured number of reads, try a
SELECT * FROM ACTIVEMQ_LOCK FOR UPDATE
UPDATE UPDATE ACTIVEMQ_LOCK SET TIME=$NOW,BROKER_NAME=$NAME WHERE ID = 1
COMMIT
if it work become new master.
This should allow AMQ to failover the DB connection as the LOCK is only done
during the short update and not the whole time.
The only other Option coming to my mind, would be using an Arbitrator host
as MySQL cluster or Sun Cluster (Quorum Server does). But that might
be more work to implement and does need a third hosts, OK we do need that
third host for MySQL Cluster as Management and Arbiration Host anyhow.
Looking forward to the discussion
Christian
--
Christian Hilgers |ConSol*
Tel. +49.2102.994-483 |Consulting&Solutions Software GmbH
Fax +49.2102.994-411 |Berliner Str. 101, 40880 Ratingen
email: Christian.Hilgers@consol.de |WWW: http://www.consol.de
Re: ActiveMQ Master/slave with MySQLCluster backend
Posted by Gary Tully <ga...@gmail.com>.
That seems very reasonable.
The locker implementation can specified via configuration, it would be
great if you could provide an implementation that you can verify with
your setup.
note the interface:
http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/store/jdbc/DatabaseLocker.java?view=markup
implemented by http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/store/jdbc/DefaultDatabaseLocker.java?view=markup
the implementation (bean) can be set via the databaseLocker accessor
on the jdbcPersistenceAdapter.
MySQLClusterLocker would be a smashing contribution. Just attach it a jira.
On 13 February 2012 15:22, Christian Hilgers
<Ch...@consol.de> wrote:
> Am 01.02.2012 17:57, schrieb Christian Hilgers:
>
> Any Updates/comments here?
>
>
>> Am 31.01.2012 14:13, schrieb Gary Tully:
>>>
>>> This need some work.
>>> On 5.6, a single broker can deal with a failover of the jdbc store.
>>> The difficulty is locking in the master/slave case, or peer cluster case.
>>>
>>> The current lock impl (who's job it is to get an exclusive lock on the
>>> store) treats failure of a lock as a fatal event and stops the broker.
>>>
>>> What would be great if you could describe how you think it should
>>> work, or how you would like it to work.
>>>
>>> I think this is something we can/should support.
>>
>>
>> I agree, this should be supported as this is the only way to build
>> continental
>> clusters.
>>
>>
>> The current implementation does single
>> Locking Query is SELECT * FROM ACTIVEMQ_LOCK FOR UPDATE
>> to determine who is Master.
>>
>> As this lock is restricted to one specific node, I now understand why AMQ
>> does the restart.
>>
>>
>> My suggestion to get out here is:
>> selected Master does perodically (eg. each second)
>> SELECT * FROM ACTIVEMQ_LOCK FOR UPDATE
>> UPDATE UPDATE ACTIVEMQ_LOCK SET TIME=$NOW,BROKER_NAME=$NAME WHERE ID = 1
>> COMMIT
>>
>> analog to the idea from
>>
>> http://mail-archives.apache.org/mod_mbox/activemq-users/201012.mbox/%3CC1CF8737-DD57-49F2-BA6C-3A859EEB6ED3@osterman.com%3E
>>
>> Slaves do read the timestamp and check it it changes/increases. As long as
>> it increased, do nothing.
>> If it does not change for a configured number of reads, try a
>> SELECT * FROM ACTIVEMQ_LOCK FOR UPDATE
>> UPDATE UPDATE ACTIVEMQ_LOCK SET TIME=$NOW,BROKER_NAME=$NAME WHERE ID = 1
>> COMMIT
>> if it work become new master.
>>
>> This should allow AMQ to failover the DB connection as the LOCK is only
>> done
>> during the short update and not the whole time.
>>
>> The only other Option coming to my mind, would be using an Arbitrator host
>> as MySQL cluster or Sun Cluster (Quorum Server does). But that might
>> be more work to implement and does need a third hosts, OK we do need that
>> third host for MySQL Cluster as Management and Arbiration Host anyhow.
>>
>> Looking forward to the discussion
>>
>>
>> Christian
>> --
>> Christian Hilgers |ConSol*
>> Tel. +49.2102.994-483 |Consulting&Solutions Software GmbH
>> Fax +49.2102.994-411 |Berliner Str. 101, 40880 Ratingen
>> email: Christian.Hilgers@consol.de |WWW: http://www.consol.de
>
>
> --
> Christian Hilgers |ConSol*
> Tel. +49.2102.994-483 |Consulting&Solutions Software GmbH
> Fax +49.2102.994-411 |Berliner Str. 101, 40880 Ratingen
> email: Christian.Hilgers@consol.de |WWW: http://www.consol.de
--
http://fusesource.com
http://blog.garytully.com
Re: ActiveMQ Master/slave with MySQLCluster backend
Posted by Christian Hilgers <Ch...@consol.de>.
Am 01.02.2012 17:57, schrieb Christian Hilgers:
Any Updates/comments here?
> Am 31.01.2012 14:13, schrieb Gary Tully:
>> This need some work.
>> On 5.6, a single broker can deal with a failover of the jdbc store.
>> The difficulty is locking in the master/slave case, or peer cluster case.
>>
>> The current lock impl (who's job it is to get an exclusive lock on the
>> store) treats failure of a lock as a fatal event and stops the broker.
>>
>> What would be great if you could describe how you think it should
>> work, or how you would like it to work.
>>
>> I think this is something we can/should support.
>
> I agree, this should be supported as this is the only way to build continental
> clusters.
>
>
> The current implementation does single
> Locking Query is SELECT * FROM ACTIVEMQ_LOCK FOR UPDATE
> to determine who is Master.
>
> As this lock is restricted to one specific node, I now understand why AMQ
> does the restart.
>
>
> My suggestion to get out here is:
> selected Master does perodically (eg. each second)
> SELECT * FROM ACTIVEMQ_LOCK FOR UPDATE
> UPDATE UPDATE ACTIVEMQ_LOCK SET TIME=$NOW,BROKER_NAME=$NAME WHERE ID = 1
> COMMIT
>
> analog to the idea from
> http://mail-archives.apache.org/mod_mbox/activemq-users/201012.mbox/%3CC1CF8737-DD57-49F2-BA6C-3A859EEB6ED3@osterman.com%3E
>
> Slaves do read the timestamp and check it it changes/increases. As long as
> it increased, do nothing.
> If it does not change for a configured number of reads, try a
> SELECT * FROM ACTIVEMQ_LOCK FOR UPDATE
> UPDATE UPDATE ACTIVEMQ_LOCK SET TIME=$NOW,BROKER_NAME=$NAME WHERE ID = 1
> COMMIT
> if it work become new master.
>
> This should allow AMQ to failover the DB connection as the LOCK is only done
> during the short update and not the whole time.
>
> The only other Option coming to my mind, would be using an Arbitrator host
> as MySQL cluster or Sun Cluster (Quorum Server does). But that might
> be more work to implement and does need a third hosts, OK we do need that
> third host for MySQL Cluster as Management and Arbiration Host anyhow.
>
> Looking forward to the discussion
>
>
> Christian
> --
> Christian Hilgers |ConSol*
> Tel. +49.2102.994-483 |Consulting&Solutions Software GmbH
> Fax +49.2102.994-411 |Berliner Str. 101, 40880 Ratingen
> email: Christian.Hilgers@consol.de |WWW: http://www.consol.de
--
Christian Hilgers |ConSol*
Tel. +49.2102.994-483 |Consulting&Solutions Software GmbH
Fax +49.2102.994-411 |Berliner Str. 101, 40880 Ratingen
email: Christian.Hilgers@consol.de |WWW: http://www.consol.de