Провели маленький тест на отказоустойчивость.
По результату - при падении PRI сервера не переходите на SDS методом onmode -d make primary
Делали 2 раза тест - отваливались чанки при активной работе в момент падения
основного сервера (киляли первый виртуальный проц - имеет право на жизнь и такой аварийный сбой).

Переходить нужно только с перезапуском для избежания проблем.
Правда это на 11.50.FC5W2 а не 11.50.FC5W4
но вроде там ничего такого не правили.

Еще ничего, токо собираюсь делать обрашение.

victor16Если предварительно запустить Connection Manager с правильно настроенным Failover Arbitrator, то автоматический переход с secondary на primary проходит без проблем. Проверял несколько раз на 11.50.


Я тоже проверял - все работало.
Но разница в том, что когда проверял и все работало - я останавливал Pri корректно.
В данном же случае тестировалась ситуация с падением, когда было более
1500 транзакций в секунду.

На пустой системе да - все ОК,
Проблем нет.

А вот нагрузили - и вылезло.

victor16Я имел в виду, что не надо переводить sec в pri вручную. Это делает CM.
Что касается падения сервера при больших нарузках, это другой вопрос, возможно, что и PMR.


Разочарован я в MACH11 не то слово как.
Из-за него отказались от Веритаса и имеем проблемы с downtime.

В данном случае как раз и нужно делать ручками.
Думаете СМ что-то такое специфическое віполняет - нет.
Он тоже віполняет onmode -d make primary, только через sysadmin api

Я понимаю, что на пустой системе все работает, но какого дидька мне кластер для пустой системы :)
За те несколько лет, что рекламируют MACH11 могли бы уже и вылизать.
После НГ выходит 11.50хС6 - в нем обещают много исправлений по MACH11.
Но, подумайте, сколько времени прошло с выхода 11.10 - неужели не могли вылизать?

А с саппортом какие-то непорядки последнее время - видать увольнения сказываются.
Открыл PMR 19.10.2009 первый ответ по сути пришел 12.11.2009.

victor16zaiets
А у Вас конфигурация железа какая?
У нас блэйд HS22 на 4 лезвиях x86-64 с общим диском на DS3400. ОС - SuSe SLES 11.0.
Идет ER с 8 филиалами, там, как правило x3650 32bit на SLES 10.2. На одном из филиалов одно время была даже Винда.
Предварительно консультировались с IBM-ом насчет работоспособности такой конфигурации, правда, не с местным, а напрямую, (благодарности J.Keessy).
На блейде во время плотной работы отключали лезвие с первичкой, CM нормально отработал.

С уважением,
Виктор

У меня все проще - Sun Solaris.
CM отрабатывет нормально - не об этом речь.
В моем случае при:
1. Активной трнзакционной активности - более 1500 транзакций в сек
2. При "kill -9" - Pri сервера.
3. При переводе SDS в PRI происходит проблема независимо каким методом все єто делается.
Проблему то я решил через FAILOVER_CALLBACK. Но через FAILOVER_CALLBACK сервер останавливается 2 минуті, а нужно біло весь переход подогнать под 2 минуті.

Как ві отключали лезвие?
Вполне возможно, что отключение всего лезвия/сервера значительно мягче чем киляние первого ВП.

Если кому интересно и хочет проверить на ТЕСТОВОЙ системе.

На тестовой системе удалось воспроизвести ситуацию.
Последовательность действий.
1. Настраиваем SDS и CM (FOC SDS,5)
2. создаем тестовую БД
echo "create database test_sds in dbs1 with log" | dbaccess sysmaster
4. Запускаем скрипт
./runtest.sh 20
20 - это количество параллельных операций (оказалось достаточно токо инсертов)
5. Киляем Pri
onstat -g glo | nawk '$1$2$3=="Individualvirtualprocessors:"{getline; getline ; k="kill -9 "$2 ; system(k)}'


У меня в результате вілетает чанк.
Думал саппорту придется отдавать данные для теста, оказалось все проще.

И как всегда, саппорт тестирует не на той платформе и не на той версии.
И у него все ОК.

Может таки кто знает где можно достать правильный бубен? :)
А то у нас прям аномалия какая-то с MACH11.

Sparc
По проблеме открыт АПАР IC64669
The planned release date for 11.50.xC6 is the 24th of December

проблемы на хС6 нет,
но моего апара в списке исправленных нет