Hi Team,
I have a question on replication of data across data centers of SingleStore clusters @the table level or in Change Data Capture mode in a bidirectional way. Could you please suggest me how that can be achieved using either SingleStore’s Replicate tool or any other feature of Singlestore.
It’s purely transaction level replication ( row store is in use)
Data can be changed in any of the existing data centers and the requirement is that the other DCs should get the changed data replicated on real time basis.
I really appreciate for providing options to achieve this, if we get perfect solution to this requirements, it’s going to be good use case.
We don’t have bi-directional replication built in. Some of our customers have done it by having 2 independent clusters in two different data centers and replicate data between them with application logic – basically update both database separately. Sometimes they use a distributed kafka queue setup to enqueue updates for both systems and then have apps read from the Kafka queues and write the databases.
If you don’t TRULY need bi-directional updates with ability to update either copy, you can use REPLICATE DATABASE for one-way replication. Then you have a master copy and a secondary copy. The master is updateable. The secondary is queryable. You can failover/failback if needed.
Why do you want this? Do you need to be able to update both DBs?
We are working toward this and have heard it from many people. CDC out of SingleStore is part of it that I expect us to address first.
Why do you want this? Do you need to be able to update both DBs?
Till date we are using SingleStore for reads by replicating data from NON-SINGLESTORE database which is our SOR. To avoid maintenance of multiple Database we are planning to make SingleStore as a primary DB by removing our SOR DB.
Data resides in multiple DCs and we want to balance the workload by sending application requests to all the clusters of the DCs. DML ops can happen in any of the DCs, and we want the same to be replicated across other clusters of the DCs.
We did notice that SingleStore supports lowest Isolation level (Read Committed), is there any way that in the future release that it can be increased to higher/highest levels ( Serializable)? Our customers are little skeptical here by comparing with Cockroach DB(which supports highest level of Isolation).
Regarding isolation levels, you can already get serializable isolation by using SELECT FOR UPDATE. E.g. to do a multi-statement update transaction you can do
BEGIN;
select … for update …; /* will hold locks on all rows fetched, until commit /
…
update … ; / can depend on rows fetched by SELECT */
COMMIT;
Hi Hanson,
we can’t afford to make code changes @the API level to cover isolation. If it is allowed as part of global variables, based on the application requirements, we can adjust it. It could be great if my other questions are answered before we go to our customer.