CODEWITHSUNDEEP
arangodb
Fiala
Fiala

Reputation: 13

Arangodb compare replicant and master

I'm having trouble comparing my master and my replicant data for programmatic sanity check. I would expect the following to respond with the same count on both my master and my replicant. For some collections, it does not.

curl -s -X POST --data-binary @- --dump - ${ARANGO_DB_ADDRESS}/_db/dbname/_api/export?collection=collection_name <<EOF
{"count":true}
EOF

Am I misunderstanding what this API call does? Is there easier way to do this? I attempted arangodump of both, but the differences are quite extreme

Upvotes: 1

Views: 58

Answers (1)

dothebart
dothebart

Reputation: 6067

The best way to inspect the replication state is to first issue db.collection.count() and then more precise db.collection.checksum(). These can also be issued with via these curl calls:

Count: 

curl http://127.0.0.1:8529/_db/_system/_api/collection/test/count   
{"id":"26724522","name":"test","isSystem":false,"doCompact":true,
 "isVolatile":false,"journalSize":33554432,
 "keyOptions":{
    "type":"traditional","allowUserKeys":true},
"waitForSync":false,"indexBuckets":8,"count":40000,"status":3,
"type":2,"error":false,"code":200}

Checksum:

curl http://127.0.0.1:8529/_db/_system/_api/collection/test/checksum
{"id":"26724522","name":"test","isSystem":false,
"status":3,"type":2,"checksum":1808041899,"revision":"7926623225",
"error":false,"code":200}

Regarding the export-API, these are dependend on the server state. Documents are contineously written to the WAL-files on creation.WAL files are used so you don't have distributed writes on your disks, which would harm performance. The documents will later on be moved into their collection files. To ensure that the export doesn't harm server performance, only the documents inside of the collection files are exported. Thus the number of documents may be different depending on the state of the collector facility.

The most reliable way to get a sync in an async state is to insert documents on a slave. If that happenes, you can go back to a sane state by issuing: 

r.applier.stop()
r.syncCollection("myCollection", {endpoint: "tcp://127.0.0.1:8529"})
r.applier.start()

However, changes to the slave will be lost.

Upvotes: 0

Related Questions