Continuent has announced the release of uni/Cluster in PostgreSQL and MySQL editions. uni/Cluster, based on Sequoia, offers a multi-master approach to replication, committing data to all nodes simultaneously. Support is included for PostgreSQL 7.4 through 8.1, and MySQL 4.1 and 5.0. In both cases, uni/cluster supports sub-second, transparent failover including re-start of transactions. There is also no need to have all database versions synchronized, so the database servers in the cluster don't have to run the same versions in all instances, which has a significant potential impact in maintenance. Machines can be added or removed to the cluster in real-time.

Aside from support, are there any differences from just using Sequoia? Also, I didn't see any pricing on the website.

Aside from support, are there any differences from just using Sequoia?

Yes, uni/cluster products include the following features (not available in Sequoia): - proprietary high-performance group communication (especially optimized for Sequoia workloads) - specific MySQL and PostgreSQL parsers to fully support the database dialect (includes sequences, stored procedures, ...) - database specific JDBC extensions support (custom database types and exceptions) - database specific performance enhancements and configuration tuning - graphical management console - certification on several platforms - complete documentation set with database specific features support Basically, uni/cluster will provide the full database transparency that Sequoia does not provide (because it remains generic and does not include any database specific extension). But the core HA functionalities remain the same in the products and in Sequoia.

Emmanuel, It helps, thanks a lot. (but why haven't you come out aggressively to add more posts in forums, I see a clear need to align my HA approach like what your product offers, but worried about the lack of vibrancy in the community that could serve as good catalyst to your product's market acceptance(correct me if I am wrong). Ok coming back to your specs, I have few questions to ask, specific MySQL and PostgreSQL parsers to fully support the database dialect (includes sequences, stored procedures, ...) For plain statements oriented towards CRUD, does the parsers add punch, In other words are they only meant for Stored Procedures ..etc? database specific performance enhancements and configuration tuning Are they something specific to, how your middleware performs or do they pertain to the database proprietary high-performance group communication (especially optimized for Sequoia workloads) Would you be able to throw more light on this ?

Aside from support, are there any differences from just using Sequoia? Also, I didn't see any pricing on the website.

Pricing information can be obtained by sending an email to sales@continuent.com

Could you say a little bit about how the latency in uni/Cluster depends on the number of nodes?

Could you say a little bit about how the latency in uni/Cluster depends on the number of nodes?

Let's distinguish controller nodes from database backend nodes. You must have at least 2 controller nodes to get HA and this is the fastest configuration for the group communication that needs to multicast writes between controllers (no influence at all on reads). A commonly client observed overhead on the query execution time of write requests is 8ms. When you add more controller nodes, the group communication overhead increases linearly with each node. But as you can have reasonably up to 8 nodes per controller, that is already 16 database nodes with 2 controllers. Adding database nodes does not change the query latency because the result can be returned as soon as the first node in the cluster as successfully completed the request. As the read workload is distributed and usually lock contention is reduced, you can experience a latency improvement when adding database backends. Usually, you will observe that your latency remains constant when the load increases (scalability). I hope this answers your question. Emmanuel

Let's distinguish controller nodes from database backend nodes. You must have at least 2 controller nodes to get HA and this is the fastest configuration for the group communication that needs to multicast writes between controllers (no influence at all on reads). A commonly client observed overhead on the query execution time of write requests is 8ms. When you add more controller nodes, the group communication overhead increases linearly with each node.

I meant controller nodes, not database nodes. It does answer my question. You say that there the latency for reads does not depend on the size of controller cluster. Does that mean that when you detect a conflict you roll back?

Adding to Lichtner's question, Is it a two phase commit ?, If so what happens to the data afterwards. In addition when you mention read write separation, are you mentioning the driver abstracts the user from worrying about writing to an instance and reading from the other ?