Перейти к основному содержимому
Версия: 2.0.x

Shared-data

Этот раздел содержит ответы на часто задаваемые вопросы о shared-data cluster.

Почему не удаётся создать таблицу?​

Проверьте журнал BE (be.INFO), чтобы определить точную причину. Распространённые причины включают:

  • Неправильно настроенные параметры объектного хранилища (например, aws_s3_path, endpoint, authentication).
  • Нестабильность или исключения сервиса объектного хранилища.

Другие ошибки:

Сообщение об ошибке: "Error 1064 (HY000): Unexpected exception: Failed to create shards. INVALID_ARGUMENT: shard info cannot be empty"

Причина: Это часто происходит, когда используется автоматический вывод bucket, в то время как нет живых узлов CN или BE. Эта проблема исправлена в v1.5.2.

Почему создание таблицы занимает слишком много времени?​

Чрезмерное количество bucket (особенно в партиционированных таблицах) заставляет Selena создавать много tablet. Системе необходимо записать файл метаданных tablet для каждого tablet в объектное хранилище, высокая задержка которого может значительно увеличить общее время создания. Вы можете рассмотреть:

  • Уменьшение количества bucket.
  • Увеличение размера пула потоков создания tablet через конфигурацию BE create_tablet_worker_count.
  • Проверку и устранение высокой задержки записи в объектное хранилище.

Почему данные в объектном хранилище не очищаются после удаления таблицы?​

Selena поддерживает два режима DROP TABLE:

  • DROP TABLE xxx: перемещает метаданные таблицы в корзину FE (данные не удаляются).
  • DROP TABLE xxx FORCE: немедленно удаляет метаданные таблицы и данные.

Если очистка не удаётся, проверьте:

  • Использовался ли DROP TABLE xxx FORCE.
  • Не установлены ли слишком высокие параметры хранения в корзине. Параметры включают:
    • Конфигурация FE catalog_trash_expire_second
    • Конфигурация BE trash_file_expire_time_sec
  • Журналы FE на наличие ошибок удаления (например, таймаут RPC). Увеличьте таймаут RPC при необходимости.

Как найти путь хранения данных таблицы в объектном хранилище?​

Выполните следующую команду, чтобы получить путь хранения.

SHOW PROC '/dbs/<database_name>';

Пример:

mysql> SHOW PROC '/dbs/load_benchmark';
+---------+-------------+----------+---------------------+--------------+--------+--------------+--------------------------+--------------+---------------+--------------------------------------------------------------------------------------------------------------+
| TableId | TableName   | IndexNum | PartitionColumnName | PartitionNum | State  | Type         | LastConsistencyCheckTime | ReplicaCount | PartitionType | StoragePath                                                                                                  |
+---------+-------------+----------+---------------------+--------------+--------+--------------+--------------------------+--------------+---------------+--------------------------------------------------------------------------------------------------------------+
| 17152   | store_sales | 1        | NULL                | 1            | NORMAL | CLOUD_NATIVE | NULL                     | 64           | UNPARTITIONED | s3://selena-common/xxxxxxxxx-xxxx_load_benchmark-1699408425544/5ce4ee2c-98ba-470c-afb3-8d0bf4795e48/17152 |
+---------+-------------+----------+---------------------+--------------+--------+--------------+--------------------------+--------------+---------------+--------------------------------------------------------------------------------------------------------------+
1 row in set (0.18 sec)

В версиях ранее v1.5.2 данные таблицы рассредоточены в одном каталоге.

Начиная с версии v1.5.2 данные организованы по партициям. Та же команда отображает корневой путь таблицы, который теперь содержит подкаталоги, названные по Partition ID, и каждый каталог партиции содержит подкаталоги data/ (файлы данных сегментов) и meta/ (файлы метаданных tablet).

Почему запросы в shared-data cluster медленные?​

Распространённые причины включают:

  • Промах кэша.
  • Недостаточная компактификация, вызывающая слишком много мелких файлов сегментов и, следовательно, чрезмерный I/O.
  • Плохой параллелизм (например, слишком мало tablet).
  • Неправильные настройки datacache.partition_duration, вызывающие сбои кэширования.

Сначала вам нужно проанализировать Query Profile, чтобы определить основную причину.

Промах кэша​

В shared-data cluster данные хранятся удалённо, поэтому Data Cache имеет решающее значение. Если запросы становятся неожиданно медленными, проверьте метрики Query Profile, такие как CompressedBytesReadRemote и IOTimeRemote.

Промахи кэша могут быть вызваны:

  • Отключением Data Cache при создании таблицы.
  • Недостаточным локальным пространством для кэша.
  • Миграцией tablet из-за эластичного масштабирования.
  • Неправильными настройками datacache.partition_duration, предотвращающими кэширование.

Недостаточная компактификация​

Без адекватной компактификации остаётся много исторических версий данных, увеличивая количество файлов сегментов, к которым происходит доступ во время запросов. Это увеличивает I/O и замедляет запросы.

Вы можете диагностировать недостаточную компактификацию:

  • Проверяя Compaction Score для соответствующих партиций.

    Compaction Score должен оставаться ниже ~10. Чрезмерно высокие Compaction Score часто указывают на сбои компактификации.

  • Просматривая метрики Query Profile, такие как SegmentsReadCount.

    Если количество сегментов высокое, компактификация может отставать или застрять.

Неправильные настройки tablet​

Tablet распределяют данные по Compute Nodes. Плохой выбор bucket или смещённые ключи bucket могут привести к тому, что запросы будут выполняться только на подмножестве узлов.

Рекомендации:

  • Выбирайте столбцы bucket, обеспечивающие сбалансированное распределение.
  • Устанавливайте разумное количество bucket (формула: общий размер данных / (1–5 ГБ)).

Неправильные настройки datacache.partition_duration​

Если это значение установлено слишком маленьким, данные из "холодных" партиций могут не кэшироваться, вызывая повторные удалённые чтения. В Query Profile, если CompressedBytesReadRemote или IOCountRemote не равны нулю, это может быть причиной. Настройте datacache.partition_duration соответствующим образом.

Почему все запросы в warehouse завершаются таймаутом с ошибками типа "Timeout was reached" или "Deadline Exceeded"?​

Проверьте, могут ли Compute Nodes в warehouse получить доступ к endpoint объектного хранилища.

Как получить метаданные tablet в shared-data cluster?​

  1. Получите видимую версию, выполнив:

    SHOW PARTITIONS FROM <table_name>`

  2. Выполните следующий оператор для получения метаданных tablet:

    admin execute on <backend_id>
    'System.print(StorageEngine.get_lake_tablet_metadata_json(<tablet_id>, <version>))'

Почему загрузка медленная при высокочастотном приёме данных?​

Selena сериализует фиксацию транзакций, поэтому высокие скорости приёма могут достигать пределов.

Мониторьте следующие аспекты:

  • Очередь загрузки: Если очередь загрузки заполнена, вы можете увеличить количество потоков I/O worker.
  • Задержка Publish Version: Высокое время публикации вызывает задержки приёма.

Как работает компактификация в shared-data cluster и почему она застревает?​

Ключевые особенности поведения:

  • Компактификация планируется FE и выполняется CN.
  • Каждая компактификация создаёт новую версию и проходит через процесс Write, Commit и Publish.
  • FE не отслеживает задачи компактификации во время выполнения; устаревшие задачи на BE могут блокировать новые.

Для очистки застрявших задач компактификации выполните следующие шаги:

  1. Проверьте информацию о версии партиции и сравните CompactVersion и VisibleVersion.

    SHOW PARTITIONS FROM <table_name>

  2. Проверьте статус задачи компактификации.

    SHOW PROC '/compactions'
    SELECT * FROM information_schema.be_cloud_native_compactions WHERE TXN_ID = <TxnID>

  3. Отмените просроченные задачи.

    a. Отключите компактификацию и миграцию.

    ADMIN SET FRONTEND CONFIG ("lake_compaction_max_tasks" = "0");
    ADMIN SET FRONTEND CONFIG ('tablet_sched_disable_balance' = 'true');
    ADMIN SHOW FRONTEND CONFIG LIKE 'lake_compaction_max_tasks';
    ADMIN SHOW FRONTEND CONFIG LIKE 'tablet_sched_disable_balance';

    b. Перезапустите все узлы BE

    c. Убедитесь, что все компактификации завершились неудачей.

    SHOW PROC '/compactions'

    d. Повторно включите компактификацию и миграцию.

    ADMIN SET FRONTEND CONFIG ("lake_compaction_max_tasks" = "-1");
    ADMIN SET FRONTEND CONFIG ('tablet_sched_disable_balance' = 'false');
    ADMIN SHOW FRONTEND CONFIG LIKE 'lake_compaction_max_tasks';
    ADMIN SHOW FRONTEND CONFIG LIKE 'tablet_sched_disable_balance';

Почему компактификация медленная в Kubernetes shared-data cluster?​

Если приём данных происходит в одном warehouse, а компактификация выполняется в другом (например, default_warehouse), компактификация должна загружать данные между warehouse без кэша, замедляя её.

Решение:

  • Установите конфигурацию BE lake_enable_vertical_compaction_fill_data_cache в true.
  • Выполняйте записи в том же warehouse, где выполняется компактификация.

Почему использование хранилища кажется завышенным в shared-data cluster?​

Использование хранилища в объектном хранилище включает все исторические версии, в то время как вывод SHOW DATA отражает только последнюю версию.

Однако, если разница чрезмерно велика, это может быть вызвано следующими проблемами:

  • Компактификация может отставать.
  • Задачи Vacuum могут накапливаться (проверьте размер очереди).

При необходимости вы можете настроить пулы потоков компактификации или vacuum.

Почему большие запросы завершаются ошибкой "meta does not exist"?​

Запрос может использовать версию данных, которая уже была скомпактифицирована и очищена.

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

Что вызывает чрезмерное количество мелких файлов в объектном хранилище?​

Чрезмерное количество мелких файлов может вызвать снижение производительности. Распространённые причины включают:

  • Слишком много bucket из-за неправильных настроек bucket.
  • Высокая частота приёма данных, вызывающая очень маленькие отдельные загрузки.

Компактификация в конечном итоге объединит мелкие файлы, но настройка количества bucket и пакетирование приёма помогают предотвратить снижение производительности.