Aerospike теряет документы, когда узел выходит из строя

Я проводил тесты купола с помощью aerospike и заметил поведение, отличное от того, что продается.

У меня есть кластер из 4 узлов, работающих на AWS в той же AZ, экземпляры t2micro (1 ЦП, 1 ГБ ОЗУ, 25 ГБ SSD), использующие aws linux с AMI aerospike.

aerospike.conf:

heartbeat {
        mode mesh
        port 3002                        
        mesh-seed-address-port XXX.XX.XXX.164 3002
        mesh-seed-address-port XXX.XX.XXX.167 3002
        mesh-seed-address-port XXX.XX.XXX.165 3002
        #internal aws IPs
...
namespace teste2 {
        replication-factor 2
        memory-size 650M
            default-ttl 365d                                                                                                                    
        storage-engine device {
                    file /opt/aerospike/data/bar.dat
                    filesize 22G
                        data-in-memory false                                                                     
        }
}

То, что я сделал, было тестом, чтобы увидеть, потеряю ли я документы, когда узел выйдет из строя. Для этого я написал небольшой код на питоне:

from __future__ import print_function
import aerospike
import pandas as pd
import numpy as np
import time
import sys
config = {
  'hosts': [ ('XX.XX.XX.XX', 3000),('XX.XX.XX.XX',3000),
             ('XX.XX.XX.XX',3000), ('XX.XX.XX.XX',3000)]
} # external aws ips
client = aerospike.client(config).connect()
for i in range(1,10000):
  key = ('teste2', 'setTest3', ''.join(('p',str(i))))
  try:
    client.put(key, {'id11': i})
    print(i)
  except Exception as e:
    print("error: {0}".format(e), file=sys.stderr)
  time.sleep(1)

Я использовал этот код только для вставки последовательности целых чисел, которую я мог проверить после этого. Я запустил этот код и через несколько секунд остановил службу aerospike на одном узле на 10 секунд, используя sudo service aerospike stop и sudo service aerospike colstart для перезапуска.

Я подождал несколько секунд, пока узлы не выполнили всю миграцию, и выполнил следующий скрипт на Python:

query = client.query('teste2', 'setTest3')
query.select('id11')
te = []
def save_result((key, metadata, record)):
    te.append(record)
query.foreach(save_result)
d = pd.DataFrame(te)
d2 = d.sort(columns='id11')
te2 = np.array(d2.id11)
for i in range(0,len(te2)):
  if i > 0:
    if (te2[i] !=  (te2[i-1]+1) ):
      print('no %d'% int(te2[i-1]+1))
print(te2)

И получил в ответ:

no 3
no 6
no 8
no 11
no 13
no 17
no 20
no 22
no 24
no 26
no 30
no 34
no 39
no 41
no 48
no 53
[ 1  2  5  7 10 12 16 19 21 23 25 27 28 29 33 35 36 37 38 40 43 44 45 46 47 51 52 54]

Мой кластер настроен неправильно или это нормально?

PS: я попытался включить как можно больше вещей, если вы предложите дополнительную информацию для включения, я буду признателен.


person dtj    schedule 17.09.2015    source источник
comment
Выполнили ли вы рекомендации Aerospike для работы на EC2? Например, интервал = 150, время ожидания сердцебиения = 20, предварительный прогрев EBS и т. д. См. aerospike .com/docs/deploy_guides/aws/recommendations для полного списка.   -  person jarmod    schedule 18.09.2015
comment
Ok. Я изменил интервал и время ожидания на машинах. Настроен для распределения IRQ по нескольким ядрам с использованием RPS. Сделал предварительный прогрев. Проверка состояния экземпляра на панели инструментов EC2 не работает для всех 4 экземпляров, и я не могу получить доступ к aerospike, amc или через ssh. Они просто перестают работать...   -  person dtj    schedule 18.09.2015
comment
Эти рекомендации будут иметь мало общего с этой ситуацией. Какую версию Aerospike вы используете? Вы уверены, что миграция была завершена, когда вы инициировали сканирование?   -  person kporter    schedule 18.09.2015
comment
утилита резервного копирования также распечатает количество резервных копий записей. и может ориентироваться на отдельный набор. Чтобы исключить проблемы с клиентом, не могли бы вы сделать резервную копию и проверить количество?   -  person kporter    schedule 18.09.2015
comment
Сделал предварительный прогрев. ... Я не могу получить доступ к aerospike, amc или через ssh Похоже, вы обнулили корневой раздел?   -  person kporter    schedule 18.09.2015
comment
Это версия 3.6.0 (последняя из AWS Marketplace). В то время не было никаких миграций, я проверял через http-клиент amc. Я больше не могу получить доступ к экземплярам, ​​они недоступны, если я попытаюсь подключить hd (том) к другому экземпляру, могу ли я выполнить резервное копирование (мне не нужны данные, я просто хочу знать, что произошло) . И что вы подразумеваете под обнулением корневого раздела? (спасибо, кстати)   -  person dtj    schedule 18.09.2015
comment
Команда, используемая для предварительного прогрева устройства, перезаписывает устройство нулями. Это, безусловно, уничтожило бы ваши тестовые данные, обсуждаемые здесь, но если бы вы нацелились на устройство, на котором смонтирована ваша корневая файловая система, вы бы удалили свою ОС. Если вы очистили свою ОС и использовали другое устройство для хранения Aerospike, вы сможете подключить его к другому экземпляру.   -  person kporter    schedule 19.09.2015
comment
Хорошо, но объяснит ли это потерю вкладышей? Любая другая идея?   -  person dtj    schedule 21.09.2015
comment
Сможете ли вы повторить эти результаты? Не могли бы вы попробовать выполнить как запрос, так и обычный доступ ко всем ключам?   -  person kporter    schedule 25.09.2015


Ответы (1)


На самом деле я нашел решение, и оно довольно простое и глупое, если честно.

В файле конфигурации у нас есть некоторые параметры для сетевого взаимодействия между узлами, такие как:

interval 150                    # Number of milliseconds between heartbeats
timeout 10                      # Number of heartbeat intervals to wait
                                # before timing out a node

Эти два параметра задают время, которое требуется кластеру, чтобы понять, что узел отключен и находится вне кластера. (в данном случае 1,5 сек).

Мы сочли полезным настроить политики записи на клиенте для работы с этими параметрами.

В зависимости от клиента у вас будут некоторые политики, такие как количество попыток до сбоя операции, время ожидания операции, время между попытками.

Вам просто нужно адаптировать параметры клиента. Например: установите количество повторных попыток на 4 (каждая выполняется через 500 мс) и время ожидания на 2 секунды. При этом клиент распознает, что узел не работает, и перенаправит операцию на другой узел.

Эта настройка может быть чрезмерной для кластера, вызывая огромную перегрузку, но она сработала для нас.

person dtj    schedule 08.10.2015