Anyone who has been on a night time support rotation can relate to the 3 AM phone call that gets you groggily out of bed, has you fixing some simple, but important problem, and then leaves you staring at the ceiling by 4 AM wondering if you should just go into work, because you know you aren't getting back to sleep. All of the engineers in our office have been there, done that, and didn't like it very much. That's one of the reasons we focus so much on resilient operations for SymmetricDS including our "Hands Off" Recovery of data synchronization. "Hands Off" recovery is pretty much exactly what it sounds like. SymmetricDS has been built from the ground up to recover and keep databases in sync without manual intervention any time it possibly can.

Add a new node (database for replication) to the SymmetricDS sync scenario. This could be a source or target or both. It will register with the master node and receive all the configuration and will immediately be ready for replication.

Cancer Research UK utilizes SymmetricDS for flagship Race for Life event website.

In addition to replicating data changes from source to target you may also wish to populate a table on the target to monitor all events.  In this blog I will show you how to create a simple load filter that will record all changes captured by SymmetricDS into a simple audit table.  

When integrating data from one database to another, sometimes the schemas are not the same. JumpMind has come across a number of projects where there was a need to transform a very denormalized database into more of a canonical or normal form.

An international retailer utilizes SymmetricDS to synchronize all store data across the United States, Europe, and Asia.

A wizard to walk users through the process of loading data between databases. The load will use the configuration in place for the nodes selected. This might be necessary if the source and target databases are not in sync before change capture being setup.

A healthcare organization consolidates data and improves operations using SymmetricDS multi master replication.

Data has become an ever increasing crutch in our daily lives and drives more and more business decisions than ever. With the steady increase in data storage technologies consumers are faced with greater challenges to keep the data synchronized for accurate reporting, analysis, and overall processing. Traditional databases such as SQL Server, Oracle, Postgres, and MySQL still play a major role in many companies. However with the rise of the cloud platforms and NoSQL technologies commonly used for warehousing and analytics the need to support a variety of technologies within each business is important.

All SymmetricDS synchronization configurations require database connectivity. As a result questions often arise around the topic of database permissions. Specifically what permissions are required for the SymmetricDS user and do the SymmetricDS tables need to run in the same catalog or schema as the tables to be synchronized.

Build some simple configuration to specify which tables will be replicated and the direction they will sync.

Setting up a "master" node for database replication is just like setting up any other node with the exception that the master node is responsible for registering new nodes onto the SymmetricDS data synchronization scenario.

SMARTMD Leverages SymmetricDS to Provide Medical Clinic Data Synchronization.

SymmetricDS promises to sync your data, but how do you know it really worked? How do you really know 2 databases are in sync? Or, maybe you have well-meaning users that come along after the sync, changing data unexpectedly, and throwing production out of whack.

Whatever the case, wouldn’t it be nice to be able to compare any 2 databases, and know exactly what the differences are and be able to prove they are in sync? That’s where a new, experimental feature of SymmetricDS comes in. It’s called simply dbcompare. Dbcompare is slated for SymmetricDS 3.8, but if you watch closely, it’s fully included starting in SymmetricDS 3.7.30.