testing_project/Documentation: book/admin/disaster_recovery — Russian @ Weblate: $ head -5 *.xlog | grep Instance Instance: ed607cad-8b6d-48d8-ba0b-dae371b79155

The translation is temporarily closed for contributions due to maintenance, please come back later.
The translation was automatically locked due to following alerts: Could not merge the repository.

Zen

	English	Russian	Actions
	Disaster recovery	Аварийное восстановление
	The minimal fault-tolerant Tarantool configuration would be a :ref:`replication cluster<replication-topologies>` that includes a master and a replica, or two masters.	Минимальная отказоустойчивая конфигурация Tarantool -- это :ref:`репликационный кластер <replication-topologies>`, содержащий мастер и реплику или два мастера.
	The basic recommendation is to configure all Tarantool instances in a cluster to create :ref:`snapshot files <index-box_persistence>` at a regular basis.	Основная рекомендация -- настраивать все экземпляры Tarantool в кластере таким образом, чтобы они регулярно создавали :ref:`файлы-снимки <index-box_persistence>`.
	Here follow action plans for typical crash scenarios.	Ниже дано несколько инструкций для типовых аварийных сценариев.
	Master-replica	Мастер-реплика
	Configuration: One master and one replica.	Конфигурация: один мастер и одна реплика.
	Problem: The master has crashed.	Проблема: мастер вышел из строя.
	Your actions:	План действий:
	Ensure the master is stopped for good. For example, log in to the master machine and use ``systemctl stop tarantool@<instance_name>``.	Убедитесь, что мастер полностью остановлен. Например, подключитесь к мастеру и используйте команду ``systemctl stop tarantool@<имя_экземпляра>``.
	Switch the replica to master mode by setting :ref:`box.cfg.read_only <cfg_basic-read_only>` parameter to false and let the load be handled by the replica (effective master).	Переключите реплику в режим мастера, установив параметру :ref:`box.cfg.read_only <cfg_basic-read_only>` значение false. Теперь вся нагрузка пойдет только на реплику (по сути ставшую мастером).
	Set up a replacement for the crashed master on a spare host, with :ref:`replication <cfg_replication-replication>` parameter set to replica (effective master), so it begins to catch up with the new master’s state. The new instance should have :ref:`box.cfg.read_only <cfg_basic-read_only>` parameter set to true.	Настройте на свободной машине замену вышедшему из строя мастеру, установив параметру :ref:`replication <cfg_replication-replication>` в качестве значения URI реплики (которая в данный момент выполняет роль мастера), чтобы новая реплика начала синхронизироваться с текущим мастером. Значение параметра :ref:`box.cfg.read_only <cfg_basic-read_only>` в новом экземпляре должно быть установлено на true.
	You lose the few transactions in the master :ref:`write ahead log file <index-box_persistence>`, which it may have not transferred to the replica before crash. If you were able to salvage the master .xlog file, you may be able to recover these. In order to do it:	Все немногочисленные транзакции в :ref:`WAL-файле <index-box_persistence>` мастера, которые он не успел передать реплике до выхода из строя, будут потеряны. Однако если удастся получить .xlog-файл мастера, их можно будет восстановить. Для этого:
	Find out the position of the crashed master, as reflected on the new master.	Узнайте позицию вышедшего из строя мастера -- эта информация доступна из нового мастера.
	Find out instance UUID from the crashed master :ref:`xlog <internals-wal>`:	Посмотрите UUID экземпляра в :ref:`xlog-файле <internals-wal>` вышедшего из строя мастера:
	$ head -5 *.xlog \| grep Instance Instance: ed607cad-8b6d-48d8-ba0b-dae371b79155	$ head -5 *.xlog \| grep Instance Instance: ed607cad-8b6d-48d8-ba0b-dae371b79155
	On the new master, use the UUID to find the position:	Используйте этот UUID на новом мастере для поиска позиции:
	tarantool> box.info.vclock[box.space._cluster.index.uuid:select{'ed607cad-8b6d-48d8-ba0b-dae371b79155'}[1][1]] --- - 23425 <...>	tarantool> box.info.vclock[box.space._cluster.index.uuid:select{'ed607cad-8b6d-48d8-ba0b-dae371b79155'}[1][1]] --- - 23425 <...>
	Play the records from the crashed .xlog to the new master, starting from the new master position:	Запишите транзакции из .xlog-файла вышедшего из строя мастера в новый мастер, начиная с позиции нового мастера:
	Issue this request locally at the new master's machine to find out instance ID of the new master:	Локально выполните эту команду на новом мастере, чтобы узнать его ID экземпляра:
	tarantool> box.space._cluster:select{} --- - - [1, '88580b5c-4474-43ab-bd2b-2409a9af80d2'] ...	tarantool> box.space._cluster:select{} --- - - [1, '88580b5c-4474-43ab-bd2b-2409a9af80d2'] ...
	Play the records to the new master:	Запишите транзакции в новый мастер:
	$ tt play <new_master_uri> <xlog_file> --from 23425 --replica 1	$ tarantoolctl <uri_нового_мастера> <xlog_файл> play --from 23425 --replica 1
	Master-master	Мастер-мастер
	Configuration: Two masters.	Конфигурация: два мастера.
	Problem: Master#1 has crashed.	Проблема: мастер #1 вышел из строя.
	Let the load be handled by master#2 (effective master) alone.	Пусть вся нагрузка идет только на мастер #2 (действующий мастер).
	2. Follow the same steps as in the :ref:`master-replica <admin-disaster_recovery-master_replica>` recovery scenario to create a new master and salvage lost data.	2. Создайте новый мастер и восстановите данные, проделав те же шаги, что и в сценарии для конфигурации :ref:`мастер-реплика <admin-disaster_recovery-master_replica>`.
	Data loss	Потеря данных
	Configuration: Master-master or master-replica.	Конфигурация: мастер-мастер или мастер-реплика.
	Problem: Data was deleted at one master and this data loss was propagated to the other node (master or replica).	Проблема: данные были удалены на одном мастере, а затем эти изменения реплицировались на другом узле (мастере или реплике).