Перейти к содержимому
Последнее обновление

Управление метаданными и их обслуживание

warning

Не используйте metadata_failure_recovery без крайней необходимости. Его использование может привести к усечению и потере метаданных, а также к split-brain. Действуйте осторожно, чтобы ошибочные операции не привели к необратимому повреждению данных.

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

Сначала прочитайте документ об устройстве метаданных Doris, чтобы понять, как работают метаданные Doris.

Важные рекомендации​

  • Текущая архитектура метаданных не обеспечивает обратной совместимости. То есть, если в новой версии изменилась структура метаданных (это можно определить по появлению новой VERSION в файле FeMetaVersion.java в коде FE), после обновления обычно невозможно вернуться к старой версии. Поэтому перед обновлением FE обязательно проверьте совместимость метаданных, выполнив действия из документа по обновлению.

Структура каталога метаданных (Catalog)​

Предположим, что в fe.conf для meta_dir указан путь path/to/doris-meta. В нормально работающем кластере Doris структура каталога метаданных должна выглядеть следующим образом:

/path/to/doris-meta/
            |-- bdb/
            |   |-- 00000000.jdb
            |   |-- je.config.csv
            |   |-- je.info.0
            |   |-- je.info.0.lck
            |   |-- je.lck
            |   `-- je.stat.csv
            `-- image/
                |-- ROLE
                |-- VERSION
                `-- image.xxxx

  1. bdb

    Для хранения журнала метаданных мы используем bdbje как распределённое хранилище «ключ-значение». Этот каталог BDB соответствует «каталогу данных» bdbje.

    Файлы с расширением .jdb содержат данные bdbje. Их объём растёт по мере увеличения количества записей в журнале метаданных. Когда Doris завершает очередное создание образа, старые записи журнала удаляются. Поэтому обычно общий объём этих файлов составляет от нескольких МБ до нескольких ГБ в зависимости от использования Doris, например от частоты импорта. Если общий объём файлов данных превышает 10 ГБ, стоит проверить, не произошёл ли сбой создания образа и не остались ли старые записи журнала из-за ошибки распространения образа.

    je.info.0 содержит журнал работы bdbje. Время в этом журнале указано в часовом поясе UTC + 0. По этому журналу также можно понять некоторые особенности работы bdbje.

  2. Каталог image

    Каталог image используется для хранения образов метаданных, которые Doris регулярно создаёт. Обычно в нём находится файл образа image.xxxxx, где xxxxx является числом. Это число означает, что образ содержит все записи журнала метаданных до xxxx. Время создания этого файла, которое можно посмотреть с помощью ls -al, обычно соответствует времени создания образа.

    В каталоге также может находиться файл image.ckpt. Это образ метаданных, который ещё создаётся. Команда du -sh должна показывать увеличение размера файла: это означает, что содержимое образа записывается в файл. После завершения записи файл автоматически переименовывается в новый image.xxxxx и заменяет старый файл образа.

    Только FE с ролью Master регулярно создаёт файлы образов. После каждого создания этот FE отправляет образ остальным FE с другими ролями. Когда подтверждено, что все остальные FE получили образ, Master FE удаляет журнал метаданных из bdbje. Поэтому при сбое создания образа или его отправки другим FE данные в bdbje будут накапливаться.

    Текстовый файл ROLE содержит тип FE: FOLLOWER или OBSERVER.

    Текстовый файл VERSION содержит идентификатор кластера Doris и токен, используемый для аутентификации доступа между узлами.

    Файлы ROLE и VERSION должны либо присутствовать одновременно, либо одновременно отсутствовать, например при первом запуске.

Основные операции​

Запуск одного узла FE​

Развёртывание с одним узлом FE является базовым вариантом. Для полноценного кластера Doris требуется хотя бы один узел FE. Если узел FE только один, его типом будет Follower, а ролью будет Master.

  1. Первый запуск

    1. Предположим, что в fe.conf для meta_dir указан путь path/to/doris-meta.

    2. Убедитесь, что каталог path/to/doris-meta уже существует, имеет правильные права доступа и пуст.

    3. Запустите FE командой bash bin/start_fe.sh --daemon.

    4. После запуска в fe.log должны появиться следующие сообщения:

      • Palo FE starting...
      • image does not exist: /path/to/doris-meta/image/image.0
      • transfer from INIT to UNKNOWN
      • transfer from UNKNOWN to MASTER
      • the very first time to open bdb, dbname is 1
      • start fencing, epoch number is 1
      • finish replay in xxx msec
      • QE service start
      • thrift server started

      Порядок сообщений может отличаться, но их содержание должно быть примерно таким.

    5. При первом запуске одного узла FE обычно не возникает проблем. Если приведённые выше сообщения не появились, скорее всего, вы не полностью выполнили описанные действия. Внимательно перечитайте соответствующую статью Wiki.

  2. Перезапуск

    1. Остановленные узлы FE можно запустить снова командой bash bin/start_fe.sh.

    2. После перезапуска в fe.log должны появиться следующие сообщения:

      • Palo FE starting...

      • finished to get cluster id: xxxx, role: FOLLOWER and node name: xxxx

      • Если до перезапуска образ ещё не создавался, появится следующее сообщение:

      • image does not exist: /path/to/doris-meta/image/image.0

      • Если до перезапуска образ уже был создан, появятся следующие сообщения:

      • start load image from /path/to/doris-meta/image/image.xxx. is ckpt: false

      • finished load image in xxx ms

      • transfer from INIT to UNKNOWN

      • replayed journal id is xxxx, replay to journal id is yyyy

      • transfer from UNKNOWN to MASTER

      • finish replay in xxx msec

      • master finish replay journal, can write now.

      • begin to generate new image: image.xxxx

      • start save image to /path/to/doris-meta/image/image.ckpt. is ckpt: true

      • finished save image /path/to/doris-meta/image/image.ckpt in xxx ms. checksum is xxxx

      • push image.xxx to other nodes. totally xx nodes, push succeeded xx nodes

      • QE service start

      • thrift server started

      Порядок сообщений может отличаться, но их содержание должно быть примерно таким.

  3. Распространённые проблемы

    При развёртывании с одним узлом FE запуск и остановка обычно не вызывают проблем. Если возникли вопросы, обратитесь к соответствующей статье Wiki и внимательно проверьте последовательность своих действий.

Добавление FE​

Процесс добавления FE подробно описан в документации по эластичному масштабированию, поэтому здесь он не повторяется. Ниже приведены рекомендации и распространённые проблемы.

  1. Примечания

    • Перед добавлением нового FE убедитесь, что текущий Master FE работает нормально: подключение доступно, JVM работает штатно, образы создаются. Также проверьте, не слишком ли велик каталог данных bdbje, и т. д.
    • При первом запуске нового FE обязательно укажите параметр --helper, направив его на Master FE. При перезапуске добавлять --helper не требуется. (Если указан --helper, FE напрямую запрашивает свою роль у вспомогательного узла. В противном случае FE пытается получить информацию из файлов ROLE и VERSION в каталоге doris-meta/image/.
    • При первом запуске нового FE убедитесь, что его каталог meta_dir создан, имеет правильные права доступа и пуст.
    • Запуск нового FE и выполнение оператора ALTER SYSTEM ADD FOLLOWER/OBSERVER, добавляющего FE в метаданные, можно выполнять в любом порядке. Если сначала запустить новый FE, не выполнив оператор, в журнале нового FE появится сообщение current node is not added to the group. Please add it first.. После выполнения оператора процесс продолжится в штатном режиме.
    • Добавляйте следующий FE только после успешного добавления предыдущего.
    • Подключитесь к MASTER FE и выполните оператор ALTER SYSTEM ADD FOLLOWER/OBSERVER.

  2. Распространённые проблемы

    1. Узел находится в состоянии DETACHED

      При первом запуске добавляемого FE, если объём данных в doris-meta/bdb на Master FE велик, в журнале добавляемого FE может появиться сообщение this node is DETACHED. В этот момент bdbje копирует данные, и размер каталога bdb/ добавляемого FE увеличивается. Обычно этот процесс занимает несколько минут в зависимости от объёма данных в bdbje. Позже в fe.log могут появиться трассировки ошибок, связанных с bdbje. Если в конце журнала появились сообщения QE service start и thrift server start, запуск обычно завершился успешно. Попробуйте подключиться к этому FE через mysql-client. Если этих сообщений нет, причиной может быть тайм-аут репликации журнала bdbje. В таком случае обычный перезапуск FE чаще всего решает проблему.

    2. Ошибки добавления по разным причинам

      • При добавлении OBSERVER следует учитывать, что FE типа OBSERVER не участвует в записи метаданных большинством узлов и теоретически может запускаться и останавливаться в любое время. Поэтому при неудачном добавлении OBSERVER можно принудительно завершить процесс OBSERVER FE, очистить его каталог метаданных и добавить процесс снова.

      • При добавлении FOLLOWER следует учитывать, что он участвует в записи метаданных большинством узлов. Поэтому FOLLOWER уже мог присоединиться к группе выборов bdbje. Если узлов FOLLOWER всего два, включая MASTER, остановка одного FE может привести к завершению другого FE из-за невозможности выполнить запись большинством узлов. В таком случае сначала удалите новый узел FOLLOWER из метаданных командой ALTER SYSTEM DROP FOLLOWER, затем принудительно завершите процесс FOLLOWER, очистите метаданные и добавьте процесс снова.

Удаление FE​

FE соответствующего типа можно удалить командой ALTER SYSTEM DROP FOLLOWER/OBSERVER. Учитывайте следующие моменты:

  • Для FE типа OBSERVER достаточно выполнить DROP, это не несёт риска.

  • Для FE типа FOLLOWER сначала убедитесь, что перед началом удаления количество узлов FOLLOWER нечётное: три или более.

    1. Если удаляется FE с ролью, отличной от MASTER, рекомендуется подключиться к MASTER FE, выполнить команду DROP, а затем принудительно завершить процесс.
    2. Если требуется удалить MASTER FE, сначала убедитесь, что количество FOLLOWER FE нечётное (odd) и все они работают нормально (and it works properly). Затем сначала принудительно завершите процесс MASTER FE. После этого один из FE будет избран MASTER. Убедившись, что оставшиеся FE работают нормально, подключитесь к новому MASTER FE и выполните команду DROP, чтобы удалить старый MASTER FE.

Расширенные операции​

Режим восстановления метаданных FE​

Неправильное использование metadata recovery mode или ошибочные действия в этом режиме могут привести к необратимому повреждению данных в производственной среде. Поэтому документация по работе с metadata recovery mode больше не предоставляется. Если такой режим действительно необходим, обратитесь за помощью к разработчикам сообщества Doris.

Изменение типа FE​

Если требуется изменить тип существующего FE с FOLLOWER/OBSERVER на OBSERVER/FOLLOWER, удалите FE описанным выше способом, а затем добавьте FE нужного типа.

Перенос FE​

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

  1. Перенос FOLLOWER или OBSERVER с узлов, не являющихся MASTER

    Сначала добавьте новый FOLLOWER / OBSERVER, затем удалите старый FOLLOWER / OBSERVER.

  2. Перенос единственного узла MASTER

    Если вы разработчик, можно выполнить операции с помощью metadata recovery mode. Пользователям, однако, не рекомендуется использовать metadata recovery mode. Вместо этого рекомендуется заново развернуть среду и перенести данные с помощью внешних таблиц.

  3. Перенос группы FOLLOWER с одной группы узлов на другую группу новых узлов

    Разверните FE на новом узле и сначала добавьте новый узел как FOLLOWER. Старые узлы можно удалять командой DROP по одному. В процессе последовательного удаления MASTER автоматически выбирается среди новых узлов FOLLOWER.

Изменение портов FE​

В настоящее время FE использует следующие порты:

  • Ed_log_port: порт связи bdbje
  • http_port: порт http, также используемый для отправки образов
  • rpc_port: порт сервера thrift компонента Frontend
  • query_port: порт подключения Mysql
  • arrow_flight_sql_port: порт подключения Arrow Flight SQL

  1. edit_log_port

    Если требуется изменить этот порт при развёртывании с несколькими узлами FE, можно удалить старый узел и добавить новый, выполнив действия по управлению узлами. Если узел только один, его можно перенести в соответствии с разделом «Перенос единственного узла MASTER» выше.

  2. http_port

    Значение http_port должно быть одинаковым на всех FE. Поэтому для изменения этого порта нужно остановить все FE, изменить настройки и затем одновременно запустить их снова.

  3. rpc_port

    После изменения конфигурации перезапустите FE. Master FE сообщит BE новый порт через heartbeat. Используется только этот порт Master FE. Тем не менее рекомендуется указывать одинаковые порты на всех FE.

  4. query_port

    После изменения конфигурации перезапустите FE. Это влияет только на адрес подключения mysql.

  5. arrow_flight_sql_port

    После изменения конфигурации перезапустите FE. Это влияет только на адрес подключения к серверу arrow flight sql.

Просмотр данных в BDBJE (только для отладки)​

Журнал метаданных FE хранится в BDBJE в формате «ключ-значение». В некоторых нештатных ситуациях FE может не запускаться из-за ошибок метаданных. Для таких случаев Doris предоставляет способ просмотра данных, хранящихся в BDBJE, чтобы упростить поиск неисправностей.

Сначала добавьте в fe.conf настройку enable_bdbje_debug_mode=true, затем запустите FE командой bash start_fe.sh --daemon.

FE перейдёт в режим отладки: запустит только сервер http и сервер MySQL, откроет экземпляр BDBJE, но не будет загружать метаданные и выполнять последующие этапы запуска.

В этом режиме данные BDBJE можно просматривать на веб-странице FE либо, подключившись к Doris через клиент MySQL, с помощью show proc "/bdbje";.

mysql> show proc "/bdbje";
+----------+---------------+---------+
| DbNames  | JournalNumber | Comment |
+----------+---------------+---------+
| 110589   | 4273          |         |
| epochDB  | 4             |         |
| metricDB | 430694        |         |
+----------+---------------+---------+

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

mysql> show proc "/bdbje/110589";
+-----------+
| JournalId |
+-----------+
| 1         |
| 2         |

...
| 114858    |
| 114859    |
| 114860    |
| 114861    |
+-----------+
4273 rows in set (0.06 sec)

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

mysql> show proc "/bdbje/110589/114861";
+-----------+--------------+---------------------------------------------+
| JournalId | OpType       | Data                                        |
+-----------+--------------+---------------------------------------------+
| 114861    | OP_HEARTBEAT | org.apache.doris.persist.HbPackage@6583d5fb |
+-----------+--------------+---------------------------------------------+
1 row in set (0.05 sec)

На третьем уровне можно посмотреть значение указанного ключа.

Рекомендуемые практики​

Рекомендации по развёртыванию FE приведены в документе по установке и развёртыванию. Ниже приведены дополнения.

  • В производственной среде развёртывайте нечётное количество FOLLOWER FE (обычно 3: 1 MASTER + 2 FOLLOWER), чтобы обеспечить высокую доступность записи метаданных. FOLLOWER участвуют в выборах лидера и записи большинством узлов; при отказе Master оставшиеся FOLLOWER выбирают нового Master. OBSERVER не участвуют в выборах: они только синхронизируют метаданные и используются для увеличения пропускной способности FE при чтении. Для тестирования или разработки допустим один FOLLOWER.

  • Запись большинством узлов означает, что запись журнала фиксируется только после её сохранения на большинстве FOLLOWER. При наличии 3 FOLLOWER допускается отказ одного узла; если остаётся только один FOLLOWER, он не может продолжать запись метаданных. Это ожидаемое поведение, а не причина отказываться от развёртывания с 3 FOLLOWER. Синхронизируйте часы FOLLOWER, выделяйте достаточно памяти для JVM FE и не останавливайте большинство FOLLOWER одновременно.

  • Для JVM процесса FE необходимо выделить достаточно памяти. Мы настоятельно рекомендуем выделять JVM FE не менее 10 ГБ, а предпочтительно от 32 ГБ до 64 ГБ. Также настройте мониторинг использования памяти JVM. При возникновении OOM в FE запись метаданных может завершиться ошибкой и привести к сбоям, после которых восстановление невозможно!

  • На узлах FE должно быть достаточно дискового пространства, чтобы рост объёма метаданных не привёл к его нехватке. Учитывайте также, что журналы FE занимают более десятка гигабайт дискового пространства.

Другие распространённые проблемы​

  1. В fe.log появляется сообщение meta out of date. current time: xxx, synchronized time: xxx, has log: xxx, fe type: xxx

    Обычно это происходит потому, что FE не может выбрать Master. Например, если настроены три FOLLOWER, но запущен только один, на нём возникнет эта проблема. Обычно достаточно одновременно перезапустить все FOLLOWER. Если после запуска проблема сохраняется, необходимо проверить, нет ли другой, пока не установленной причины.

  2. Clock delta: xxxx ms. between Feeder: xxxx and this Replica exceeds max permissible delta: xxxx ms.

    Bdbje требует, чтобы расхождение часов между узлами не превышало определённый порог. При его превышении узел аварийно завершает работу. По умолчанию порог составляет 5000 мс и задаётся параметром FE `max_bdbje_clock_delta_ms', который можно изменить при необходимости. Однако мы рекомендуем использовать NTP или другие средства синхронизации часов, чтобы обеспечить согласованность времени на хостах кластера Doris.

  3. Файлы образов в каталоге image/ давно не обновлялись

    По умолчанию Master FE создаёт файл образа после каждых 50,000 записей журнала метаданных. В активно используемом кластере новый файл образа обычно создаётся с интервалом от половины суток до нескольких дней. Если файл образа давно не обновлялся, например более недели, последовательно проверьте следующие возможные причины:

    1. Найдите сообщение memory is not enough to do checkpoint. Committed memory XXXX Bytes, used memory XXXX Bytes. в fe.log узла Master FE. Его наличие означает, что текущей JVM FE недостаточно памяти для создания образа: обычно для этого требуется резервировать половину памяти FE. В таком случае увеличьте объём памяти JVM, перезапустите FE и проверьте результат. При каждом перезапуске Master FE сразу создаётся новый образ. Такой перезапуск также можно использовать для принудительного создания новых образов. Обратите внимание: при развёртывании с несколькими FOLLOWER после перезапуска текущего Master FE другой FOLLOWER FE станет MASTER, и последующее создание образов будет выполнять новый Master. Поэтому может потребоваться изменить настройки памяти JVM всех FOLLOWER FE.

    2. Найдите сообщение begin to generate new image: image.xxxx в fe.log узла Master FE. Если оно есть, создание образа началось. Проверьте последующие сообщения этого потока: сообщение checkpoint finished save image.xxxx означает, что образ успешно записан. Сообщение Exception when generating new image file означает сбой создания; для выяснения причины изучите конкретные сообщения об ошибках.

  4. Размер каталога bdb/ очень велик и достигает нескольких гигабайт или более.

    После устранения ошибки, мешающей созданию нового образа, каталог BDB некоторое время может оставаться большим. Возможно, Master FE не удалось отправить образ. Найдите сообщение push image.XXXX to other nodes. totally XX nodes, push succeeded YY nodes в fe.log узла Master FE. Если YY меньше xx, образ был успешно отправлен не всем FE. Конкретную ошибку можно найти в сообщении Exception when pushing image file.url = xxx в fe.log.

    Также можно добавить в файл конфигурации FE настройку edit_log_roll_num = xxxx. Этот параметр задаёт количество записей журнала метаданных, после которого создаётся образ. Значение по умолчанию составляет 50000. Его можно уменьшить, чтобы образы создавались чаще и старые записи журнала удалялись быстрее.

  5. FOLLOWER FE завершают работу один за другим

    Метаданные Doris записываются большинством узлов: запись журнала метаданных считается успешной только после её сохранения на достаточном количестве FOLLOWER FE. Например, при наличии трёх FOLLOWER запись должна успешно сохраниться на двух. При сбое записи процесс FE самостоятельно завершает работу. Предположим, есть три FOLLOWER: A, B и C. Если сначала завершит работу C, а затем B, то A тоже завершит работу. Это ожидаемое поведение при записи большинством узлов. В производственной среде по-прежнему следует развёртывать 3 FOLLOWER; не останавливайте большинство FOLLOWER одновременно. Если работающим остался только один FOLLOWER, сначала восстановите остальные FOLLOWER и запустите их вместе, а не запускайте только оставшийся узел. Иначе может появиться сообщение meta out of date, описанное в пункте 1.

  6. В fe.log появляется сообщение get exception when try to close previously opened bdb database. ignore it

    Если в конце сообщения есть слова ignore it, обычно никаких действий не требуется. При желании можно найти эту ошибку в BDBEnvironment.java и прочитать комментарии.

  7. В выводе show frontends; значение Join для FE равно true, но на самом деле FE работает некорректно.

    Команда show frontends; позволяет посмотреть информацию в столбце Join. Значение true означает лишь, что FE присоединился к кластеру. Оно не означает, что FE по-прежнему нормально работает в кластере. Значение false означает, что FE никогда не присоединялся к кластеру.

  8. Настройка параметров FE master_sync_policy, replica_sync_policy и txn_rollback_limit.

    Параметры master_sync_policy и replica_sync_policy управляют вызовами fsync (): первый определяет, вызывается ли fsync () при записи журнала метаданных узлом Leader FE, а replica_sync_policy определяет, вызывают ли остальные Follower FE fsync () при синхронизации метаданных в конфигурации FE HA. В ранних версиях Doris значением по умолчанию для обоих параметров было WRITE_NO_SYNC, то есть fsync () не вызывался. В последней версии Doris значение по умолчанию изменено на SYNC, то есть fsync () вызывается. Вызов fsync () значительно снижает производительность записи метаданных на диск. В некоторых средах IOPS может снизиться до нескольких сотен, а задержка увеличиться до 2-3 мс, хотя этого всё ещё достаточно для операций с метаданными Doris. Поэтому мы рекомендуем следующую конфигурацию:

    1. При развёртывании с одним Follower FE установите master_sync_policy в SYNC, чтобы предотвратить потерю метаданных при сбое системы FE.
    2. При развёртывании с несколькими Follower FE можно установить master_sync_policy и replica_sync_policy в WRITE_NO_SYNC, поскольку вероятность одновременного отказа нескольких систем считается очень низкой.

    Если при развёртывании с одним Follower FE параметр master_sync_policy установлен в WRITE_NO_SYNC, сбой системы FE может привести к потере метаданных. В таком случае при попытке перезапуска другого Observer FE может появиться ошибка:

    Node xxx must rollback xx total commits(numPassedDurableCommits of which were durable) to the earliest point indicated by transaction xxxx in order to rejoin the replication group, but the transaction rollback limit of xxx prohibits this.

Это означает, что некоторые уже сохранённые транзакции необходимо откатить, но количество записей превышает установленный предел. По умолчанию этот предел составляет 100; его можно изменить параметром txn_rollback_limit. Эта операция позволяет лишь попытаться запустить FE в штатном режиме, но не восстанавливает потерянные метаданные.

Report issue