I have a production server with a single ArangoDB database containing large collections (millions of edges and tens of thousand nodes). Every week it gets regenerated on a different server and then the updated database get pushed to the production server using arangodump. The problem is that the copy takes about 1h, during which the production server is not really usable. Is there a solution to avoid any downtime ?
With MySQL to update table1, I can fill table1_tmp and then switch tables with an atomic operation:
RENAME TABLE table1totable1_old, table1_tmpTOtable1;
However I did not find an equivalent in ArangoDB
Related
I have two computers each one being a Cassandra node and they communicate well with each other.
From what I understand Cassandra will replicate the data to each other but will always query certain portions from one of them.
I would like though to have the data being copied to each other so they have the same data but they only use data from the local node. Is that possible?
The background reason is that the application in each node keeps generating and downloading a lot of data and at the same time both are doing some CPU super intensive tasks. What happens is that one node saves the data and suddenly can't find it anymore because it has been saved in the other node which is busy enough to reply with that data.
Technically, you just need to change replication factor to a number of nodes, and set your application to always read from a local node using whitelist load balancing mode. But it may not help you because if your nodes are very busy, replication of data from another node may also not happen, so the query will fail as well. Or replication will add an additional overhead making the situation much worse.
You need to rethink your approach - typically, you need to separate application nodes from database nodes, so application processes doesn't affect database processes.
We’re trying to create Master-Master replication between two TiDB clusters. Each cluster has 3 PD server, 4 KV servers and 2 TiDB server. TiDB is running with binlog enabled. On TiDB servers we have also installed pump.
Now we came to installing drainer and we’re seeing the following issues:
If we deploy multiple drainers on same TiDB servers configured to sync data to remote TiDB cluster - we’re getting duplicated entries in remote TiDB. Each drainer is sending inserts separately, so for each inserted record on source cluster we get 2 records on destination cluster
If we deploy single drainer on separate server allocated specifically for it, we’re creating single point of failure. If something happens to this server - data won’t be synced.
Additionally, we couldn’t find any infromation about design of pump cluster. As we know, pump is saving all transactions for gc days, and minimum what is possible to set is 1 day.
If we have 2 TiDB servers and each of them is running pump - does each pump saves same full data? Or is it sharded? Does it have replicas if it’s sharded? If we lose one of TiDB servers (with pump running on it) - do we lose part of pump data?
I am a TiDB user too.
From the official website, it recommends you use separate instances to deploy pumps and drainers.
Q1: Does each pump saves same full data? Or is it shaded?
If you deploy more than 1 pump, the transaction records will be randomly sent to pumps and drainer is for merging those binlogs based on the commit time.
Drainer collects and merges binlogs from each Pump, converts the binlog to SQL or data of a specific format, and replicates the data to a specific downstream platform.
https://docs.pingcap.com/tidb/stable/tidb-binlog-overview#:~:text=Drainer%20collects%20and%20merges%20binlogs%20from%20each%20Pump%2C%20converts%20the%20binlog%20to%20SQL%20or%20data%20of%20a%20specific%20format%2C%20and%20replicates%20the%20data%20to%20a%20specific%20downstream%20platform.
Q2.If we lose one of TiDB servers (with pump running on it) - do we lose part of pump data?
Ideally, if one pump fails, then new binlogs will be sent to other available pumps and binlog files are stored in a drainer machine rather than a pump.
Here is the drainer config file:
https://github.com/pingcap/tidb-binlog/blob/master/cmd/drainer/drainer.toml
I think it is very useful, you may follow it to do your own setup.
In my experience, you may store binlogs to two drainers to avoid losing data instead of having one drainer only. Also, the alternative way is to sync binlogs to kafka, which is also available in the drainer.toml file.
I understand that when a record is deleted in Cassandra the value is not actually deleted but marked as a tombstone so that consistency can be achieved among other nodes.
In my production setup, I am receiving data from 1000's of sensors and I am pushing this data to Azure service bus, internet is not very stable in production so I have a cassandra node to store the data that was not yet sent to Azure,
Once I send to Azure I delete the data in Cassandra records that I have successfully sent, I have set the GC_Grace_Seconds table to 0 and I never in the future plan to add another node to this cluster (always a single node Cassandra).
Will this cause me any issues in the future with this plan..? will the performance of this table reduce..? Will It affect any other tables that I may want to create in this node..?
For this specific use case when you had a plan to proceed with single node cassandra cluster it won't have any such impact. So whenever the data got deleted from table with gc_grace_seconds=0, it will be considered as deleted and not marked as tombstone. Other thing, because it is just a single node cassandra cluster so no need to worry about any peers node to share the deletion updates.
But the other raising question is choice of cassandra database as a single node cluster for this use case, preferred is Postgres can easily satisfied your need.
I have been looking a way to restore single database in couchdb vesion 2.0.0 or best practice on restoring a single database.
The enviroment, 5x couchdb2.0.0 instances, cluster mode with sharding.
What I used to do in the past with a single couchdb without sharding is to replace the db.couch files and a database file.
However, with the replication and sharding, I found that the database behaves differently. After I copy the db.couch files and shards/ from backup, I was able to get the restored documents. However after I restart couchdb, it went back to the original as if the restored database never there.
We are considering additional backup strategies for our Cassandra database.
Currently we use:
nodetool snapshot - allows us to take a snapshot of all data on a given node at any time
replication level in itself is a backup - if any node ever goes down we still have additional copies of the data
Is there any other efficient strategy? The biggest issue is that we need a copy of life data in additional datacenter, which has just one server. So, for example let's say we 3 Cassandra servers, that we want to replicate to one backup Cassandra server in a second datacenter. the only way I can think we can do it is to set the replication level to 4. That means all the data will have to be written to all servers at all times.
We are also considering running Cassandra on top of some network distributed system like HDFS. Correct me if I'm wrong but that would be a very inefficient use of Cassandra?
Are there any other efficient backup strategies for Cassandra that can backup the current data without impairing it's performance?