Управление оповещениями

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

примечание

В следующих примерах все переменные имеют префикс $. Их следует заменить в соответствии с вашей бизнес-средой. Например, $job_name следует заменить соответствующим именем задания в конфигурации Prometheus, а $fe_leader следует заменить IP-адресом Leader FE.

Оповещения о приостановке сервиса

Приостановка сервиса FE

PromSQL

count(up{group="fe", job="$job_name"}) >= 3

Описание оповещения

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

Решение

Попробуйте перезапустить приостановленный узел FE.

Приостановка сервиса BE

PromSQL

node_info{type="be_node_num", job="$job_name",state="dead"} > 1

Описание оповещения

Оповещение срабатывает, когда приостановлено более одного узла BE.

Решение

Попробуйте перезапустить приостановленный узел BE.

Оповещения о нагрузке на машины

Оповещение о CPU BE

PromSQL

(1-(sum(rate(starrocks_be_cpu{mode="idle", job="$job_name",instance=~".*"}[5m])) by (job, instance)) / (sum(rate(starrocks_be_cpu{job="$job_name",host=~".*"}[5m])) by (job, instance))) * 100 > 90

Описание оповещения

Оповещение срабатывает, когда использование CPU BE превышает 90%.

Решение

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

1. Используйте команду top для проверки использования ресурсов процессами.

   top -Hp $be_pid

2. Используйте команду perf для сбора и анализа данных о производительности.

   # Выполните команду в течение 1-2 минут и завершите её нажатием CTRL+C.
   sudo perf top -p $be_pid -g >/tmp/perf.txt

примечание

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

Оповещение о памяти

PromSQL

(1-node_memory_MemAvailable_bytes{instance=~".*"}/node_memory_MemTotal_bytes{instance=~".*"})*100 > 90

Описание оповещения

Оповещение срабатывает, когда использование памяти превышает 90%.

Решение

Обратитесь к Get Heap Profile для устранения неполадок.

примечание

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

Оповещения о дисках

Оповещение о нагрузке на диск

PromSQL

rate(node_disk_io_time_seconds_total{instance=~".*"}[1m]) * 100 > 90

Описание оповещения

Оповещение срабатывает, когда нагрузка на диск превышает 90%.

Решение

Если кластер срабатывает оповещение node_disk_io_time_seconds_total, сначала проверьте, есть ли какие-либо изменения в бизнесе. Если да, рассмотрите возможность отката изменений для поддержания предыдущего баланса ресурсов. Если изменения не выявлены или откат невозможен, рассмотрите, не вызывает ли нормальный рост бизнеса потребность в расширении ресурсов. Вы можете использовать инструмент iotop для анализа использования дискового I/O. iotop имеет интерфейс, похожий на top, и включает информацию, такую как pid, user и I/O.

Вы также можете использовать следующий SQL-запрос для выявления tablet'ов, потребляющих значительный I/O, и отследить их до конкретных задач и таблиц.

-- "all" указывает все сервисы. 10 указывает, что сбор длится 10 секунд. 3 указывает получение топ-3 результатов.
ADMIN EXECUTE ON $backend_id 'System.print(ExecEnv.io_profile_and_get_topn_stats("all", 10, 3))';

Оповещение о емкости корневого пути

PromSQL

node_filesystem_free_bytes{mountpoint="/"} /1024/1024/1024 < 5

Описание оповещения

Оповещение срабатывает, когда доступное пространство в корневом каталоге составляет менее 5 ГБ.

Решение

Общие каталоги, которые могут занимать значительное пространство, включают /var, /opt и /tmp. Используйте следующую команду для проверки больших файлов и очистки ненужных файлов.

du -sh / --max-depth=1

Оповещение о емкости диска данных

PromSQL

(SUM(starrocks_be_disks_total_capacity{job="$job"}) by (host, path) - SUM(starrocks_be_disks_avail_capacity{job="$job"}) by (host, path)) / SUM(starrocks_be_disks_total_capacity{job="$job"}) by (host, path) * 100 > 90

Описание оповещения

Оповещение срабатывает, когда использование емкости диска превышает 90%.

Решение

1. Проверьте, были ли изменения в объеме загружаемых данных.

   Отслеживайте метрику load_bytes в Grafana. Если произошло значительное увеличение объема загрузки данных, вам может потребоваться масштабировать системные ресурсы.

2. Проверьте наличие операций DROP.

   Если объем загрузки данных не сильно изменился, выполните SHOW BACKENDS. Если сообщаемое использование диска не соответствует фактическому использованию, проверьте журнал аудита FE на предмет недавних операций DROP DATABASE, TABLE или PARTITION.

   Метаданные для этих операций остаются в памяти FE в течение одного дня, что позволяет восстановить данные с помощью оператора RECOVER в течение 24 часов, чтобы избежать ошибочных операций. После восстановления фактическое использование диска может превысить то, что показано в SHOW BACKENDS.

   Период хранения удаленных данных в памяти можно настроить с помощью динамического параметра FE catalog_trash_expire_second (значение по умолчанию: 86400).

   ADMIN SET FRONTEND CONFIG ("catalog_trash_expire_second"="86400");

   Чтобы сохранить это изменение, добавьте элемент конфигурации в файл конфигурации FE fe.conf.

   После этого удаленные данные будут перемещены в каталог trash на узлах BE ($storage_root_path/trash). По умолчанию удаленные данные хранятся в каталоге trash в течение одного дня, что также может привести к тому, что фактическое использование диска превысит то, что показано в SHOW BACKENDS.

   Время хранения удаленных данных в каталоге trash можно настроить с помощью динамического параметра BE trash_file_expire_time_sec (значение по умолчанию: 86400).

   curl http://$be_ip:$be_http_port/api/update_config?trash_file_expire_time_sec=86400

Оповещение о емкости диска метаданных FE

PromSQL

node_filesystem_free_bytes{mountpoint="${meta_path}"} /1024/1024/1024 < 10

Описание оповещения

Оповещение срабатывает, когда доступное дисковое пространство для метаданных FE составляет менее 10 ГБ.

Решение

Используйте следующие команды для проверки каталогов, занимающих большое количество пространства, и очистки ненужных файлов. Путь к метаданным указывается конфигурацией meta_dir в fe.conf.

du -sh /${meta_dir} --max-depth=1

Если каталог метаданных занимает много места, это обычно происходит из-за того, что каталог bdb большой, возможно, из-за сбоя CheckPoint. Обратитесь к Оповещение о сбое CheckPoint для устранения неполадок. Если этот метод не решает проблему, обратитесь к команде технической поддержки.

Оповещения об исключениях сервиса кластера

Оповещения о сбоях Compaction

Оповещение о сбое Cumulative Compaction

PromSQL

increase(starrocks_be_engine_requests_total{job="$job_name" ,status="failed",type="cumulative_compaction"}[1m]) > 3
increase(starrocks_be_engine_requests_total{job="$job_name" ,status="failed",type="base_compaction"}[1m]) > 3

Описание оповещения

Оповещение срабатывает, когда происходит три сбоя в Cumulative Compaction или Base Compaction в течение последней минуты.

Решение

Найдите в журнале соответствующего узла BE следующие ключевые слова для выявления задействованного tablet'а.

grep -E 'compaction' be.INFO | grep failed

Запись журнала, подобная следующей, указывает на сбой Compaction.

W0924 17:52:56:537041 123639 comaction_task_cpp:193] compaction task:8482. tablet:8423674 failed.

Вы можете проверить контекст журнала для анализа сбоя. Обычно сбой мог быть вызван операцией DROP TABLE или PARTITION во время процесса Compaction. Система имеет внутренний механизм повтора для Compaction, и вы также можете вручную установить статус tablet'а как BAD и запустить задачу Clone для его восстановления.

примечание

Перед выполнением следующей операции убедитесь, что таблица имеет как минимум три полные реплики.

ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "$tablet_id", "backend_id" = "$backend_id", "status" = "bad");

Оповещение о высоком давлении Compaction

PromSQL

starrocks_fe_max_tablet_compaction_score{job="$job_name",instance="$fe_leader"} > 100

Описание оповещения

Оповещение срабатывает, когда наивысший Compaction Score превышает 100, указывая на высокое давление Compaction.

Решение

Это оповещение обычно вызвано частой загрузкой, операциями INSERT INTO VALUES или DELETE (со скоростью 1 в секунду). Рекомендуется установить интервал между задачами загрузки или DELETE более 5 секунд и избегать отправки высококонкурентных задач DELETE.

Оповещение о превышении количества версий

PromSQL

starrocks_be_max_tablet_rowset_num{job="$job_name"} > 700

Описание оповещения

Оповещение срабатывает, когда tablet на узле BE имеет более 700 версий данных.

Решение

Используйте следующую команду для проверки tablet'а с избыточными версиями:

SELECT BE_ID,TABLET_ID FROM information_schema.be_tablets WHERE NUM_ROWSET>700;

Пример для Tablet с ID 2889156:

SHOW TABLET 2889156;

Выполните команду, возвращенную в поле DetailCmd:

SHOW PROC '/dbs/2601148/2889154/partitions/2889153/2889155/2889156';

При нормальных обстоятельствах, как показано, все три реплики должны быть в статусе NORMAL, а другие метрики, такие как RowCount и DataSize, должны оставаться согласованными. Если только одна реплика превышает лимит версий в 700, вы можете запустить задачу Clone на основе других реплик, используя следующую команду:

ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "$tablet_id", "backend_id" = "$backend_id", "status" = "bad");

Если две или более реплик превышают лимит версий, вы можете временно увеличить лимит количества версий:

# Замените be_ip на IP узла BE, который хранит tablet, превышающий лимит версий.
# be_http_port по умолчанию равен 8040.
# Значение по умолчанию tablet_max_versions равно 1000.
curl -XPOST http://$be_ip:$be_http_port/api/update_config?tablet_max_versions=2000

Оповещение о сбое CheckPoint

PromSQL

starrocks_fe_meta_log_count{job="$job_name",instance="$fe_master"} > 100000

Описание оповещения

Оповещение срабатывает, когда количество журналов BDB узла FE превышает 100 000. По умолчанию система выполняет CheckPoint, когда количество журналов BDB превышает 50 000, а затем сбрасывает счетчик до 0.

Решение

Это оповещение указывает на то, что CheckPoint не был выполнен. Вам необходимо исследовать журналы FE для анализа процесса CheckPoint и решения проблемы:

В fe.log узла Leader FE найдите записи типа begin to generate new image: image.xxxx. Если найдено, это означает, что система начала генерировать новый образ. Продолжите проверку журналов на наличие записей типа checkpoint finished save image.xxxx для подтверждения успешного создания образа. Если вы найдете Exception when generate new image file, генерация образа не удалась. Вы должны осторожно обрабатывать метаданные на основе конкретной ошибки. Рекомендуется обратиться к команде поддержки для дальнейшего анализа.

Оповещение о превышении количества потоков FE

PromSQL

starrocks_fe_thread_pool{job="$job_name", type!="completed_task_count"} > 3000

Описание оповещения

Оповещение срабатывает, когда количество потоков на FE превышает 3000.

Решение

Лимит количества потоков по умолчанию для узлов FE и BE составляет 4096. Большое количество запросов UNION ALL обычно приводит к избыточному количеству потоков. Рекомендуется уменьшить конкурентность запросов UNION ALL и настроить системную переменную pipeline_dop. Если невозможно настроить детализацию SQL-запросов, вы можете глобально настроить pipeline_dop:

SET GLOBAL pipeline_dop=8;

примечание

В чрезвычайных ситуациях для быстрого восстановления сервисов вы можете увеличить динамический параметр FE thrift_server_max_worker_threads (значение по умолчанию: 4096).

ADMIN SET FRONTEND CONFIG ("thrift_server_max_worker_threads"="8192");

Оповещение о высоком использовании JVM FE

PromSQL

sum(jvm_heap_size_bytes{job="$job_name", type="used"}) * 100 / sum(jvm_heap_size_bytes{job="$job_name", type="max"}) > 90

Описание оповещения

Оповещение срабатывает, когда использование JVM на узле FE превышает 90%.

Решение

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

# Обратите внимание, что указание `live` в команде может привести к перезапуску FE.
jmap -histo[:live] $fe_pid > jmap.dump

примечание

В чрезвычайных ситуациях для быстрого восстановления сервисов вы можете перезапустить соответствующий узел FE или увеличить размер JVM (Xmx), а затем перезапустить сервис FE.

Оповещения о доступности сервиса

Оповещения об исключениях загрузки

Оповещение о сбое загрузки

PromSQL

rate(starrocks_fe_txn_failed{job="$job_name",instance="$fe_master"}[5m]) * 100 > 5

Описание оповещения

Оповещение срабатывает, когда количество неудачных транзакций загрузки превышает 5% от общего количества.

Решение

Проверьте журналы узла Leader FE, чтобы найти информацию об ошибках загрузки. Найдите ключевое слово status: ABORTED для выявления неудачных задач загрузки.

2024-04-09 18:34:02.363+08:00 INFO (thrift-server-pool-8845163|12111749) [DatabaseTransactionMgr.abortTransaction():1279] transaction:[TransactionState. txn_id: 7398864, label: 967009-2f20a55e-368d-48cf-833a-762cf1fe07c5, db id: 10139, table id list: 155532, callback id: 967009, coordinator: FE: 192.168.2.1, transaction status: ABORTED, error replicas num: 0, replica ids: , prepare time: 1712658795053, commit time: -1, finish time: 1712658842360, total cost: 47307ms, reason: [E1008]Reached timeout=30000ms @192.168.1.1:8060 attachment: RLTaskTxnCommitAttachment [filteredRows=0, loadedRows=0, unselectedRows=0, receivedBytes=1033110486, taskExecutionTimeMs=0, taskId=TUniqueId(hi:3395895943098091727, lo:-8990743770681178171), jobId=967009, progress=KafkaProgress [partitionIdToOffset=2_1211970882|7_1211893755]]] successfully rollback

Оповещение о задержке потребления Routine Load

PromSQL

(sum by (job_name)(starrocks_fe_routine_load_max_lag_of_partition{job="$job_name",instance="$fe_mater"})) > 300000
starrocks_fe_routine_load_jobs{job="$job_name",host="$fe_mater",state="NEED_SCHEDULE"} > 3
starrocks_fe_routine_load_jobs{job="$job_name",host="$fe_mater",state="PAUSED"} > 0
starrocks_fe_routine_load_jobs{job="$job_name",host="$fe_mater",state="UNSTABLE"} > 0

Описание оповещения

• Оповещение срабатывает, когда более 300 000 записей задерживаются в потреблении.
• Оповещение срабатывает, когда количество ожидающих задач Routine Load превышает 3.
• Оповещение срабатывает, когда есть задачи в состоянии PAUSED.
• Оповещение срабатывает, когда есть задачи в состоянии UNSTABLE.

Решение

1. Сначала проверьте, находится ли статус задачи Routine Load в состоянии RUNNING.

   SHOW ROUTINE LOAD FROM $db;

   Обратите внимание на поле State в возвращаемых данных.

2. Если какая-либо задача Routine Load находится в состоянии PAUSED, изучите поля ReasonOfStateChanged, ErrorLogUrls и TrackingSQL. Обычно выполнение SQL-запроса в TrackingSQL может выявить конкретную ошибку.

   Пример:

   

3. Если статус задачи Routine Load RUNNING, вы можете попробовать увеличить конкурентность задачи. Конкурентность отдельных заданий Routine Load определяется минимальным значением из следующих четырех параметров:

   • kafka_partition_num: Количество разделов в Kafka Topic.
   • desired_concurrent_number: Установленная конкурентность для задачи.
   • alive_be_num: Количество живых узлов BE.
   • max_routine_load_task_concurrent_num: Параметр конфигурации FE со значением по умолчанию 5.

В большинстве случаев вам может потребоваться настроить конкурентность задачи или количество разделов Kafka Topic (при необходимости обратитесь к поддержке Kafka).

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

ALTER ROUTINE LOAD FOR ${routine_load_jobname}
PROPERTIES
(
    "desired_concurrent_number" = "5"
);

Оповещение о лимите транзакций загрузки для одной базы данных

PromSQL

sum(starrocks_fe_txn_running{job="$job_name"}) by(db) > 900

Описание оповещения

Оповещение срабатывает, когда количество транзакций загрузки для одной базы данных превышает 900 (100 в версиях до v3.1).

Решение

Это оповещение обычно срабатывает из-за большого количества вновь добавленных задач загрузки. Вы можете временно увеличить лимит транзакций загрузки для одной базы данных.

ADMIN SET FRONTEND CONFIG ("max_running_txn_num_per_db" = "2000");

Оповещения об исключениях запросов

Оповещение о задержке запросов

PromSQL

starrocks_fe_query_latency_ms{job="$job_name", quantile="0.95"} > 5000

Описание оповещения

Оповещение срабатывает, когда задержка запросов P95 превышает 5 секунд.

Решение

1. Исследуйте, есть ли большие запросы.

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

   • Выполните show proc '/current_queries'; для просмотра QueryId больших запросов. Если вам нужно быстро восстановить сервис, вы можете использовать команду KILL для завершения долго выполняющихся запросов.

     mysql> SHOW PROC '/current_queries';
     +--------------------------------------+--------------+------------+------+-----------+----------------+----------------+------------------+----------+
     | QueryId                              | ConnectionId | Database   | User | ScanBytes | ProcessRows    | CPUCostSeconds | MemoryUsageBytes | ExecTime |
     +--------------------------------------+--------------+------------+------+-----------+----------------+----------------+------------------+----------+
     | 7c56495f-ae8b-11ed-8ebf-00163e00accc | 4            | tpcds_100g | root | 37.88 MB  | 1075769 Rows   | 11.13 Seconds  | 146.70 MB        | 3804     |
     | 7d543160-ae8b-11ed-8ebf-00163e00accc | 6            | tpcds_100g | root | 13.02 GB  | 487873176 Rows | 81.23 Seconds  | 6.37 GB          | 2090     |
     +--------------------------------------+--------------+------------+------+-----------+----------------+----------------+------------------+----------+
     2 rows in set (0.01 sec)

   • Вы также можете перезапустить узлы BE с высоким использованием CPU для решения проблемы.

2. Проверьте, достаточно ли машинных ресурсов.

   Убедитесь, что CPU, память, дисковый I/O и сетевой трафик во время исключения нормальны. Если обнаружены аномалии, исследуйте основную причину, изучив пиковые изменения трафика и использование ресурсов кластера. Если проблема сохраняется, рассмотрите возможность перезапуска затронутого узла.

примечание

В чрезвычайных ситуациях вы можете решить проблему:

• Уменьшив бизнес-трафик и перезапустив затронутый узел BE, если внезапный всплеск трафика вызвал чрезмерное использование ресурсов и сбой запросов.
• Расширив емкость узлов, если высокое использование ресурсов связано с нормальными операциями.

Оповещение о сбое запросов

PromSQL

sum by (job,instance)(starrocks_fe_query_err_rate{job="$job_name"}) * 100 > 10

# Этот PromSQL поддерживается начиная с v3.1.15, v3.2.11 и v3.3.3.
increase(starrocks_fe_query_internal_err{job="$job_name"})[1m] >10

Описание оповещения

Оповещение срабатывает, когда частота сбоев запросов превышает 0.1/секунду или происходит 10 неудачных запросов в течение одной минуты.

Решение

Когда срабатывает это оповещение, проверьте журналы для выявления запросов, которые завершились неудачей.

grep 'State=ERR' fe.audit.log

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

SELECT stmt FROM starrocks_audit_db__.starrocks_audit_tbl__ WHERE state='ERR';

Обратите внимание, что запросы, которые завершаются неудачей из-за синтаксических ошибок или тайм-аутов, также записываются в starrocks_fe_query_err_rate.

Для сбоев запросов, вызванных проблемами ядра, найдите ошибку в fe.log и получите полную трассировку стека и Query Dump, и обратитесь к команде поддержки для устранения неполадок.

Оповещение о перегрузке запросов

PromSQL

abs((sum by (exported_job)(rate(starrocks_fe_query_total{process="FE",job="$job_name"}[3m]))-sum by (exported_job)(rate(starrocks_fe_query_total{process="FE",job="$job_name"}[3m] offset 1m)))/sum by (exported_job)(rate(starrocks_fe_query_total{process="FE",job="$job_name"}[3m]))) * 100 > 100
abs((sum(starrocks_fe_connection_total{job="$job_name"})-sum(starrocks_fe_connection_total{job="$job_name"} offset 3m))/sum(starrocks_fe_connection_total{job="$job_name"})) * 100 > 100

Описание оповещения

Оповещение срабатывает, когда QPS или количество соединений увеличивается на 100% в течение последней минуты.

Решение

Проверьте, ожидаются ли высокочастотные запросы в fe.audit.log. Если есть законные изменения в поведении бизнеса (например, запуск новых сервисов или увеличение объемов данных), отслеживайте нагрузку на машины и масштабируйте узлы BE по мере необходимости.

Оповещение о превышении лимита пользовательских соединений

PromSQL

sum(starrocks_fe_connection_total{job="$job_name"}) by(user) > 90

Описание оповещения

Оповещение срабатывает, когда количество пользовательских соединений превышает 90. (Лимиты пользовательских соединений поддерживаются начиная с версий v3.1.16, v3.2.12 и v3.3.4.)

Решение

Используйте SQL-команду SHOW PROCESSLIST для проверки, соответствует ли количество текущих соединений ожидаемому. Вы можете завершить неожиданные соединения с помощью команды KILL. Кроме того, убедитесь, что фронтенд-сервисы не держат соединения открытыми слишком долго, и рассмотрите возможность настройки системной переменной wait_timeout (единица: секунды) для ускорения автоматического завершения неактивных соединений системой.

SET wait_timeout = 3600;

примечание

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

• Для v3.1.16, v3.2.12 и v3.3.4 или более поздних версий:

  ALTER USER 'jack' SET PROPERTIES ("max_user_connections" = "1000");

• Для v2.5 и более ранних версий:

  SET PROPERTY FOR 'jack' 'max_user_connections' = '1000';

Оповещение об исключении Schema Change

PromSQL

increase(starrocks_be_engine_requests_total{job="$job_name",type="schema_change", status="failed"}[1m]) > 1

Описание оповещения

Оповещение срабатывает, когда более одной задачи Schema Change завершается неудачей в течение последней минуты.

Решение

Выполните следующий оператор для проверки, содержит ли поле Msg какие-либо сообщения об ошибках:

SHOW ALTER COLUMN FROM $db;

Если сообщение не найдено, найдите JobId из предыдущего шага в журналах Leader FE для получения контекста.

• Schema Change Out of Memory

  Если Schema Change завершается неудачей из-за недостатка памяти, найдите в журналах be.WARNING failed to process the version, failed to process the schema change from tablet или Memory of schema change task exceeded limit для выявления записей журнала, показанных ниже:

  fail to execute schema change: Memory of schema change task exceed limit. DirectSchemaChange Used: 2149621304, Limit: 2147483648. You can change the limit by modify BE config [memory_limitation_per_thread_for_schema_change]

  Ошибка лимита памяти обычно вызвана превышением лимита памяти в 2 ГБ для одного Schema Change, контролируемого динамическим параметром BE memory_limitation_per_thread_for_schema_change. Вы можете изменить этот параметр для решения проблемы.

  curl -XPOST http://be_host:http_port/api/update_config?memory_limitation_per_thread_for_schema_change=8

• Schema Change Timeout

  За исключением добавления столбцов, которое является легковесной реализацией, большинство Schema Changes включают создание большого количества новых tablet'ов, перезапись исходных данных и реализацию операции через SWAP.

  Create replicas failed. Error: Error replicas:21539953=99583471, 21539953=99583467, 21539953=99599851

  Вы можете решить это:

  • Увеличив тайм-аут для создания tablet'ов (по умолчанию: 10 секунд).

    ADMIN SET FRONTEND CONFIG ("tablet_create_timeout_second"="60");

  • Увеличив количество потоков для создания tablet'ов (по умолчанию: 3).

    curl -XPOST http://be_host:http_port/api/update_config?alter_tablet_worker_count=6

• Ненормальное состояние Tablet

  1. Если tablet находится в ненормальном состоянии, найдите в журналах be.WARNING tablet is not normal и выполните SHOW PROC '/statistic' для проверки UnhealthyTabletNum на уровне кластера.

     

  2. Выполните SHOW PROC '/statistic/$DbId' для проверки количества нездоровых tablet'ов в указанной базе данных.

     

  3. Выполните SHOW TABLET $tablet_id для просмотра информации о таблице соответствующего tablet'а.

     

  4. Выполните команду, возвращенную в поле DetailCmd, для выявления причины нездоровых tablet'ов.

     

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

примечание

В чрезвычайных ситуациях для восстановления сервиса вы можете установить ненормальные реплики как Bad для запуска задачи Clone.

ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "$tablet_id", "backend_id" = "$backend_id", "status" = "bad");

Перед выполнением этой операции убедитесь, что таблица имеет как минимум три полные реплики с только одной ненормальной репликой.

Оповещение об исключении обновления материализованного представления

PromSQL

increase(starrocks_fe_mv_refresh_total_failed_jobs[5m]) > 0

Описание оповещения

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

Решение

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

   SELECT TABLE_NAME,IS_ACTIVE,INACTIVE_REASON,TASK_NAME FROM information_schema.materialized_views WHERE LAST_REFRESH_STATE !=" SUCCESS";

2. Попробуйте вручную обновить материализованное представление.

   REFRESH MATERIALIZED VIEW $mv_name;

3. Если материализованное представление находится в состоянии INACTIVE, попробуйте вручную активировать его.

   ALTER MATERIALIZED VIEW $mv_name ACTIVE;

4. Исследуйте причину сбоя обновления.

   SELECT * FROM information_schema.task_runs WHERE task_name ='mv-112517' \G