# Резервное копирование и восстановление

Регулярное резервное копирование ваших таблиц необходимо для восстановления в случае сбоев системы, отказа оборудования или повреждения/потери данных. Также настоятельно рекомендуется создавать резервные копии перед обновлением до новой версии Manticore Search или перед выполнением команды [ALTER TABLE](../Updating_table_schema_and_settings.md#Updating-table-schema-in-RT-mode).

Резервное копирование систем баз данных можно выполнять двумя уникальными способами: логическое и физическое копирование. У каждого из этих методов есть свои преимущества и недостатки, которые могут варьироваться в зависимости от конкретной среды базы данных и потребностей. Здесь мы рассмотрим различия между этими двумя типами резервных копий.

### Логические резервные копии

Логические резервные копии предполагают экспорт схемы базы данных и данных в виде SQL-запросов или форматов данных, специфичных для данной базы данных. Этот формат резервной копии обычно читаем человеком и может использоваться для восстановления базы данных на различных системах или движках баз данных.

Преимущества и недостатки логических резервных копий:
- ➕ **Портабельность:** Логические резервные копии обычно более переносимы, чем физические, так как могут использоваться для восстановления базы данных на разном аппаратном обеспечении или операционных системах.
- ➕ **Гибкость:** Логические резервные копии позволяют выборочно восстановить отдельные таблицы, индексы или другие объекты базы данных.
- ➕ **Совместимость:** Логические резервные копии могут использоваться для миграции данных между разными системами управления базами данных или их версиями, при условии, что целевая система поддерживает экспортируемый формат или SQL-запросы.
- ➖ **Медленное резервное копирование и восстановление:** Логические резервные копии могут выполняться медленнее физических, так как движку базы данных необходимо преобразовывать данные в SQL-запросы или иной формат экспорта.
- ➖ **Повышенная нагрузка на систему:** Создание логических резервных копий может вызвать большую нагрузку на систему, так как процесс требует больше ресурсов CPU и памяти для обработки и экспорта данных.

Manticore Search поддерживает [mysqldump](../Securing_and_compacting_a_table/Backup_and_restore.md#Backup-and-restore-with-mysqldump) для логического резервного копирования.

### Физические резервные копии

Физические резервные копии предполагают копирование сырых файлов данных и системных файлов, составляющих базу данных. Такой тип резервного копирования фактически создает снимок физического состояния базы данных в определенный момент времени.

Преимущества и недостатки физических резервных копий:
- ➕ **Скорость:** Физические резервные копии, как правило, выполняются быстрее логических, так как они предполагают прямое копирование сырых файлов данных с диска.
- ➕ **Согласованность:** Физические резервные копии обеспечивают согласованную резервную копию всей базы данных, так как все связанные файлы копируются вместе.
- ➕ **Низкая нагрузка на систему:** Создание физических резервных копий обычно накладывает меньше нагрузки на систему по сравнению с логическими, так как процесс не включает дополнительную обработку данных.
- ➖ **Портабельность:** Физические резервные копии обычно менее переносимы, чем логические, поскольку могут зависеть от конкретного оборудования, операционной системы или конфигурации движка базы данных.
- ➖ **Гибкость:** Физические резервные копии не позволяют выборочно восстанавливать отдельные объекты базы данных, так как резервная копия содержит сырые файлы всей базы данных.
- ➖ **Совместимость:** Физические резервные копии нельзя использовать для миграции данных между разными системами управления базами данных или их версиями, так как сырые файлы данных могут быть несовместимы между разными платформами или программным обеспечением.

Manticore Search имеет инструмент командной строки [manticore-backup](../Securing_and_compacting_a_table/Backup_and_restore.md#Using-manticore-backup-command-line-tool) для физических резервных копий.

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

## Использование инструмента командной строки manticore-backup

Инструмент `manticore-backup`, входящий в состав официальных [пакетов](https://manticoresearch.com/install) Manticore Search, автоматизирует процесс резервного копирования таблиц для экземпляра, работающего в [RT режиме](../Read_this_first.md#Real-time-mode-vs-plain-mode).

### Установка

**Если вы следовали [официальным инструкциям по установке](https://manticoresearch.com/install/), у вас уже должно быть все установлено и не о чем беспокоиться.** В противном случае, [`manticore-backup`](https://github.com/manticoresoftware/manticoresearch-backup) требует PHP 8.1.10 и [специфические модули](https://github.com/manticoresoftware/executor/blob/main/build-linux) или [`manticore-executor`](https://github.com/manticoresoftware/executor), и вам необходимо убедиться, что один из них доступен.

Обратите внимание, что `manticore-backup` пока недоступен для Windows.

### Как использовать

Во-первых, убедитесь, что вы запускаете `manticore-backup` на том же сервере, где работает экземпляр Manticore, который вы собираетесь резервировать.

Во-вторых, рекомендуется запускать инструмент под пользователем `root`, чтобы инструмент мог передавать права собственности на файлы, которые вы резервируете. В противном случае резервное копирование также будет выполнено, но без передачи прав собственности. В любом случае убедитесь, что `manticore-backup` имеет доступ к каталогу данных экземпляра Manticore.

<!-- example backup1 -->

Единственным обязательным аргументом для `manticore-backup` является `--backup-dir`, который указывает место назначения для резервной копии. Если вы не укажете дополнительных аргументов, `manticore-backup` будет:
- обнаруживать экземпляр Manticore, работающий с конфигурацией по умолчанию
- создавать подкаталог в директории `--backup-dir` с именем, включающим временную метку
- выполнять резервное копирование всех таблиц, найденных в экземпляре

<!-- request Example -->
```bash
manticore-backup --config=path/to/manticore.conf --backup-dir=backupdir
```

<!-- response Example -->
```bash
Copyright (c) 2023-2024, Manticore Software LTD (https://manticoresearch.com)

Manticore config file: /etc/manticoresearch/manticore.conf
Tables to backup: all tables
Target dir: /mnt/backup/

Manticore config
  endpoint =  127.0.0.1:9308

Manticore versions:
  manticore: 5.0.2
  columnar: 1.15.4
  secondary: 1.15.4
2022-10-04 17:18:39 [Info] Starting the backup...
2022-10-04 17:18:39 [Info] Backing up config files...
2022-10-04 17:18:39 [Info]   config files - OK
2022-10-04 17:18:39 [Info] Backing up tables...
2022-10-04 17:18:39 [Info]   pq (percolate) [425B]...
2022-10-04 17:18:39 [Info]    OK
2022-10-04 17:18:39 [Info]   products (rt) [512B]...
2022-10-04 17:18:39 [Info]    OK
2022-10-04 17:18:39 [Info] Running sync
2022-10-04 17:18:42 [Info]  OK
2022-10-04 17:18:42 [Info] You can find backup here: /mnt/backup/backup-20221004171839
2022-10-04 17:18:42 [Info] Elapsed time: 2.76s
2022-10-04 17:18:42 [Info] Done
```
<!-- end -->

<!-- example backup2 -->
Чтобы резервировать только определённые таблицы, используйте флаг `--tables`, за которым следует список таблиц, разделенных запятыми, например `--tables=tbl1,tbl2`. В этом случае будут сохранены только указанные таблицы, остальные будут игнорированы.

<!-- request Example -->
```bash
manticore-backup --backup-dir=/mnt/backup/ --tables=products
```

<!-- response Example -->
```bash
Copyright (c) 2023-2024, Manticore Software LTD (https://manticoresearch.com)

Manticore config file: /etc/manticoresearch/manticore.conf
Tables to backup: products
Target dir: /mnt/backup/

Manticore config
  endpoint =  127.0.0.1:9308

Manticore versions:
  manticore: 5.0.3
  columnar: 1.16.1
  secondary: 0.0.0
2022-10-04 17:25:02 [Info] Starting the backup...
2022-10-04 17:25:02 [Info] Backing up config files...
2022-10-04 17:25:02 [Info]   config files - OK
2022-10-04 17:25:02 [Info] Backing up tables...
2022-10-04 17:25:02 [Info]   products (rt) [512B]...
2022-10-04 17:25:02 [Info]    OK
2022-10-04 17:25:02 [Info] Running sync
2022-10-04 17:25:06 [Info]  OK
2022-10-04 17:25:06 [Info] You can find backup here: /mnt/backup/backup-20221004172502
2022-10-04 17:25:06 [Info] Elapsed time: 4.82s
2022-10-04 17:25:06 [Info] Done
```
<!-- end -->

### Аргументы

| Argument | Описание |
|-|-|
| `--backup-dir=path` | Путь к директории резервного копирования, где будет храниться резервная копия. Директория должна уже существовать. Этот аргумент обязателен и не имеет значения по умолчанию. При каждом запуске резервного копирования `manticore-backup` создаст поддиректорию в указанной директории с меткой времени в имени (`backup-[дата-время]`) и скопирует в неё все необходимые таблицы. Таким образом, `--backup-dir` является контейнером для всех ваших резервных копий, и можно безопасно запускать скрипт несколько раз. Поддерживает URL-адреса S3 в формате `s3://bucket/prefix` — подробности см. в разделе [Поддержка хранилища S3](../Securing_and_compacting_a_table/Backup_and_restore.md#S3-storage-support).|
| `--restore[=backup]` | Восстановить из `--backup-dir`. Просто `--restore` выводит список доступных резервных копий. `--restore=backup` восстановит из `<--backup-dir>/backup`. Работает как с локальными путями, так и с URL-адресами S3. |
| `--force` | Пропустить проверку версий при восстановлении и выполнить восстановление без ошибок. |
| `--disable-telemetry` | Укажите этот флаг, если хотите отключить отправку анонимизированных метрик в Manticore. Можно также использовать переменную окружения TELEMETRY=0 |
| `--config=/path/to/manticore.conf` | Путь к конфигурационному файлу Manticore. Необязательно. Если не указан, будет использована конфигурация по умолчанию для вашей операционной системы. Используется для определения хоста и порта для связи с демоном Manticore. Инструмент `manticore-backup` поддерживает [динамические настройки](../Server_settings/Scripted_configuration.md). Можно указать опцию `--config` несколько раз, если конфигурация разбросана по нескольким файлам. |
| `--tables=tbl1,tbl2, ...` | Список таблиц через точку с запятой, которые нужно сохранить резервную копию. Для резервного копирования всех таблиц этот аргумент можно опустить. Все указанные таблицы должны существовать в экземпляре Manticore, из которого вы делаете резервное копирование, иначе оно завершится ошибкой. |
| `--compress` | Нужно ли сжимать резервные файлы. По умолчанию не включено. | необязательно |
| `--unlock` | В редких случаях, когда что-то идет не так, таблицы могут остаться заблокированными. Используйте этот аргумент для их разблокировки. |
| `--version` | Показать текущую версию. |
| `--help` | Показать эту справку. |


## Поддержка хранилища S3

`manticore-backup` поддерживает сохранение и восстановление резервных копий напрямую в/из S3-совместимого хранилища, включая AWS S3, MinIO, Wasabi, Cloudflare R2 и другие. Просто передайте URL-адрес `s3://bucket/prefix` в качестве `--backup-dir`.

### Конфигурация

Установите следующие переменные окружения перед запуском `manticore-backup`:

| Переменная | Обязательно | Описание |
|----------|----------|-------------|
| `AWS_ACCESS_KEY_ID` | Да | Ключ доступа AWS (или `AWS_ACCESS_KEY`) |
| `AWS_SECRET_ACCESS_KEY` | Да | Секретный ключ AWS (или `AWS_SECRET_KEY`) |
| `AWS_REGION` | Нет | Регион AWS (по умолчанию: `us-east-1`) |
| `AWS_ENDPOINT_URL` | Нет | Пользовательская S3-совместимая конечная точка — **только URL сервера, без имени бакета** (например, `http://localhost:9000`) |
| `AWS_S3_ENCRYPTION` | Нет | Включить шифрование на стороне сервера SSE-S3 (по умолчанию: `1` для AWS S3; установите `0` для MinIO, R2 или других пользовательских конечных точек) |

> ⚠️ `AWS_ENDPOINT_URL` не должен включать имя бакета. Бакет берётся из аргумента `s3://bucket/prefix`. Включение бакета в URL конечной точки приводит к его дублированию в каждом запросе и вызывает ошибки.
>
> ```
> # Неправильно — бакет "mybucket" продублирован в пути URL
> AWS_ENDPOINT_URL=https://account.r2.cloudflarestorage.com/mybucket
>
> # Правильно — конечная точка это только сервер
> AWS_ENDPOINT_URL=https://account.r2.cloudflarestorage.com
> ```

### Примеры использования

```bash
# Backup to AWS S3 (SSE-S3 encryption enabled by default)
export AWS_ACCESS_KEY_ID=your_key
export AWS_SECRET_ACCESS_KEY=your_secret
manticore-backup --backup-dir=s3://my-bucket/backups

# Restore from S3
manticore-backup --restore --backup-dir=s3://my-bucket/backups
manticore-backup --restore=backup-20221004171839 --backup-dir=s3://my-bucket/backups

# Use with MinIO (disable encryption)
export AWS_ACCESS_KEY_ID=minioadmin
export AWS_SECRET_ACCESS_KEY=minioadmin
export AWS_ENDPOINT_URL=http://localhost:9000
export AWS_S3_ENCRYPTION=0
manticore-backup --backup-dir=s3://my-bucket/backups

# Use with Cloudflare R2
export AWS_ACCESS_KEY_ID=your_r2_access_key
export AWS_SECRET_ACCESS_KEY=your_r2_secret_key
export AWS_ENDPOINT_URL=https://<account_id>.r2.cloudflarestorage.com
export AWS_REGION=auto
export AWS_S3_ENCRYPTION=0
manticore-backup --backup-dir=s3://my-bucket/backups
```

### Необходимые разрешения S3

Для резервного копирования требуется `s3:PutObject`, для восстановления — `s3:GetObject`, а для вывода списка доступных точек восстановления — `s3:ListBucket`.

## Команда SQL BACKUP

Вы также можете делать резервное копирование данных через SQL, выполнив простую команду `BACKUP TO /path/to/backup`.

> ПРИМЕЧАНИЕ: `BACKUP` не поддерживается в Windows. Рассмотрите использование [mysqldump](../Securing_and_compacting_a_table/Backup_and_restore.md#Backup-and-restore-with-mysqldump) вместо этого.

> ПРИМЕЧАНИЕ: `BACKUP` требует [Manticore Buddy](../Installation/Manticore_Buddy.md). Если не работает, убедитесь, что Buddy установлен.

### Общий синтаксис BACKUP

```sql
BACKUP
  [{TABLE | TABLES} a[, b]]
  TO path_to_backup
  [{OPTION | OPTIONS}
    async = {on | off | 1 | 0 | true | false | yes | no}
    [, compress = {on | off | 1 | 0 | true | false | yes | no}]
  ]
```

Например, чтобы сделать резервную копию таблиц `a` и `b` в каталог `/backup`, выполните следующую команду:

```sql
BACKUP TABLES a, b TO /backup
```

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

* `async`: делает резервное копирование неблокирующим, позволяя сразу получить ответ с путем резервной копии и выполнять другие запросы во время выполнения резервного копирования. Значение по умолчанию — `0`.
* `compress`: включает сжатие файлов с помощью zstd. Значение по умолчанию — `0`.

Например, чтобы выполнить резервное копирование всех таблиц в асинхронном режиме с включенным сжатием в каталог `/tmp`:

```sql
BACKUP TO /tmp OPTION async = yes, compress = yes
```

### Поведение асинхронного резервного копирования

При использовании `async = 1` (или `yes`, `on`, `true`) операция резервного копирования запускается в фоновом задании:

* Команда возвращается сразу с путем к резервной копии
* Вы можете продолжать выполнять другие запросы во время резервного копирования
* Задача резервного копирования выполняется в отдельном потоке, управляемом Manticore Buddy
* Во время выполнения задача будет отображаться в выводе `SHOW QUERIES` и автоматически исчезнет после завершения

**Пример асинхронного резервного копирования:**

```sql
BACKUP TO /tmp/mybackup OPTION async = 1
```

Это вернет сразу вывод, например:
```
+----------------------------------+
| Path                             |
+----------------------------------+
| /tmp/mybackup/backup-20221004... |
+----------------------------------+
```

Вы можете проверить, выполняется ли резервное копирование, используя `SHOW QUERIES`. После завершения задача исчезнет из списка запросов, а все файлы резервной копии будут присутствовать в указанном каталоге.

### Важные моменты

1. Путь к резервной копии может содержать пробелы, если заключен в одинарные кавычки, например, `BACKUP TO '/path/with spaces'`
2. Пути без пробелов кавычки не требуют: `BACKUP TO /tmp/backup`
3. Поддерживаются пути Windows: `BACKUP TO 'C:\path'` или `BACKUP TO C:\windows\backup`
4. Убедитесь, что Manticore Buddy запущен (по умолчанию запущен)
5. Каталог резервной копии должен существовать и быть доступным для записи процессом Manticore

### Как резервное копирование поддерживает целостность таблиц

Чтобы обеспечить целостность таблиц во время резервного копирования, инструменты резервного копирования Manticore Search используют инновационные команды [FREEZE и UNFREEZE](../Securing_and_compacting_a_table/Freezing_and_locking_a_table.md). В отличие от традиционной функции блокировки таблиц в MySQL, `FREEZE` останавливает сброс данных на диск, при этом позволяя записывать (в некоторой степени) и выбирать обновленные данные из таблицы.

Однако, если размер чанка в оперативной памяти превышает порог `rt_mem_limit` во время длительных операций резервного копирования с большим количеством вставок, данные могут быть сброшены на диск, и операции записи будут заблокированы до завершения сброса. Несмотря на это, инструмент поддерживает баланс между блокировкой таблиц, целостностью данных и доступностью записи в базу данных во время заморозки таблиц.

Когда вы используете `manticore-backup` или SQL-команду `BACKUP`, команда `FREEZE` выполняется один раз и замораживает все таблицы, которые вы копируете, одновременно. Процесс резервного копирования затем последовательно копирует каждую таблицу, снимая заморозку после успешного бэкапа каждой таблицы.

Если резервное копирование не удается или прерывается, инструмент пытается разморозить все таблицы.

## Восстановление с помощью инструмента manticore-backup

<!-- example restore_list -->
Для восстановления экземпляра Manticore из резервной копии используйте команду `manticore-backup` с аргументами `--backup-dir` и `--restore`. Например: `manticore-backup --backup-dir=/path/to/backups --restore`. Если не указать аргумент для `--restore`, просто будет выведен список всех резервных копий в `--backup-dir`.

<!-- request Example -->
```bash
manticore-backup --backup-dir=/mnt/backup/ --restore
```

<!-- response Example -->

```bash
Copyright (c) 2023-2024, Manticore Software LTD (https://manticoresearch.com)

Manticore config file:
Backup dir: /tmp/

Available backups: 3
  backup-20221006144635 (Oct 06 2022 14:46:35)
  backup-20221006145233 (Oct 06 2022 14:52:33)
  backup-20221007104044 (Oct 07 2022 10:40:44)
```

<!-- end -->

<!-- example restore -->

Чтобы начать задачу восстановления, запустите `manticore-backup` с флагом `--restore=имя_резервной_копии`, где `имя_резервной_копии` — это имя директории резервной копии внутри `--backup-dir`. Обратите внимание, что:
1. На том же хосте и порту, на который происходит восстановление, не должно запускаться ни одного экземпляра Manticore.
2. Старый файл `manticore.json` не должен существовать.
3. Старый конфигурационный файл не должен существовать.
4. Старая директория данных должна существовать и быть пустой.

Если все условия выполнены, восстановление продолжится. Инструмент предоставит подсказки, чтобы вам не нужно было их запоминать. Крайне важно избежать перезаписи существующих файлов, поэтому убедитесь, что удалили их до восстановления, если они ещё существуют. Отсюда и все условия.

<!-- request Example -->
```bash
manticore-backup --backup-dir=/mnt/backup/ --restore=backup-20221007104044
```

<!-- response Example -->

```bash
Copyright (c) 2023-2024, Manticore Software LTD (https://manticoresearch.com)

Manticore config file:
Backup dir: /tmp/
2022-10-07 11:17:25 [Info] Starting to restore...

Manticore config
  endpoint =  127.0.0.1:9308
2022-10-07 11:17:25 [Info] Restoring config files...
2022-10-07 11:17:25 [Info]   config files - OK
2022-10-07 11:17:25 [Info] Restoring state files...
2022-10-07 11:17:25 [Info]   config files - OK
2022-10-07 11:17:25 [Info] Restoring data files...
2022-10-07 11:17:25 [Info]   config files - OK
2022-10-07 11:17:25 [Info] The backup '/tmp/backup-20221007104044' was successfully restored.
2022-10-07 11:17:25 [Info] Elapsed time: 0.02s
2022-10-07 11:17:25 [Info] Done
```

<!-- end -->

## Резервное копирование и восстановление с помощью mysqldump

Manticore поддерживает утилиту `mysqldump` из MySQL до версии 26.7 и утилиту `mariadb-dump` из MariaDB до версии 12.3.

<!-- example mysqldump_backup -->

> ПРИМЕЧАНИЕ: некоторые версии `mysqldump` / `mariadb-dump` требуют [Manticore Buddy](../Installation/Manticore_Buddy.md). Если дамп не работает, убедитесь, что Buddy установлен.

Для создания резервной копии вашей базы данных Manticore Search вы можете использовать команду `mysqldump`. В примерах мы будем использовать порт и хост по умолчанию.

Обратите внимание, что `mysqldump` поддерживается только для таблиц с режимом реального времени.

<!-- request Basic -->
```bash
mysqldump -h0 -P9306 manticore > manticore_backup.sql
mariadb-dump -h0 -P9306 manticore > manticore_backup.sql
```

Выполнение этой команды создаст файл резервной копии с именем `manticore_backup.sql`. Этот файл будет содержать все данные и схемы таблиц.

<!-- request Replace mode -->
```bash
mysqldump -h0 -P9306 --replace --net-buffer-length=16m -etc manticore tbl > tbl.sql
```

Это создаст файл резервной копии `tbl.sql` с командами `replace` вместо `insert`, при этом имена столбцов сохраняются в каждой партии. Документы будут разбиваться на партии размером до 16 мегабайт. Команд `drop`/`create table` не будет. Это полезно для полной текстовой переиндексации после изменения настроек токенизации.

<!-- request Replication mode -->
```bash
mysqldump -etc --replace -h0 -P9306 -ucluster manticore --skip-lock-tables cluster:tbl | mysql -P9306 -h0
mariadb-dump -etc --replace -h0 -P9306 -ucluster manticore --skip-lock-tables cluster:tbl | mysql -P9306 -h0
```

В этом случае `mysqldump` сгенерирует команды вида `REPLACE INTO cluster:table ...`, которые будут напрямую отправлены в экземпляр Manticore, в результате чего документы будут повторно вставлены.
Используйте пользователя `cluster` и флаг `-t` для включения режима репликации. Подробнее см. в примечаниях ниже.

<!-- end -->

Чтобы применить изменённые настройки полнотекстового поиска к существующим документам, см. [Переиндексация существующих документов после изменения настроек FT](../Updating_table_schema_and_settings.md#Reindexing-existing-documents-after-changing-FT-settings).

При прямой передаче дампа в `mysql` для переиндексации той же таблицы требуется `--skip-lock-tables`. При экспорте в файл и последующем воспроизведении после выхода `mysqldump` это не требуется.

<!-- example mysqldump_restore -->
### Восстановление

Если вы хотите восстановить базу данных Manticore Search из файла резервной копии, клиент mysql — ваш инструмент.

Обратите внимание, если вы восстанавливаете в [Plain режиме](../Read_this_first.md#Real-time-mode-vs-plain-mode), вы не можете напрямую удалять и создавать таблицы. Поэтому следует:
- Использовать `mysqldump` с опцией `-t`, чтобы исключить команды `CREATE TABLE` из резервной копии.
- Вручную [TRUNCATE](../Emptying_a_table.md) таблицы перед восстановлением.

<!-- request SQL -->
```bash
mysql -h0 -P9306 < manticore_backup.sql
mariadb -h0 -P9306 < manticore_backup.sql
```

Эта команда позволяет восстановить всё из файла `manticore_backup.sql`.
<!-- end -->

### Дополнительные параметры

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

- `-t` пропускает команды `drop`/`create` таблицы. Используйте его при переиндексации таблицы после изменения настроек полнотекстового поиска.
- `--no-data`: Эта настройка исключает данные таблиц из резервной копии, результатом будет файл, содержащий только схемы таблиц.
- `--ignore-table=[database_name].[table_name]`: Эта опция позволяет исключить конкретную таблицу из операции резервного копирования. Обратите внимание, что имя базы данных должно быть `manticore`.
- `--replace` выполняет `replace` вместо `insert`. Используйте его при переиндексации таблицы после изменения настроек полнотекстового поиска.
- `--net-buffer-length=16M` для формирования партий размером до 16 мегабайт для более быстрой реставрации.
- `-e` для группировки документов в батчи. Полезно для более быстрой реставрации.
- `-c` для сохранения имён столбцов. Полезно для переиндексации таблицы после изменения её схемы (например, изменения порядка полей).

Для полного списка параметров и их подробного описания обратитесь к официальной [документации MySQL](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) или [документации MariaDB](https://mariadb.com/kb/en/mariadb-dump/).

### Примечания

* Чтобы создать дамп в режиме репликации (где дамп включает `INSERT/REPLACE INTO <cluster_name>:<table_name>`):
  - Убедитесь, что таблица не меняется во время создания дампа.
  - Используйте пользователя `cluster`. Например: `mysqldump -u cluster ...` или `mariadb-dump -u cluster ...`. Имя пользователя, запускающего режим репликации для `mysqldump`, можно изменить командой `SET GLOBAL cluster_user = new_name`.
  - Используйте флаг `-t`.
  - Используйте флаг `--skip-lock-tables`.
  - При указании таблицы в режиме репликации необходимо использовать синтаксис `cluster_name:table_name`. Например: `mysqldump -P9306 -h0 -t -ucluster manticore cluster:tbl`.
* Рекомендуется явно указывать базу данных `manticore` при резервном копировании всех баз, вместо использования опции `--all-databases`.
* Обратите внимание, что `mysqldump` не поддерживает резервное копирование распределённых таблиц и не может резервировать таблицы, содержащие ненакопленные (non-stored) поля. В таких случаях рассмотрите возможность использования `manticore-backup` или SQL-команды `BACKUP`. Если у вас есть распределённые таблицы, рекомендуется всегда указывать таблицы, которые нужно сохранить.

<!-- proofread -->
