гуру, подскажите размер передаваемого за раз пакета(hdr buffer) равен log_buffer или stmt_cach_size?

ситуация такова,что при запуске оч сложного операционного процесса логи на основном меняются очень-очень быстро,а резерв получает по 1 пакету размеров 2Мб раз в 10 секунд и ему приходится долго догонять,в результате чего разрыв доходит до 300Мб и передача на вторичный отваливается по параметру drtimeout

как увеличить размер передаваемого буфера?по идее он равен логическому буферу

Прав ли я?

Спасибо

GVF112GVF,

Вадим,спасибо большое за ответы и советы,но не получилось(

Я уже не понимаю почему такое происходит:репликация работает неделю при маленьких изменениях,а потом при запуске процесса,активно заполняющего логические логи на основном серваке,запускаю onstat -g rss verbose -r 1 на основном и вижу что буферы передаются.
Как я это заметил?---

В выводе команды есть 4 основны естроки:
-номер лога и номер посл отправленного буфера
-номер лога и номер след буфера
-размер след передаваемого буфера
-остаток буферов для передачи
Так вот во время заполнения логов на первичном отставание нарастает(4строка) и в какой-то момент первичный просто перестает передавать.Примерное отставание 150000 2Кб страниц,то есть 300Мб.


1)Изначально думал,что отваливается по времени,но увеличил интервал до 30минут,но не помогло,т.е. теперь ни по drtimeout ни по delay_apply ограничений на передачу нет.

2)Первичный сервер в 1.5 слабее по памяти и процу и на вторичном поставил OFF_RECVRY_THREADS =200 при CPU VPS=16...Накатывать он успевает точно и безо всяких проблем

3)DRINTERVAL=20,но он тоже не влияет,потому что при таком процессе логические буферы заполняются оч быстро и сразу отправляются.

4)NETTYPE onsoctcp,8,150,CPU
NETTYPE onsoctcp,6,150,NET
Как я почитал в Administration guide этот протокол лучше всего для соединения 2 серверов.Правильно ли я сделал тут?Или лучше ipsch?и + только для протокола tcp можно менять коммуникационный размер буфера

5) LOGBUFF = 2048 и менял его и в большую и в меньшую сторону-но размер передачи буфера не меняется!Т.е. он не зависит он него,а скорее всего от коммуникационного размера буфера передачи

6)TEMPTAB_NOLOG = 1 установил-не помогло

7)в SQLHOSTS для ALIAS HDR и RSS, можно задать размер коммуникационного буфера b=''
прочитал об этом в пятницу вечером,изменил параметр,сервера отресторил на с одинакового бэкапа,подключил реплику,вторичный стал догонять первичный по логике,но опять же с размером 2048,хотя в sqlhosts установил b=8192.Может быть только новые изменения он станет так передавать?В чем я оч сильно сомневаюсь...Вроде все сделал как в guide написано и ребутнул серваки
Между серверами есть 2 разные сети:одна внутренняя кластерная без фаерволов и работает в 1 свитче,а вторая внешняя,но репликация падает и там и там одинаково.Задержек и перебоев в сетях нет.Скорость около 50Мбит/с постоянна.


8)RSS_FLOW_CONTROL не могу использовать этот параметр,так как проблема не в накатывании логов,а в передаче.



Подскажите что еще можно сделать???

Можно спросить тонкости изменения размера коммуникационного буфера?

Сетевые платы гигабитные и нагружать их можно.Сеть тоже

Спасибо большое за любую помощь

GVF112GVF,

спасибо большое Вадим.завтра с утра буду все делать и установлю параметры как Вы советуете.

- Какая пропускная способность сети ?
файлы передаются по ssh со скоростью 50Мбайт/сек
- Какой сетевой адаптер, используется между серверами HDR & RSS ?
гигабитные сетевушки hp на обоих серверах
- Какая версия IDS ?
IDS 11.50 FX6, red hat linux 5.5 на обоих серверах


NETTYPE soctcp,1,50,NET <- DBSERVERALIASES ifx_hdr,ifx_rss - для репликационной пары (HDR-RSS).
Вадим,скажи пожалуйста,так прям и передавать параметры подключения,указав вместо DBSERVERALIASES ifx_hdr,ifx_rss алиасы серверов или это для моего понимания?

GVF112GVF,

не получилось((((

primary prime03
onconfig
DBSERVERNAME prime03
DBSERVERALIASES prime03int
...
NETTYPE onipcstr,1,50,CPU
NETTYPE onsoctcp,1,50,NET
NETTYPE sqlmux

В файле конфигурации sqlhosts (на primary):
...
prime03 onipcstr 192.168.1.1 1526
prime03int onsoctcp 192.168.201.1 sqlexec b=16384
prime02int onsoctcp 192.168.201.2 sqlexec b=16384

В файле
/etc/services
sqlexec 9088/tcp
sqlexec 9088/udp


secondary
onconfig
DBSERVERNAME prime02
DBSERVERALIASES prime02int
...
NETTYPE onipcstr,1,50,CPU
NETTYPE onsoctcp,1,50,NET
NETTYPE sqlmux

В файле конфигурации sqlhosts (на primary):
...
prime02 onipcstr 192.168.1.1 1526
prime02int onsoctcp 192.168.201.1 sqlexec b=16384
prime03int onsoctcp 192.168.201.2 sqlexec b=16384

В файле
/etc/services
sqlexec 9088/tcp
sqlexec 9088/udp


Остальные параметры поставил как Вы указали в пред сообщении.

Подключил реплику,но коммуникационный буфер не изменился и также репликация падает как и раньше(((((

Вот с основного лог

Local server type: Primary
Index page logging status: Enabled
Index page logging was enabled at: 2011/05/10 15:32:03
Number of RSS servers: 1

RSS Server information:

RSS Server control block: 0x3c4848780
RSS server name: prime02int
RSS server status: Active
RSS connection status: Connected
Log transmission status: Active
Next log page to send(log id,page): 943,32032
Last log page acked(log id,page): 943,31999
Time of Last Acknowledgement: 2011-05-23.11:03:28
Pending Log Pages to be ACKed: 1
Approximate Log Page Backlog:148708
Sequence number of next buffer to send: 1066
Sequence number of last buffer acked: 1064
Supports Proxy Writes: N


И на этом репликация перестает работать( в логе onstat -m ничего нет

вот onstat -m с основного
11:01:04 DELAY_APPLY has been set to 20M on server prime02
11:01:04 RSS prime02int has resumed acknowledgement
11:01:04 RSS prime02 resumed acknowledging log transmission
11:01:59 RSS prime02 is not acknowledging log transmission
11:02:10 RSS prime02 resumed acknowledging log transmission
11:02:23 Checkpoint Completed: duration was 1 seconds.
11:02:23 Mon May 23 - loguniq 943, logpos 0x2c9c2018, timestamp: 0x93687a3 Interval: 94569


и с вторичного

11:00:35 Cleared 50697 MB of the physical and logical logs in 244 seconds
11:00:35 B-tree scanners disabled.
11:00:36 DR: RSS secondary server operational
11:00:36 Secondary Delay or Stop Apply: Using the directory /mnt/ids_data2/RSSreplica/ifmxlog_0.
11:00:36 A Request to reset the log position to 943:0 was sent to the primary server.


Помогите плиз

Денис_88,

уменьшил drinterval до 2 и репликация стала падать еще быстрее.раньше она хотя бы успевала догнать основной,а теперь падает спустя 3минуты после включения

Вадим,

Вы не поверете,но hdr репликация с этими параметрами работает нормально даже при высоконагруженном опер процессе.
Ведь RSS это тоже hdr но с возможностью задержки наката(т.е. наоборот легче чем hdr и использует duplex в сети вместо того,чтобы ждать подтверждения о доставке,как это делает hdr),но почему логи не передаются нормально при RSS?

GVF112GVF,

Вадим,а можно Вас попросить выложить весь текст бага,а то я не могу открыть.

Спасибо

Вадим,

а можно еще 1 маленький вопрос по RSS для понимания?

активно заполняются HDR Buffer'а,но не успевают передаваться с такой же скоростью как заполняются.

Что делает сервер?Он ставит эти буфера в очередь отправки и потихоньку отправляет с пропускной способностью сети?

А если буфер должен быть накачен на вторичном спустя 10М (delay_apply),но он еще не успел передаться?Получается,что нарушена целостность репликации.

При постановке буфера в очередь сервер считает что он его уже очистил,т.е. он параметр DRINTERVAL не включает в себя время ожидания на отправку?

Спасибо большое

GVF112GVF,

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

Можно было бы грешить на сеть или на параметры репликации,но при точно таких же параметрах работает hdr репликация без каких-либо проблем.
Какова разница между асинхронной hdr и RSS???только ли лишь в возможности задержки наката?

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

Единственное на что я предполагаю: при RSS коммуникационный буфер передавался раз в 10 секунд (это было видно с помощью onstat -g rss verbose),а здесь возможно он передается быстрее,тем самым быстрее освобождая hdr буфера для новой записи и sqlexec вместе с процессами записи в лог не находятся в режиме ожидания.

Завтра попробую посмотреть передачу логов при HDR.Правда пока не знаю как.

если подскажете с лету аналог onstat -g rss verbose для hdr-буду признателен..

Спасибо