Investigating SingleStore currently. I can’t find any info on how SingleStore managed services support a multi zone, region setup. We want to be able to have a cluster in multi regions on gcp for high availability if a region is down - or even multi zone for same purpose.
Is this something that is supporter?
I guess that when you do the installation yourself you can get the different vms in different regions to talk.
But what endpoint should be used then. Should we a load balancer in front of the different nodes?
We can deploy your clusters on SingleStore Managed Service (S2MS) in 2 availability zones upon request, and in the near future, you’ll be able to do it automatically w/o contacting us. Stay tuned for that.
The default approach uses Unlimited Storage (which is on S3 in AWS) and is deployed in 1 AZ. But the data is on S3 which is in 2 AZs by default. So you could recover with a minute or so of data loss with that approach in the event of a total AZ loss.
Multi-region deployment for S2MS is on the roadmap.
If you want to get DR via our database product today under your full control, you can self-host SingleStore DB and use REPLICATE DATABASE for DR across regions or AZs.
Thanks for the feedback. The idea who have two purposes 1/ surviving a zone / region outage in datacenter, 2/ having data “close” to the users. When having services in US and EU for example, we could point US users to US endpoints; EU to EU endpoints. But still we would think of it as 1 cluster. Would this be possible? Or is latency a huge issue in that case?
I would not recommend that. It has been tried – you can put one availability group in one geography and another availability group in another – but it is outside the normal design parameters of our HA solution, where we expect the nodes in the cluster to have low latency between them.
I’d go with some sort of replication strategy, and have a cluster in the US and one in EU.
If you need one read-only and one read-write, you can use REPLICATE DATABASE if you self-host S2DB.
If you need both locations read-write, then you will need to build replication at the application tier – update the primary location, then queue updates for the secondary location. Or, partition the data logically so you have different data for EU and US. This approach could be done on S2MS or S2DB.
If we partition in the logical layer, EU and US data; would it be an option to still async replicate certain data? Let’s say you have a Sales table for EU sales and US sales. But in the end, global HQ want to report on EU + US sales together. What would be the best strategy here?
The best approach currently would be to do the logical partitioning and async replication in the application tier.
We’re looking at ways to support this in a more automated ways at the DB layer.
Shoot me an email at my_last_name@singlestore.com and we can talk about your requirements.
-Eric Hanson