MARSYS announces the release of Colada 4.1, a software replication framework that provides a non-invasive, platform independent solution for clients. Colada maintains real-time replication and synchronization of data across multiple LAN and WAN frameworks. In addition, it is a disaster recovery enabler with the ability to leverage disaster recovery hardware, automatic database failover, the ability to configure delayed replication and instant backup of data across multiple servers.
The product is made up of various different components, including the Alarm Server, the Configuration Server or Configuration Console, the Database Synch Tool, Client Object, Sequencer and Replicator.
Configuration Console - The Configuration Console simplifies the job of a DBA. One of the biggest problems of implementing replication today is that it is not a very simple proposition whether it is in SQL Server or any other database. Colada's Configuration Console provides a wizard-like feature that allows you to string databases together into a replication framework and manage those databases from a central console. The Configuration Server stores change in the configuration, broadcasting them to the components.
Replicator - One of the main components within Colada is the Replicator itself. The Replicator accepts transactions, which are subsequently sent in a sequential manner to each of the databases to be executed. MARSYS guarantees that everything is executed in the same order that it was received via this Replicator.
Client Object - One of the initial objectives behind Colada was that it be easy to implement and easy to access. MARSYS knew the best way to access things was via drivers, so the client object was created. The Client Object is a flexible application standard driver (OLEDB, ODBC, JDBC, etc.) used to access the data Replicator.
Database Synch Tool - The Database Synch Tool examines the transaction logs generated by the Replicator and Sequencer, and allows you to replace transactions on any database, should that be necessary.
Sequencer - The Sequencer is used to maintain Replicators in a WAN situation. In a situation where you are outside of a standard LAN, the Replicators talk to the Sequencer, which maintains the sequence of all of the Replicators so that they execute and continue to guarantee results. For example, an individual taking an online class might start the class in the morning, and complete it in the afternoon after stepping off a plane in a different location. It is essential that the data from the data center move with him as he accesses a different data center later in the day. Colada assists in that process, ensuring that data is replicated to both data centers and is available to the client as he moves around the United States.
Standby Server - If corruption occurs, the Alarm Server sends SNMP traps, email or even to pagers if necessary. When you are working with live replication, you are susceptible to corruption. All transactions are going through very quickly; if one that can corrupt the database goes through to all of your databases, it can cause an enormous problem. To offset this problem, MARSYS created the notion of a standby server, which allows you to configure delayed replication to individual servers.
There are different types of replication available, with both pros and cons to
their structures. A negative aspect of transactional replication is if your
master dies, your replication pretty much goes down the tubes at the same
time. Snapshot replication is more of a point-in-time capture used for
reporting systems. Merge replication is one of the most difficult to maintain.
Colada, on the other hand, offers application level
replication, or replication at the transactional/data level, replacing the reliance on database specific replication. The DBA can manage everything from a single console, which means he only needs to understand a single technology rather than numerous ones.
Colada sports a simple to use application interface; the configuration console is all point and click, which makes setting up a replication scenario effortless. Many of the replication scenarios on the market are complicated, especially publisher/subscriber situations that require figuring out how the publishers and subscribers are talking to each other. In these situations, you would normally have to set it up on two sets of machines, making sure the subscriber is listening and the publisher is sending. In addition, the replication console provides the ability to add and delete databases as well as the ability to start and stop databases.