dirty read if the connection is not stable?

[zouyonghao]

I see some logs about reading dirty data, and some logs about connection error.

Does the default read operation of client allow dirty read?

OS: Ubuntu 18.04.5
Version: Aerospike Community Edition build 5.6.0.5
Client: aerospike-client-c-5.2.0.ubuntu18.04.x86_64

[kportertx]

Dirty read tends to mean the reading uncommitted data. That shouldn't be possible, otherwise would be a bug.

Please clarify what you mean by dirty read.

[zouyonghao]

Sorry, maybe I misunderstand.
The error I met is that I got read of old data like logs below

{:process 1342109410, :type :ok, :f :write, :value 1808049630},
{:process 1333716706, :type :invoke, :f :read, :value nil},
{:process 1333716706, :type :ok, :f :read, :value 1808049630},
{:process 1325324002, :type :invoke, :f :write, :value 2822355899},
{:process 1325324002, :type :ok, :f :write, :value 2822355899},
{:process 1316931298, :type :invoke, :f :write, :value 2853104656},
{:process 1316931298, :type :ok, :f :write, :value 2853104656},
{:process 1308538594, :type :invoke, :f :read, :value nil},
{:process 1308538594, :type :ok, :f :read, :value 1808049630},

Maybe it's a split-brain issue?

[kportertx]

Oh, of course stale reads can happen when not using Strong Consistency mode which isn't available in the community edition. Any time there are multiple masters in AP (split brain) the client could update either and read either. When the split brain clears, Aerospike will have to conflict resolve records updated on different masters. AP conflict resolution policies give you the option to either keep the latest update or the update which likely preserves the most history. In either case, updates not chosen will be lost.

If you require stronger consistency guarantees and it is acceptable to sacrifice availability then you will need to look to the "Strong Consistency" feature in our Enterprise version.