I'm trying to figure out if the community edition of Couchbase supports bidirectional replication btwn data centers?
I'm reading this: https://www.couchbase.com/products/editions
but I can't see any clear comments about it.
What I'm trying to test / achieve is what's described in the following documentation under the "bidirectional" section.
https://docs.couchbase.com/server/6.0/learn/clusters-and-availability/xdcr-overview.html
Thanks.
Bidirectional replication just means you have XDCR going from cluster A to B, and another XDCR going from cluster B to A. Since Community Edition includes XDCR, it includes bidirectional replication.
Related
Can I get some advice on whether it is possible to proceed like the steps below?
SQL Server data is loaded in Ignite Cluster
The data in SQL Server has been changed.
-> Is there any other way to reflect this changed data without reloading the data from SQL Server?
When used as a cache in front of the database, when changes are made directly to the DB without going through the Ignite Cluster, can the already loaded cache data be directly reflected in the Ignite cache?
Is it possible to set only the value to change without loading the data again?
If possible, which part should I set? Please.
I suppose the real question is - how to propagate changes applied to SQL Server first to the Apache Ignite cluster. And the short answer is - you need to do it by yourself, i.e. you need to implement some synchronization logic between the two databases. This should not be a complex task if most of the data updates come through Ignite and SQL Server-first updates are rare.
As for the general approach, you can check for the Change Data Capture (CDC) pattern implementations. There are multiple articles on how you can achieve it using external tools, for sample, CDC Between MySQL and GridGain With Debezium or this video.
It's worth mentioning that Apache Ignite is currently working on its own native implementation of CDC.
Take a look at Ignite's external storage integration, and the read/write through features. See: https://ignite.apache.org/docs/latest/persistence/external-storage
and https://ignite.apache.org/docs/latest/persistence/custom-cache-store
examples here: https://github.com/apache/ignite/tree/master/examples/src/main/java/org/apache/ignite/examples/datagrid/store
As said in another answer here:
The number of Redis databases is fixed, and set in the configuration
file. By default, you have 16 databases. Each database is identified
by a number (not a name).
But I am curious if there is a way I could and should title and describe my databases? Especially in the scenario when one server could be used by few users (developers for example).
No, currently there isn't such a way. Please also note that numbered (shared) databases are not future-compatible (unsupported by Redis v3 with clustering support) and are not recommended for use - see here for more details: https://redislabs.com/blog/benchmark-shared-vs-dedicated-redis-instances
I am on Rails 3 with a local Postgres database. What we want to do is replicate the entire database onto a second server in real time. We are thinking of using Octopus.
I'm confused about what model I'm looking for and how the master-slave model applies.
Postgres 9.1 and later comes with streaming replication built in (for master-slave configurations). Check out http://www.postgresql.org/docs/9.2/static/warm-standby.html#STREAMING-REPLICATION for more information on configuration and setup.
There are other third-party solutions for configuration, but I'd start there and see if that meets your needs.
How to implement Publishing subscriber Replication topology in SQL?
First, work out what kind of replication you want, and so on.
Also, read through something like the Help system (SQL Books Online) to understand the various Agents that will play a part. Such as the Log Reader agent, the Distribution Agent, and so on. Think about what users you want to use for these.
Then just go into SQL Management Studio, connect to your source, go to the Replication bit and use the New Publisher wizard. Once that's done, go to your Subscriber and set up Subscribers in a similar way.
What do you mean by "Publishing subscriber Replication topology"?
In one sense (the "traditional" sense), SQL Server doesn't support a pub / sub model for replication, where a single publisher multicasts data out to many subscribers.
In another sense, all forms of replication are pub / sub, in that there is a central Publisher that provides data to one or more Subscribers, by way of a Distributor and Agents (but it's actually serial unicast).
I need to set up this scenario:
A SQL Server 2005 database will create a transactional replication subscription from another database to populate a set of lookup tables. These lookup tables will then be published as a merge replication publication to the client's SQL Server Mobile.
I remember seeing a similar scenario defined in the SQL Server Books Online somewhere, but I was unable to find the link anymore. I hope someone can help me find it, or otherwise point me to any other similar links.
Okay, I managed to get the answers I needed at the MSDN SQL Server Replication forum.
The article I was looking for is called: Republishing Data.
Apparently, it is located within "Advanced Replication Features and Internals" of the "Configuring and Maintaining Replications" section. It's a little non-obvious, so I spent most of my time looking in the "Replicating Data Between a Server and Clients" section, instead of there. Good to know, as there seems to be a number of other special scenarios worth looking at in there.
I do not get the interest of having a transactional replication to generate lookup tables. Such tables are not made to be updated from the client side, so why do you want to combine transactional + merge replication when you don't have the data modified by the subscribers?
Maybe the original scenario is not clear, so let me clarify.
The database where the original lookup tables are located either remotely with bad network connection, or operated under heavy load. This approach was suggested so that the lookup tables are replicated to another database which all merge replication with the clients will be performed.
Of course, it may not be the most appropriate approach to our problem, so if anyone has a better idea, we'll like to hear them.
Still, the main reason for this question is to find an article I previously found (but stupidly did not bookmarked) which described our scenario quite well. Any possible leads to this article (title, author, similar topics, etc) are definitely appreciated.