Преобразование с использованием восстановления с учетом стойки

Материал из Dynatrace
Версия от 07:22, 6 декабря 2021; YaPolkin (обсуждение | вклад) (Новая страница: «Этот метод универсален и может работать для больших кластеров и более сложных изменений...»)
(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)

Этот метод универсален и может работать для больших кластеров и более сложных изменений топологии. Однако процесс восстановления занимает много времени, и из-за ежедневного резервного копирования происходит некоторая потеря данных. Хранилище транзакций (PurePaths) не содержится в резервной копии.

Процесс преобразования Managed кластера в кластер с учетом стойки с помощью резервного копирования и восстановления

Подготовка

  • Убедитесь, что у кластера есть последняя резервная копия. См. Резервное копирование и восстановление кластера.
  • Подготовьте новый узел (ы). Убедитесь, что раздел диска, выделенный для хранилища Cassandra на новом узле, достаточен для размещения всей базы данных Cassandra (с запасом для сжатия и новых данных). Размер диска должен быть как минимум вдвое больше объединенных хранилищ Cassandra всех существующих узлов кластера. Рекомендуется размещать данные Cassandra на отдельном томе, чтобы избежать проблем с дисковым пространством, связанных с различными типами данных.

Восстановление кластера в новые стойки

Восстановить кластер в новые стойки

1. Остановите существующий кластер, чтобы два кластера с одинаковым идентификатором не могли подключиться к Ключ-АСТРОМ Mission Control.

См. Запуск/остановка/перезапуск кластера.

2. Выполните официальную процедуру восстановления кластера (резервное копирование и восстановление кластера), используя следующий измененный шаг:

Запустите восстановление Ключ-АСТРОМ на каждом узле

Параллельно на каждом узле запустите программу установки Ключ-АСТРОМ Managed со следующими параметрами:

  • --rack-name - определяет стойку, к которой будет принадлежать этот узел.
  • --rack-dc - определяет дата-центр, которому будет принадлежать этот узел.
  • --restore - переводит программу установки в режим восстановления.
  • --cluster-ip - IPv4-адрес узла, на котором вы запускаете установщик.
  • --cluster-nodes - разделенный запятыми список идентификаторов и IP-адресов всех узлов в кластере, включая тот, на котором вы запускаете установщик, в следующем формате <node_id>:<node_ip>,<node_id>:<node_ip>.
  • --seed-ip - IPv4-адрес исходного узла.
  • backup-file - путь к файлу резервной копии *.tar , который включает путь к монтированию общего файлового хранилища, идентификатор кластера, идентификатор узла, версию резервной копии и файл резервной копии *.tar в следующем формате:

<path-to-backup>/<UUID>/node_<node_id>/files/<backup_version_number>/<backup_file>

Пример резервного пути

В этом примере пути: /mnt/backup/bckp/c9dd47f0-87d7-445e-bbeb-26429fac06c6/node_1/files/19/backup-001.tar части пути следующие:

  • <path-to-backup> = /mnt/backup/bckp/
  • <UUID> = c9dd47f0-87d7-445e-bbeb-26429fac06c6
  • <node_id> = 1
  • <backup_version_number> = 19

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

  • Каталог с более низким номером версии содержит старую резервную копию. Он будет удален после завершения резервного копирования.
  • Каталог с более высоким номером версии содержит текущую резервную копию.

Номер версии резервной копии увеличивается при каждом выполнении резервного копирования.

Получите идентификаторы и IP-адреса из инвентаря, который вы создали перед началом работы.

Например:

10.176.41.168 - IP-адрес восстанавливаемого узла

1: 10.176.41.168, 3: 10.176.41.169, 5: 10.176.41.170 - идентификаторы узлов и новые IP-адреса всех узлов в кластере

  1. sudo ./tmp/backup-001-dynatrace-managed-installer.sh
  2. --rack-name rack2
  3. --rack-dc datacenter1
  4. --restore
  5. --cluster-ip "10.176.41.168"
  6. --cluster-nodes "1:10.176.41.168,3:10.176.41.169,5:10.176.41.170"
  7. --seed-ip "10.176.41.169"
  8. --backup-file /mnt/backup/bckp/c9dd47f0-87d7-445e-bbeb-26429fac06c6/node_1/files/19/backup-001.tar

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

Когда преобразование будет завершено, вы увидите стойки на странице состояния развертывания в консоли управления кластером:

Страница состояния развертывания CMC кластера с учетом стойки

Источник — https://doc.expert-apm.kz/index.php?title=Преобразование_с_использованием_восстановления_с_учетом_стойки&oldid=512