Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Informix Новый топик    Ответить
 NEAR_SYNC  [new]
cpr
Member

Откуда: Rostov-on-Don
Сообщений: 717
Коллеги, доброго дня!

IDS FC4W1

Параметр HDR_TXN_SCOPE = NEAR_SYNC

периодически проверяю onstat -g cluster на primary
и вижу что Applied page немного отстает от ACKed page.
Меня терзают смутные сомненья, что если отставание будет нарастать?

Есть ли штатные способы генерации алертов?

Ставить FULL_SYNC пока страшновато, а ну как вайтеры на блокировках попрут.
10 янв 17, 16:51    [20090290]     Ответить | Цитировать Сообщить модератору
 Re: NEAR_SYNC  [new]
cpr
Member

Откуда: Rostov-on-Don
Сообщений: 717
cpr,

в смысле IDS 12.10
10 янв 17, 16:54    [20090303]     Ответить | Цитировать Сообщить модератору
 Re: NEAR_SYNC  [new]
яфшуеі
Guest
Вайты попрут не по блокировкам.
Вайты могут пойти по ожиданиям буферов лог. журнала - "тормоза".
Разница больше суммарного размера буферов лог. журнала?
Если разница больше, и нет ожиданий буферов журнала - то проблем производительности не должно как по мне быть - рассинхронизованность рано или поздно пройдет.
Если у вас кол-во активных пользователей/сессий исчисляется сотнями/тысячами - попробуйте при хорошей активности пользователей сделать большую чистку минут на 5 и посмотрите на репликацию и состояние нитей.


Мое субъективное мнение -
После IDS 9.40 репликация стала работать медленнее.
На 9.40 почти безпроблемно работала на не лучших каналах связи.
Кстати у ИБМ нет требований к каналам связи для репликации.
На 12.10 так и не перешли, на 11.70 для unbuf БД даже ASYNC HDR проблемна местами.
На более поздних релизах 11.70 должны были править механизм SMX (связано с SMX_COMPRESS) и там какие-то проблемы должны были решиться.
11 янв 17, 16:43    [20094660]     Ответить | Цитировать Сообщить модератору
 Re: NEAR_SYNC  [new]
cpr
Member

Откуда: Rostov-on-Don
Сообщений: 717
яфшуеі,

Разница пока незначительна , в пике - десятки страниц.
Думаю написать монитор чтобы последить на длительных циклах нагрузки не менее месяца.
11 янв 17, 18:42    [20095199]     Ответить | Цитировать Сообщить модератору
 Re: NEAR_SYNC  [new]
cpr
Member

Откуда: Rostov-on-Don
Сообщений: 717
яфшуеі
Вайты попрут не по блокировкам.
Вайты могут пойти по ожиданиям буферов лог. журнала - "тормоза".
Разница больше суммарного размера буферов лог. журнала?
Если разница больше, и нет ожиданий буферов журнала - то проблем производительности не должно как по мне быть - рассинхронизованность рано или поздно пройдет.
Если у вас кол-во активных пользователей/сессий исчисляется сотнями/тысячами - попробуйте при хорошей активности пользователей сделать большую чистку минут на 5 и посмотрите на репликацию и состояние нитей.


Мое субъективное мнение -
После IDS 9.40 репликация стала работать медленнее.
На 9.40 почти безпроблемно работала на не лучших каналах связи.
Кстати у ИБМ нет требований к каналам связи для репликации.
На 12.10 так и не перешли, на 11.70 для unbuf БД даже ASYNC HDR проблемна местами.
На более поздних релизах 11.70 должны были править механизм SMX (связано с SMX_COMPRESS) и там какие-то проблемы должны были решиться.
11 янв 17, 18:43    [20095208]     Ответить | Цитировать Сообщить модератору
 Re: NEAR_SYNC  [new]
cpr
Member

Откуда: Rostov-on-Don
Сообщений: 717
cpr,

последнее сообщение - косяк
11 янв 17, 18:43    [20095211]     Ответить | Цитировать Сообщить модератору
 Re: NEAR_SYNC  [new]
cpr
Member

Откуда: Rostov-on-Don
Сообщений: 717
яфшуеі,

Вы писали:-"попробуйте при хорошей активности пользователей сделать большую чистку минут на 5"

Простите не понял какая чистка имеется ввиду?
11 янв 17, 18:45    [20095217]     Ответить | Цитировать Сообщить модератору
 Re: NEAR_SYNC  [new]
яфшуеі
Guest
имелось в виду удаление записей.
По моим наблюдениям - репликация плохо переносит массовые удаления,
т.е. передача(или применение) на DR DELETE операций значительно медленнее чем других.
Хотя, восстановление с бекапа "накатывает" эти операции значительно быстрее.

И снова, субъективно, скорее всего, независимо какое значение HDR_TXN_SCOPE и DRINTERVAL,
максимальное отставание HDR будет LOGBUFF*3(нужно еще учитывать logmode БД),
после какого начинаются проблемы производительности на PRIMARY.
Перевод в standart проблему производительности решает.

Да, и нужно разделять логику передачи на HDR сервер
1. Когда сервера синхронны используется одна логика, ее и обсуждаем.
2. Когда мы только запускаем HDR (onmode -d primary),
до момента синхронизации используется своя логика - транзакции получаем с файлов журнала.

По этой причине еще на 11.50 отказались от HDR в пользу RS.
Саппорт отрицал связь HDR и LOGBUFF.

Все это касается 11.70.FC5XE. На 12.10 может быть по другому.



При дилемме синхронность данных-производительнось, я (вернее бизнес) выбираю производительность.
Вас скорее интересует синхронность, поэтому ход мыслей может разниться :)
12 янв 17, 12:32    [20097862]     Ответить | Цитировать Сообщить модератору
 Re: NEAR_SYNC  [new]
cpr
Member

Откуда: Rostov-on-Don
Сообщений: 717
яфшуеі,

спасибо, есть над чем подумать.


А не знаете случайно какие алерты генерирует датчик ifx_ha_monitor_log_replay_task

он вызывает сишную функцию и непонятно что он делает
13 янв 17, 13:33    [20102565]     Ответить | Цитировать Сообщить модератору
Все форумы / Informix Ответить