Aerospike отсутствует данные при добавлении нового узла в кластер - PullRequest
Новая
       18

Aerospike отсутствует данные при добавлении нового узла в кластер

0 голосов
/ 12 марта 2019

У меня есть кластер Aerospike (3.11.1.1) с 6 узлами.Когда я пытаюсь добавить новый узел, иногда некоторые объекты «временно» теряются, когда кластер переносит данные.После завершения миграции отсутствующие данные возвращаются.Это ошибка или я делаю что-то не так?Как избежать

Заметим, что во время миграции число главных объектов ниже, чем фактическое число окончательных объектов после завершения миграции

Число основных и реплик до завершения миграции:

Master and replica count before finishing migrations

Количество мастер-копий и реплик после завершения миграции:

Master and replica count after finishing migrations

My 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
        }
}

1 Ответ

1 голос
/ 12 марта 2019

Часть расхождений произошла из-за проблемы в первоначальном дизайне миграции / перебалансировки и устранена при изменении протокола в Aerospike 3.13 .Перед изменением протокола в 3.13 при запуске replication-factor 2 оператор должен обновить один узел за раз и дождаться завершения миграции после этого.

Дополнительное расхождение - Aerospike, избегающий перерасчета master-objects и репликиобъекты (т.е. prole-objects) во время миграции.Также с 3.13 мы добавили стат для non-replica-objects, которые являются объектами, которые в настоящее время не действуют как мастер или реплика.Это либо (а) объекты в разделе, который имеет входящие миграции, и в конечном итоге они будут действовать как реплика, либо (б) это объекты в разделе, которые не будут участвовать и будут отброшены после завершения миграции для раздела.

До версии 3.13 non-replica-object типа (a) уменьшало бы число как для master-objects, так и prole-objects.Это связано с тем, что до изменения протокола, когда раздел возвращается, который был главным, он сразу же возобновляет работу как главный, даже если у него нет новых записей, которые имели место, пока он отсутствовал.Это не оптимальное поведение, но оно не теряет данные, так как мы разрешим отсутствующие записи из non-replica-objects на других узлах.После изменения протокола возвращающийся раздел «master» не возобновит работу в качестве «master», пока не получит все миграции с других узлов.

До 3.13 non-replica-objects типа (b) немедленно отбрасывался иуменьшить счет на prole-objects.Это приводит к уменьшению replication-factor записей, записанных во время отсутствия узла, на единицу (например, replication-factor 2 временно становится replication-factor 1).По этой же причине важно было дождаться завершения миграции, прежде чем приступить к обновлению следующего узла.После изменения протокола (если только он не работает в памяти), больше нет необходимости ждать завершения миграций между обновлениями узлов, поскольку временные «подмножества разделов» не удаляются, что препятствует уменьшению replication-factor записи (фактически, сновый протокол, во время миграции часто replication-factor + 1 копия записи).

...