Re: [Sequoiadb-discuss] Sequoia replication

[Heshel R. <hs...@gm...>]

Hi Emmanuel,

On Thu, May 7, 2009 at 6:21 PM, Emmanuel Cecchet <ma...@fr...>wrote:

> Hi Heshel,
>
>> I have a couple of questions concerning the replication of Sequoia. Some
>> background info, we have two locations that we are in the process of setting
>> up. In each location will be two controllers, currently sitting on the same
>> box as the application server. These controllers then have one or more
>> PostgreSQL database boxes for backends. We will also be setting up a pair of
>> switches for the internal communications in each location. Hopefully the
>> duplication will allow me to sleep soundly if we ever have a piece of
>> hardware fail.. ;) We are running FreeBSD for the under lying OS, and the
>> binary of Sequoia 2.10.10.
>>
>> First, I am attempting to use a dedicated link between the controllers in
>> the same physical location, however I cannot see to get the controllers to
>> use the IP of this interface for replication. I will be removing my current
>> configuration and starting fresh in hopes that it may just be an error in
>> them, but I thought I would also ask here if can it be done while I work
>> that out.
>>
> You can force which IP address you want the controller to bind in the
> controller configuration file.


Sorry, I guess I laid out the points in a bad order, as this "first"
question did not come up until after the second one.. I have set the
controller IPs via the configuration file, and I have set another IP from
the second interface for the replication. I did this based on the hope that
the clients would continue to connect to the public interface, while the
controllers would move the replication communication to the dedicated
crossover between them. I have not had a chance to redo the configuration to
attempt this again.

>
>  Second, I did have a working configuration for using a single nic for all
>> communication, however, there was some issues with it. The controllers would
>> disconnect shortly after forming the cluster, upon checking my logs they
>> were using ports outside of what I had configured the hedra/jgroups
>> configuration files for. I had configured the controllers to use 7900 as the
>> communication port, which they did use, but none of the other ports were
>> defined by myself to connect to. (This is a reason I am looking at the
>> separate interface for the controller communication, as opening pf right up
>> on the main interface(s), or turning it off is not an option. However,
>> having a crossconnect between the two servers that is unhindered is
>> acceptable.)
>>
> Are you sure that the controller is using your configuration file? It will
> use the first one it finds in the classpath.
>

I am sure that the configuration file is being loaded. I had stumbled upon
the naming issue with the default sequencer.xml, I changed my configuration
file to be called jgroups_tcp.xml, and made sure the
hedra_jgroups.properties files was updated to reflect that.

>
>  Third I am required to setup replication between 2 physical locations.
>> Since the plan is to use Sequoia for replication in each location, there
>> have been talks of using it for the wan replication as well. I am curious
>> about peoples experience with such a setup. As another possibility, I have
>> been looking into the use of the tungsten connector between the controllers
>> at each site.
>>
> For Tungsten, I guess you will have to ask on the Tungsten mailing list. I
> have not been following their development closely (shame on me) and I am not
> sure how this would work.
> You can try to setup a tunnel for the group communication between the 2
> sites but latency is probably going to be a penalty. Another option is to
> use the remote controller as an additional backend of the local controller.


Latency is the one reason I have been trying to convince the designer to
fold everything into one site, that has proper redundancy, but that is
neither here nor there. The remote controller as a backend is an interesting
idea, which would limit the traffic to a known port for each remote
controller. It would be best in that case to add all remote controllers as
backends for redundancy, however I see an issue with bandwidth there..

Would there be a way to have a cluster to cluster communication as a single
stream, that would be able to failover between controllers? So the primary
controller in each cluster would have a channel open for passing the data,
most likely async, that if one of the primaries failed, the secondary would
resume the role? They would use the primary's recovery log that is still up
to ensure consistancy? As I continue to think about this, having the sequoia
controllers share an IP via CARP or other type of ip clustering could allow
the single stream possibly..

>
>  Some additonal questions;
>>
>> FreeBSD rc scripts? I did some digging in the past to see if this was
>> possible, found some talk of it but nothing more.
>>
> There are some scripts for Linux but nothing for FreeBSD as far as I know.


Doh. Maybe I might have to look into the creation of one, as it would help
ease my management steps of the servers if I could ensure Sequoia is up
before Tomcat, and the databases are sync'd before a shutdown/reboot with
minimal effort.

>
>  Probably a very common question, new releases of Sequoia? I know working
>> is being done on 4.x, and possibly 2.10.11? Just curious if there is any
>> timelimes?
>>
> Sequoia 2.10.11 if it ever comes out will be provided by Continuent. Not
> sure if this will ever happen.
> Sequoia 4 relies on me. I have been very busy with my 2 other jobs recently
> and I have had no time to make progress. I have to make a new release
> (probably a beta), if possible this month, otherwise in June. The problem is
> that I have to redo the documentation and that will take time. Also I have
> no access to the test suite that was developed at Continuent so the
> debugging phase might be more painful.


Thanks for the info! An additonal question, has Sequoia 4 been relatively
stable? Stable enough that it is used in a production environment even
though it would be classed as alpha/beta?

>
>
> Keep us posted with your progress.
> Emmanuel
>
> --
> Emmanuel Cecchet
> FTO @ Frog Thinker Open Source Development & Consulting
> --
> Web: http://www.frogthinker.org
> email: ma...@fr...
> Skype: emmanuel_cecchet
>
>