ActiveMQ offline message transfer on database level

Question

we are running an in-house EAI system using ActiveMQ as the message broker using JDBC persistence.

There we have a cold-standby failover solution each one having an own database schema (due to several reasons).

Now if the primary goes down and we want to startup the backup we would like to transfer all undelivered messages on database level from the one node to the other.

Having a look at the table "ACTIVEMQ_MSGS" made us unsure if we can do this without any drawbacks or side effects:

• There is a column "ID" without any DB-sequence behind - can the backup broker handle this?
• The column "MSGID_PROD" contains the host name of the primary server - is there a problem if the message should be processed by a broker with a different name?
• There is a column "MSGID_SEQ" (which seems to be "1" all the time) - what does this mean? Can we keep it?

Thanks and kind regards,

Michael

Answer 1

I would raise a big red flag about this idea. Well, yes, in theory you could well succeed with this, but you are not supposed to touch the JDBC data piece by piece.

ActiveMQ has a few different patterns for master/slave HA setups. Either using a shared store for both the master and the slave, or use a replicated store (LevelDB+ZooKeeper).

Even a shared JDBC store could be replicated, but on the database level.

Ok, so you somehow want another setup than the official ones, fine. There is a way, but not using raw SQL commands.

By "Primary goes down", I assume you somehow assumes the primary database is still alive to copy data from. Fine. Then have a spare installation of ActiveMQ ready (on a laptop, on the secondary server or anywhere safe). You can configure that instance to connect to the "primary database" and ship all messages over to the secondary node using "network of brokers". From the "spare" broker, configure a network connection to the secondary broker and make sure you specify the "staticBrige" option to true. That will make the "spare" broker hand over all unread messages to the secondary broker. Once the spare broker is done, it can be shut down and the secondary should have all messages. This way, you can reuse the logic in whatever ActiveMQ version you have and need not to worry about ID sequences and so forth.