将新节点添加到群集时，Aerospike会丢失数据

Question

我有一个带有6个节点的Aerospike（3.11.1.1）集群。当我尝试添加新节点时，有时某些对象在群集迁移数据时“暂时”丢失。迁移完成后，丢失的数据将返回。这是一个BUG还是我做错了什么？怎么避免

注意到迁移发生时，主对象计数低于迁移完成后的实际最终对象计数

完成迁移之前的主计数和副本计数：

完成迁移后的主数据和副本计数：

我的aerospike.conf：

service {
    user root
    group root
    paxos-single-replica-limit 1 # Number of nodes where the replica count is automatically reduced to 1.
        paxos-recovery-policy auto-reset-master
    pidfile /var/run/aerospike/asd.pid
    service-threads 32
    transaction-queues 32
    transaction-threads-per-queue 4
        batch-index-threads 40
    proto-fd-max 15000
        batch-max-requests 30000
        replication-fire-and-forget true
}

logging {
    # Log file must be an absolute path.
    file /var/log/aerospike/aerospike.log {
        context any info
    }
}

network {
    service {
        #address any
        port 3000
    }

    heartbeat {
                mode mesh
                mesh-seed-address-port 10.240.0.32 3002
                mesh-seed-address-port 10.240.0.33 3002
                port 3002

        interval 150
        timeout 20
    }

    fabric {
        port 3001
    }

    info {
        port 3003
    }
}

namespace mynamespace {
    replication-factor 2
    memory-size 1500M
    default-ttl 0 # 30 days, use 0 to never expire/evict.
        ldt-enabled true
        write-commit-level-override master

    storage-engine device {
          file /data/aerospike.dat
          #device /dev/sdb
          write-block-size 1M
          filesize 280G
        }
}

Answer 1

一些差异是由于原始迁移/再平衡设计中的问题，并且在Aerospike 3.13的协议更改中得到了解决。在3.13中的协议更改之前，运行replication-factor 2时，运营商必须一次升级一个节点，然后等待迁移完成。

另外的差异是Aerospike避免在迁移过程中过度计算master-objects和复制对象（即prole-objects）。同样在3.13中，我们为non-replica-objects添加了一个stat，它是目前不作为master或replica的对象。这些是（a）具有入站迁移的分区上的对象，并且最终将充当副本，或者（b）这些是不参与的分区上的对象，并且当迁移终止于分区时将被删除。

在3.13之前，（a）类型的non-replica-object将减少master-objects或prole-objects的计数。这是因为在协议更改之前，当分区返回先前为master时，它会立即恢复为master，即使它没有在它离开时发生的新写入。这不是最佳行为，但它不会丢失数据，因为我们将从其他节点上的non-replica-objects解析丢失的记录。在协议更改后，返回的“主”分区将不会恢复为“主”，直到它收到来自其他节点的所有迁移。

在3.13之前，（b）类型的non-replica-objects会立即下降，并会减少prole-objects的数量。这导致在节点离开时写入的记录的replication-factor减少一个（例如replication-factor 2暂时变为replication-factor 1）。这也是在继续升级下一个节点之前等待迁移完成的重要原因。发布协议更改（除非仅在内存中运行），不再需要等待节点升级之间的迁移完成，因为临时的“子集分区”不会被丢弃，这会阻止记录的replication-factor被减少（实际上，新的协议，在迁移过程中经常有replication-factor + 1份记录）。