Every day i need to scan all node separately. and write all Record into separately file.
From one day, i found there were two same key in two files( means two nodes, just think node A and B ). And when I use the aql to query only get one value( always meaning get the result from one fixed node, just think get from Node A ), and when i update the record, only the record in Node A will be updated( can see the different from scan file of next day ), and record with same key in Node B cannot be access, cannot query, cannot update, cannot deleted like a dirty record.
I think this case is happened during data migration, but i am not sure about this.
Having difficulty following your description. That said, 3.15.3.14 is very old with many known issues, it is also no longer a supported version. I suggest that an upgrade may fix your issue. If you have Enterprise support, open a case with them to help you along. If you are using community, I don’t think many will be willing to invest time investigating such an old build since it is unlikely to be mutually beneficial.
Are you able to share a list of your sets name? I wanted to double check that you are not using any forbidden characters like “:” or “;” in the set names.
asinfo -v sets -l
Most likely you have the same PK in different sets.
You can check for illegal characters in set names using this guide.
Another possibility is that you have some records with null sets. (no sets specified when they were written). A scan on the namespace would show two records (1 with no set name and 1 with a set name.)
example with two records:
aql> INSERT INTO test.demo (PK, foo, bar) VALUES ('key1', 123, 'abc')
OK, 1 record affected.
aql> INSERT INTO test (PK, foo, bar) VALUES ('key1', 123, 'abc')
OK, 1 record affected.
aql> select * from test.demo
+-----+-------+
| foo | bar |
+-----+-------+
| 123 | "abc" |
+-----+-------+
1 row in set (0.076 secs)
OK
aql> select * from test
+-----+-------+
| foo | bar |
+-----+-------+
| 123 | "abc" |
| 123 | "abc" |
+-----+-------+
2 rows in set (0.074 secs)
OK