Как справиться со сбоями в работе центра обработки данных в кластере Cassandra Cluster.

Наше приложение работает в кластере Cassandra из шести узлов с двумя центрами обработки данных.

Информация о кластере:

Версия Cassandra: 2.0.3

Snitch: GossipingPropertyFileSnith

Partitioner: Murmur3Partitioner

У каждого постоянного тока есть три узла.

У каждого постоянного тока коэффициент репликации равен 2.

Каждый узел использует num_vnodes = 256. (все виртуальные узлы)

DC1 - это постоянный ток в реальном времени (локальный постоянный ток), который в настоящее время предоставляет данные пользователям. DC2 - это просто резервный постоянный ток (удаленный постоянный ток), который не передает никаких данных пользователям. Поскольку мы планируем операции по техническому обслуживанию только в DC1, мы собираемся сделать удаленный DC DC2 для обслуживания пользователей в течение периода обслуживания.

Во время отключения весь DC1 может выйти из строя на несколько дней. После завершения обслуживания мы снова сделаем DC1 для обслуживания данных и DC2 для резервного копирования. Поэтому нам нужно иметь актуальные данные в DC1 после сбоя. Наше приложение будет обрабатывать большие объемы данных (несколько ГБ) во время простоя.

Перед отключением DC1

1) О чем (например, настройках журнала фиксации и т. Д.) Нужно позаботиться на узлах DC1.

2) О чем все (например, о настройках хэндовера и т. Д.) Нужно позаботиться в узлах DC2.

Во время отключения

3) Когда весь DC1 не работает, где будут написаны подсказки (в любом из узлов DC2?) И как обработать эти подсказки?

После включения DC1

4) Во время простоя репликация может дать сбой в узлах DC1. Как мы можем эффективно изготовить / отремонтировать DC1 с актуальными данными, используя DC2?


nosql cassandra cql cassandra-2.0 cassandra-2.1
person Ravi Raja Chandra Bose    schedule 18.12.2015    source источник
comment
См. Также stackoverflow.com/questions/13647921/   -  person Raedwald    schedule 23.12.2015

Ответы (1)


arrow_upward
1
arrow_downward

понижает DC1

Перед отключением DC1 убедитесь, что вы выполнили полное восстановление с помощью nodetool repair.

Это гарантирует, что все данные передаются от DC1 к DC2.

Затем начните уничтожать узлы один за другим из DC1. следуйте инструкциям, приведенным здесь

Убедитесь, что согласованность записи будет выполняться с вашим DC2, иначе вы потеряете все свои данные.

если вы пишете с ЛЮБЫМ уровнем согласованности, то это гарантирует вам надежность записи.

Во время отключения

Если вы используете настройку cassnadra по умолчанию, подсказки будут храниться только в течение 3 часов. Увеличение этого параметра приведет к ненужным накладным расходам вашей машины, и я не буду предлагать вам хранить подсказки на 5 дней.

Вы можете настроить интервал времени подсказки, используя свойство max_hint_window_in_ms в файле cassandra.yaml.

Я не уверен, что вы должны позволять cassandra писать подсказки для DC1.

После того, как DC1 поднят

снова запустите полное восстановление с помощью nodetool repair, чтобы реплицировать данные в вашем центре обработки данных.

person Aftab    schedule 18.12.2015
comment
Запись с CL.ANY не гарантирует, что запись достигнет одной из реплик, ответственных за ключ раздела данных. Если, скажем, все реплики для раздела отключены, CL.ANY позволяет другому узлу (то есть координатору) сохранить запись в качестве подсказанной передачи обслуживания, которая будет воспроизведена, когда одна из ответственных реплик станет доступной - ЕСЛИ одна из них станет доступной. Обратите внимание, что подсказки передачи могут истечь (теряя долговечность). Уровень согласованности CL.ONE гарантирует, что ваша запись попала хотя бы в одну из ответственных реплик. - person William Price; 07.01.2016