Hi Ryan,

Myosotis is a proxy that translates between the native wire protocol of 
MySQL/PostgreSQL to JDBC.  We use it to allow non-JDBC native clients like PHP 
to connect to the cluster without complex library substitutions.

Sequoia offers transparent failover in the sense that failures ranging from 
TCP/IP connection loss all the way to backends failing are handled 
transparently.  Your applications generally do not see connection failures 
unless all Sequoia controllers go down or lose all their backends.

Myosotis on the other hand does not provide any failover if the myosotis 
process itself fails.  In this case your applications would at the very least 
see a broken TCP/IP connection and would need to connect to another Myosotis 
connector process (or the same one after it comes back).  In this sense, 
Myosotis is not transparent.

If failures are a concern you can put Myosotis behind a hardware load balancer 
or LVS (http://www.linuxvirtualserver.org), which allows your applications to 
load balance quickly onto another myosotis process.  This is sufficient for 
many if not all cases.

Cheers, Robert


On 4/21/08 5:40 PM, "Ryan Manikowski" <[EMAIL PROTECTED]> wrote:

Emmanuel,

Thank you for your response. In the coming month we'll be going ahead
and testing Sequoia in a lab environment to verify compatibility with
our various tomcat and jboss instances. We're really not looking for a
big performance boost so much as high availability in the event of a
server failure. Management is not a big deal since we are a fairly small
shop and the reason we're even considering Sequoia is due to cost
constraints. We will gladly write our own management scripts to save a
few dollars.

You mentioned the Myosotis project which provides functionality for PHP
and stated that transparent failover is not possible. How is this so?
Can you explain in further detail? I would expect that since the client
apps are making calls to the Sequoia virtual database there wouldn't be
any issues if a backend server were to go down.

All of our database servers reside in a single physical location so
network partitioning is not a concern of ours at this time.

One of the notable unsupported items is distributed joins. Are there any
other limitations that you can explain easily via email?

Thanks again and I'm sure I'll have additional questions to post to the
list once we get started with our testing. Is the community fairly
active? Why do you state that not many users have been willing to share
their experiences with Sequoia? One of the hesitations my developers
have with deploying this solution is the lack of verifiable real-world
feedback from users.

Thanks,

Ryan Manikowski



Emmanuel Cecchet wrote:
> Hi Ryan,
>> Hello. My company is currently looking to evaluate Sequoia as a mysql
>> clustering solution and I am wondering if anyone can share their
>> experiences with the software.
> Very few people are willing to share their experience in using open
> source Sequoia even though there are quite a bit of production users
> out there. However I can tell you what I have seen so far (my opinion
> is probably biased since I was the designer of Sequoia ;-)).
>> We may potentially be rolling out the service in our production
>> environment and would like to know of any glaring limitations of the
>> software if there are any. Also, can anyone point me to configuration
>> documents for getting the software up and running?
> You can find the documentation at http://sequoia.continuent.org/Manuals
> There is no fundamental difference between 2.x and 3.x but 3.x is now
> deprecated and not supported (4.0 is in the works). Config file format
> is slightly different.
>
> Besides what the bug tracker can tell you, I would say Sequoia is a
> solution that is more geared towards high availability than
> performance. Depending on the parallelism you have in your workload
> you may see no or little improvement in performance. Note that it is
> still the same database that will in the end execute the query, so
> individual queries won't execute faster, we just spread the load on
> multiple nodes. Writes are replicated on all nodes, so you will never
> see improvement on write speed performance.
> Sequoia has all the required management mechanics but it does not
> provide automated management, you will have to write your own scripts
> for that. Continuent provides a commercial product based on Sequoia
> that will handle that nicely. If you prefer staying the open source
> route, you can seek for help on the mailing list or get help from
> consultants (I do consulting ;-)).
>> How well does the software work with PHP? Most of our backend systems
>> are tomcat 5.5/6.x but we still maintain legacy PHP software where
>> needed.
> The software was originally designed to work with Java but the
> Myosotis project adds direct MySQL protocol support so that you can
> run with legacy PHP applications. Just be aware that you won't have
> transparent failover with Myosotis. Another option is to use
> ODBSequoia, an ODBC implementation if you PHP application uses a db
> library that can take an ODBC driver.
>
> Sequoia is highly configurable which sometimes confuses users and can
> lead to poor design or integration. We are trying to simplify
> configuration for Sequoia 4 but there will still be application
> specific optimizations or architectures that cannot be automatically
> guessed. One thing to keep in mind is that Sequoia provides
> synchronous statement-based replication and the strong consistency
> provided does not support network partitions. Therefore, you have to
> think twice if you want to use it in a WAN environment.
>
> If some of the things I mentioned are not clear to you or don't ring a
> bell, you can read this article that should give you an overview of
> the problems you are going to face depending on what solution you go
> for (Sequoia or not): http://infoscience.epfl.ch/record/118488
>
> Thanks for your interest in Sequoia,
> Emmanuel
>
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia



--
Robert Hodges, CTO, Continuent, Inc.
Email:  [EMAIL PROTECTED]
Mobile:  +1-510-501-3728  Skype:  hodgesrm
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia

Reply via email to