Continuent Community

We are doing some pre-production testing. We have 2 DB nodes (master and slave)

We set up tungsten to use ping monitoring vs. multicast for our test. However when we issue say a "reboot" to the slave the connector will hang until the slave node comes back up. Normally in other test where we down mysql only and leave the manager and replicator running we can just issue a:
datasource db2 offline
and the connector will then progress on accepting jdbc connections.

But when we actually power off/reboot the box simulating a total failure of the slave...how do we get the connector to resume w/o bringing the slave back on-line?

As soon as the slave comes backup and pings the connector will respond automatically. So need to figure it out as losing a slave totally is a possiblity.

Thanks

Cody

Well re-running the configure script and choosing multicast seems to let us do a datasource db2 shun and have the connector recover. This was NOT the case when we used the PING discover method and would not allow us to do anything until the downed host came back online during our tests

Hi Cody!

Where is the connector located in this topology? Is it on one of the db boxes or a third host?

The ping vs. multi-cast difference in behavior indicates that there are problems with manager communications as opposed to the connector itself. I will try this out if you can let me know what the full topology looks like.

Cheers, Robert

Thank you for your reply Robert. We have the connector currently running on the master DB1. Switching to multicast seemed to allow us to take the datasource out of the rotation and have jdbc connections resume. But we couldnt accomplish that with ping?

Thank You

Cody