Начальная загрузка центра обработки данных с помощью моментального снимка

Я предоставляю новый центр обработки данных для существующего кластера. Довольно шаткое VPN-соединение мешает мне выполнить nodetool rebuild начальную загрузку нового DC. Интересно, что у меня есть полный свежий снимок/резервная копия базы данных в том же месте, что и новый DC (перенесенный за пределы VPN). Сейчас я рассматриваю следующий подход:

  1. Убедитесь, что мои клиенты используют старый контроллер домена.
  2. Подготовьте новые узлы в новом DC.
  3. ALTER пространство ключей, чтобы включить реплики на новом контроллере домена. Это начнет репликацию всех записей со старого контроллера домена на новый контроллер домена.
  4. Перед gc_grace_seconds после операции 3) выше используйте sstableloader для потоковой передачи моей резервной копии на новые узлы.
  5. В целях безопасности произведите полный ремонт.

Будет ли это работать?


cassandra datastax datastax-enterprise cassandra-2.1 datastax-startup
person Ztyx    schedule 18.04.2016    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Наша команда тоже столкнулась с похожей ситуацией. Мы запускаем C* на Amazon EC2.

Итак, сначала мы подготовили снимок существующих узлов и использовали их для создания их для другого центра обработки данных (чтобы избежать передачи огромных объемов данных).

Процедура, которой мы следовали:

  1. Change replication strategy for all DC1 servers from simple-strategy to networkTopologyStrategy {DC1:x, DC2:y}
    1. change cassandra.yaml
      • endpoint_snitch: GossipingPropertyFileSnitch
      • добавить IP-адрес узла DC2 в список семян
      • остальные менять не надо
    2. change cassandra-rackdc.properties
      • dc=DC1
      • стойка=RAC1
    3. restart nodes one at a time.
      • restart seed node first
    4. Alter the keyspace. ALTER KEYSPACE keyspace_name WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'DC1' : x, 'DC2':y };
      • Do it for all keyspace in DC1
    5. нет необходимости ремонтировать.
    6. проверить стабильность системы по запросу
  2. Add DC2 servers as new data center to DC1 data center
    • https://docs.datastax.com/en/cassandra/2.1/cassandra/operations/ops_add_dc_to_cluster_t.html
      1. in DC2 db, cassandra.yaml > auto_bootstrap: false
      2. fix seeds, endpoint_snitch, cluster name
        • Node1 DC1 IP, Node2 DC2 IP as seeds.
        • рекомендуемый endpoint_snitch : GossipingPropertyFileSnitch
        • имя кластера, такое же, как DC1: test-cluster
      3. fix gossiping-property-file-snith : cassandra-rackdc.properties
        • dc=DC2
        • стойка=RAC1
      4. bring DC2 nodes up one at a time
        • seed node first
      5. изменить пространство ключей на networkTopologyStrategy {DC1:x, DC2:y}
      6. поскольку база данных DC2 копируется из DC1, мы должны восстановить, а не перестроить
person chaitan64arun    schedule 20.04.2016
comment
Большой! Незначительная деталь: исправления в версии 2.6 (которая очень медленная!) можно было бы избежать, если бы вместо этого вы использовали sstableloader для загрузки моментального снимка в новый центр обработки данных. - person Ztyx; 21.04.2016

arrow_upward
1
arrow_downward

Да, этот подход должен работать. Я проверил его с помощью двух знающих людей в сообществе Cassandra. Однако важно отметить два момента:

  • Моментальный снимок создается после того, что мутации начали записываться в новый центр обработки данных.
  • Резервная копия должна быть полностью импортирована до gc_grace_seconds после создания резервной копии. В противном случае вы рискуете получить всплывающие данные о зомби.
person Ztyx    schedule 21.04.2016