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

IKuznetsov в 08:24, 7 января 2025

2025-01-07T08:24:23Z

← Предыдущая версия		Версия от 08:24, 7 января 2025
Строка 1:		Строка 1:
			'''''[[Установка и настройка]] / [[Установка и настройка\|Основные элементы АппОптима]] / [[АппОптима]] / [[АппОптима\|Эксплуатация]] / Преобразование с использованием восстановления с учетом стойки'''''

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

IKuznetsov в 16:09, 25 декабря 2024

2024-12-25T16:09:15Z

← Предыдущая версия		Версия от 16:09, 25 декабря 2024
Строка 18:		Строка 18:
	----'''Запустите восстановление АппОптима на каждом узле'''		----'''Запустите восстановление АппОптима на каждом узле'''

	Параллельно на каждом узле запустите программу установки АппОптима ~~Managed~~ со следующими параметрами:		Параллельно на каждом узле запустите программу установки АппОптима со следующими параметрами:

	* <code>--rack-name</code> - определяет стойку, к которой будет принадлежать этот узел.		* <code>--rack-name</code> - определяет стойку, к которой будет принадлежать этот узел.

IKuznetsov в 13:54, 8 ноября 2024

2024-11-08T13:54:07Z

← Предыдущая версия		Версия от 13:54, 8 ноября 2024
Строка 11:		Строка 11:
	Восстановить кластер в новые стойки		Восстановить кластер в новые стойки

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

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

	2. Выполните официальную процедуру восстановления кластера (резервное копирование и восстановление кластера), используя следующий измененный шаг:		2. Выполните официальную процедуру восстановления кластера (резервное копирование и восстановление кластера), используя следующий измененный шаг:
	----'''Запустите восстановление ~~Ключ-АСТРОМ~~ на каждом узле'''		----'''Запустите восстановление АппОптима на каждом узле'''

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

	* <code>--rack-name</code> - определяет стойку, к которой будет принадлежать этот узел.		* <code>--rack-name</code> - определяет стойку, к которой будет принадлежать этот узел.
Строка 65:		Строка 65:
	Когда преобразование будет завершено, вы увидите стойки на странице состояния развертывания в консоли управления кластером:		Когда преобразование будет завершено, вы увидите стойки на странице состояния развертывания в консоли управления кластером:

	[[Файл:Cmcstatus.webp\|альт=Страница состояния развертывания CMC кластера с учетом стойки]]		[[Файл:Cmcstatus.webp\|альт=Страница состояния развертывания CMC кластера с учетом стойки\|1068x1068пкс]]

Lobanov: /* Восстановление кластера в новые стойки */

2022-03-15T17:23:10Z

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

← Предыдущая версия		Версия от 17:23, 15 марта 2022
Строка 52:		Строка 52:
	<code>1: 10.176.41.168, 3: 10.176.41.169, 5: 10.176.41.170</code> - идентификаторы узлов и новые IP-адреса всех узлов в кластере		<code>1: 10.176.41.168, 3: 10.176.41.169, 5: 10.176.41.170</code> - идентификаторы узлов и новые IP-адреса всех узлов в кластере

	# <code>sudo ./tmp/backup-~~001~~-~~dynatrace-managed-installer~~.sh</code>		# <code>sudo ./tmp/{backup-instaler-name}.sh</code>
	# <code>--rack-name rack2</code>		# <code>--rack-name rack2</code>
	# <code>--rack-dc datacenter1</code>		# <code>--rack-dc datacenter1</code>

YaPolkin: Новая страница: «Этот метод универсален и может работать для больших кластеров и более сложных изменений...»

2021-12-06T07:22:41Z

Новая страница: «Этот метод универсален и может работать для больших кластеров и более сложных изменений...»

Новая страница

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

[[Файл:Man-conversion-restore.webp|альт=Процесс преобразования Managed кластера в кластер с учетом стойки с помощью резервного копирования и восстановления]]

== Подготовка ==

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

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

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

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

2. Выполните официальную процедуру восстановления кластера (резервное копирование и восстановление кластера), используя следующий измененный шаг:
----'''Запустите восстановление Ключ-АСТРОМ на каждом узле'''

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

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

<code><path-to-backup>/<UUID>/node_<node_id>/files/<backup_version_number>/<backup_file></code>
----<blockquote>Пример резервного пути

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

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

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

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

Номер версии резервной копии увеличивается при каждом выполнении резервного копирования.</blockquote>
----Получите идентификаторы и IP-адреса из инвентаря, который вы создали перед началом работы.

Например:

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

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

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

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

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

[[Файл:Cmcstatus.webp|альт=Страница состояния развертывания CMC кластера с учетом стойки]]