Pull to refresh

Comments 6

Спасибо, что поделились опытом. Очень интересно.

Если не NDA (ну вдруг), то можете рассказать поподробнее?:
1) реплика на которую преключаетесь находится локально в том же ЦОДе? А для DR есть offsite-реплика?
2) у вас реплики под управлением Pacemaker-кластера или просто primary-secondary с ручным takeover'ом?
3) реплика с preload_column_tables = true?
4) сколько выставлен tables_preloaded_in_parallel? И какая скорость чтения с диска при стартапе без FastRestart'а.
5) при таких ресурсах (12TB+448core) и 10K юзеров во сколько выставлены default_statement_concurrency_limit и statement_memory_limit?
6) ECC или S4? :)

Из того как боремся сами (объемы, правда, поменьше): кручение параметров по нотам при различных утечках в разных аллокаторах на разных ревиженах, reload_tables=false на копиях прода, workload-классы для особо прожорливых репортов/транзакций и непонятливых юзеров ну и resman shrink если уж совсем апож. Смотрим на NSE, который теперь можно в ECC/S4.

С logreplay есть «дьявол в деталях» — если на реплике выставлен preload_column_tables = false, то indexserver все-равное будет лопать память аллокатором Pool/ColumnStore и чем дольше реплика работает — тем больше. Поэтому при совмещении реплики с препродом/тестом приходится играться с GAL и периодически передергивать реплику или переходить на delta_datashipping, в котором такого нет.
Добрый день, krids!

1. Нет, это 2 разных ЦОДа.
2. Pacemaker настроен, да. Все автоматически переезжает. Тут тоже пришлось поплясать с бубном, чтобы хорошо работало.
3. Все верно, параметр не меняли. По умолчанию preload_column_tables = true
4. tables_preloaded_in_parallel = 30. Диск никогда не замеряли специально, а проверять на продуктиве сейчас не хочется) Но если будет возможность, обязательно проверим.
5. default_statement_concurrency_limit = 40, statement_memory_limit =150
6. В рамках этой статьи речь по ECC, но в ближайшее время уже проверим и на S/4)

Утечка памяти в аллокаторах — извечная проблема. Не стал ее описывать в статье, но тоже сталкиваемся регулярно. На большой базе это не так сильно заметно, а вот на меньших объемах в 512 Гб — 1,5 Тб бывает очень критично. И что самое сложное — очень сильно зависит от ревизии HANA. Приходится тщательно тестировать все новые обновления. Ну и shrink спасает, конечно.

NSE сейчас тоже тестируем. Пока в поиске разумного баланса между скоростью считывания и потреблением памяти :) Опция как минимум хороша для не продуктивных систем, если требуется использовать железо с меньшим объемом памяти.

А вот про logreplay и preload_column_tables = false — не сталкивался. Видимо, никогда не тестировали такую конфигурацию. Спасибо за информацию!
Большое спасибо за ответы, но появляются еще вопросы (тема «больная») :)

1. Нет, это 2 разных ЦОДа.
2. Pacemaker настроен, да. Все автоматически переезжает. Тут тоже пришлось поплясать с бубном, чтобы хорошо работало.

Не расскажите как сделан stonith/fencing? Кейс с network isolation (когда с primary-БД все хорошо, но с нее недоступны ни реплика ни fencing device) тестировали? ASCS/AS реплицируете во второй ЦОД?

В рамках этой статьи речь по ECC, но в ближайшее время уже проверим и на S/4)
Cкорее всего увидите много «открытий чудных» и мемори-лимит придется раза в два приподнять ;)
Не расскажите как сделан stonith/fencing? Кейс с network isolation (когда с primary-БД все хорошо, но с нее недоступны ни реплика ни fencing device) тестировали? ASCS/AS реплицируете во второй ЦОД?

Тут, к сожалению, речь про КТ. Полноценно раскрыть не могу. Скажем так, кейс с network isolation стараемся не допускать, но проблема такая есть.

Cкорее всего увидите много «открытий чудных» и мемори-лимит придется раза в два приподнять ;)

krids, может поделитесь с чем столкнулись? Очень любопытно)

Упс....прошу прощения, пропустил. В основном на S4 проблема с неоптимальными СDS выедающими кучу памяти (у нас лимит 400GB и иногда в закрытие приходится крактовременно увеличивать). Тот же "всеми любимый" J_3RMOBVEDH теперь сделан ADMP-процедурой и тоже ест памяти (пришлось на него сделать workload class на 200GB лимита)

Из статьи непонятно, используются ли два равноценных по ресурсам узла для построения кластера. Если они равноценны, то БД ещё с древнейших версий SP HANA 1.0 умела выполнять синхронную репликацию online. Тогда вся перезагрузка сводилась бы ко времени отработки команды hdbnsutil.

Sign up to leave a comment.