MarkLogi c: Как ускорить процесс ребалансировки при добавлении нового леса в существующую базу данных? - PullRequest
1 голос
/ 02 апреля 2020

Наше производство MarkLogi c В БД хранятся данные по 1,2 ТБ, разделенные на 6 лесов. Мы планируем добавить 2 новых леса, чтобы уменьшить количество древостоев на количество лесов.

Теперь добавление новых лесов начинает перебалансировать данные. Это нормально, это занимает время. Но это время перебалансировки продолжает расти, когда слияния начинаются вместе с перебалансированием. Иногда это занимает от 8 часов до 16 часов. Итак, в среднем весь процесс занимает около 24 часов.

Мой вопрос - Если мы отключим объединение перед добавлением новых лесов и включим ручное объединение вскоре после завершения перебалансировки (после добавление лесов), будет ли этот процесс быстрее? И будет ли это безопасно делать?

Ответы [ 2 ]

1 голос
/ 02 апреля 2020

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

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

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

0 голосов
/ 02 апреля 2020

В дополнение к другой предоставленной информации политика назначения может влиять на объем выполненной работы. См. Например: https://docs.marklogic.com/guide/admin/database-rebalancing#id_81616. Вы также можете установить дроссель ребалансера, чтобы он работал медленнее, если система перегружена. Но если вы отключите объединение во время перебалансировки, я готов поспорить, что вы довольно быстро столкнетесь с ошибкой TOOMANYSTANDS, так как из-за ребалансировки нужно будет записывать небольшие стенды, но они не смогут объединяться в более крупные + меньше стендов. .

...