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

Откуда:
Сообщений: 70
гуру, подскажите размер передаваемого за раз пакета(hdr buffer) равен log_buffer или stmt_cach_size?

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

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

Прав ли я?

Спасибо
20 май 11, 16:16    [10685670]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
GVF112GVF
Guest
Денис_88
гуру, подскажите размер передаваемого за раз пакета(hdr buffer) равен log_buffer или stmt_cach_size?

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

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

Прав ли я?

Спасибо


Размер LOGBUFF (Logical Log Buffer), определяет и размер репликационного буфера (Replication Buffer) в Shared Memory
(Logical Log Buffer == Replication Buffer).

PS: The logical log buffers should be sized to hold the contents of an average transaction to minimize the possibility of losing committed data (BUFFERED) or of simply wasting memory (UNBUFFERED) to no purpose.

Далее, HDR Threads:
- RSS_send: using full duplex communication (i.e. without waiting for the receipt of an acknowledgement),
this thread sends log pages to an RSS server (runs on the primary server).
- RSS_recv: receives the log pages from the primary server (runs on the RSS server) .
- RSS_apply: copies the contents of the reception buffer to the recover buffer(runs on the RSS server).

Не совсем понятно, почему у Вас передача на вторичный, отваливается по параметру drtimeout (проблемы с сетью - задержки,
низкая пропускная способность) ?!
Другой вопрос - почему вторичный сервер, накатывает долго ?!
Какой уровень журналирования используется для баз данных - BUFFERED/UNBUFFERED ?!

Для начала, попробуйте увеличить значение - OFF_RECVRY_THREADS на RSS-сервере.

На первичном сервере, можно попробовать:
1) DRINTERVAL = 0 <- Replication Buffer, будет отправляться на RSS-сервер по мере его заполнения.
2) Увеличит значение параметра - drtimeout.
3) BUFFERED -> UNBUFFERED <- здесь осторожно !!!!

С уважением,
Вадим.
20 май 11, 23:24    [10687541]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
GVF112GVF
Guest
Денис_88,

Как правило,
- OFF_RECVRY_THREADS =3 * CPU VPS, но не мешьше 11 !!!
- LOGBUFF = 1024
- в SQLHOSTS для ALIAS HDR и RSS, можно задать размер коммуникационного буфера b=''
- TEMPTAB_NOLOG = 1 (на всех RSS узлах).
- RSS_FLOW_CONTROL - Flow control provides a way to limit log activity on the primary server so that RS secondary servers in the cluster can catch up their log replay positions (очень осторожно - http://planetids.com/content/rssflowcontrol-current-restriction-max-2-gig) !!!

Более подробно см. - http://www.iiug.org/conf11/C10-Privett-Best_Practices_for_Cluster_Environments.pdf

С уважением,
Вадим.
21 май 11, 00:04    [10687672]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
Денис_88
Member

Откуда:
Сообщений: 70
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 не могу использовать этот параметр,так как проблема не в накатывании логов,а в передаче.



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

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

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

Спасибо большое за любую помощь
22 май 11, 17:53    [10690704]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
GVF112GVF
Guest
Денис_88,
...

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

- Какая пропускная способность сети ?
- Какой сетевой адаптер, используется между серверами HDR & RSS ?
- Какая версия IDS ?

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

Думаю, что будет достаточно - OFF_RECVRY_THREADS =50 (нужно уменьшить значение с 200 до 50).

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

Попробуй установить - DRINTERVAL=2

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


Я не знаю, зачем Вы устанавили такое значение для NETTYPE onsoctcp,8,150,CPU ?!

На мой взгляд, можно рассмотреть слеующие значения

NETTYPE ipcshm,1,50,CPU <- DBSERVERNAME ifx_online - для административного доступа .
NETTYPE soctcp,8,150,NET <- DBSERVERALIASES ifx_online_client - для клиентских соединений через стек TCP/IP.
NETTYPE soctcp,1,50,NET <- DBSERVERALIASES ifx_hdr,ifx_rss - для репликационной пары (HDR-RSS).
...
# NETTYPE sqlmux <- только для UNIX систем (Multiplexed connections).
...
FASTPOLL 1 <- if you have more than 300 concurrent connections with the database server, you can enable the FASTPOLL configuration parameter for better performance.
...
NET_IO_TIMEOUT_ALARM 4
..
Число и тип VPCLASS, надеюсь Вы установите сами. Для UNIX систем, можно рассмотреть использование -
Multiplexed connections (sqlmux) и т.д.

Коммуникационный размер буфера следует изменить в файле sqlhosts, только для пары репликационных серверов -
DBSERVERALIASES ifx_hdr,ifx_rss

Для репликационной пары (DBSERVERALIASES ifx_hdr,ifx_rss), следует определить отдельный сетевой интерфейс и размер
коммуникационнго буфера.

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

Он и не должен менять, пока Вы его не измените в файле конфигурации sqlhosts для сервер из DBSERVERALIASES (b='').
Размер параметра b='', должен коррелироваться с параметрами окна фрейма для стека TCP/IP.

По умолчанию, размер b='4096' (bytes). Вы можете его увеличить b='16384'.
On many operating systems, the maximum buffer size supported for TCP/IP is 16 KB. To determine the maximum allowable buffer size, see the documentation for your operating system or contact the technical-support services for the vendor of your platform.
...
Между серверами есть 2 разные сети:одна внутренняя кластерная без фаерволов и работает в 1 свитче,а вторая внешняя,но репликация падает и там и там одинаково. Задержек и перебоев в сетях нет.Скорость около 50Мбит/с постоянна.

Скорость 50 Mбит/c - это ~ 5 Мб в секунду! С какой скоростью, заполняются логические журналы
на первичном сервере HDR ?!!! Если больше 5 Мб - тогда понятно ... нужна устанавливать 100 МБ сетевую карту ... :)

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

Проблема передачи логов - это скорее всего, проблема пропускной способности сети.
На всякий случай - If anyone is looking to use RSS_FLOW_CONTROL (in 11.50FC8 and 11.70) there is currently one restriction that I uncovered that has been entered as a defect - https://www.ibm.com/developerworks/mydeveloperworks/blogs/jfilippi_informix/entry/rss_flow_control_current_restriction_max_2_gig?lang=en

Параметр RSS_FLOW_CONTROL - очень важен, когда вторичный сервер не успевает накатывать логи.
Какая у Вас версия Informix ?!

PS: Network buffer pools - http://publib.boulder.ibm.com/infocenter/idshelp/v117/topic/com.ibm.perf.doc/ids_prf_110.htm

С уважением,
Вадим.
22 май 11, 21:22    [10691080]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
Денис_88
Member

Откуда:
Сообщений: 70
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 алиасы серверов или это для моего понимания?
22 май 11, 23:50    [10691582]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
GVF112GVF
Guest
Денис_88
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 алиасы серверов или это для моего понимания?


Обратите Ваше внимание на пункты 5) и 8) в Machine notes for Linux x86_64 - http://publib.boulder.ibm.com/infocenter/idshelp/v115/topic/com.ibm.relnotes.doc/ids_1150xc6/mach/ids_machine_notes_11.50.lin64.html

В файле конфигурации ONCONFIG (на primary):
...
DBSERVERNAME ifx_online
DBSERVERALIASES ifx_online_client,ifx_hdr
...
NETTYPE onipcstr,1,50,CPU
NETTYPE onsoctcp,8,150,NET
NETTYPE onsoctcp,1,50,NET
...

В файле конфигурации sqlhosts (на primary):
...
ifx_online onipcstr 192.168.1.1 ifx_online
ifx_online_client onsoctcp 192.168.1.1 sqlexec
ifx_hdr onsoctcp 192.168.201.1 sqlexec b=16384
ifx_rss onsoctcp 192.168.201.2 sqlexec b=16384
...

Вообще-то, лучше объединять все DBSERVERALIASES в отдельную группу и использовать Connection Manager для
управления доступом клиентов к серверам в группе ... MACH11 ... :)

С уважением,
Вадим.
23 май 11, 02:27    [10691949]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
Денис_88
Member

Откуда:
Сообщений: 70
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.


Помогите плиз
23 май 11, 11:13    [10692848]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
Денис_88
Member

Откуда:
Сообщений: 70
Денис_88,

уменьшил drinterval до 2 и репликация стала падать еще быстрее.раньше она хотя бы успевала догнать основной,а теперь падает спустя 3минуты после включения
23 май 11, 12:08    [10693319]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
Денис_88
Member

Откуда:
Сообщений: 70
Вадим,

Вы не поверете,но hdr репликация с этими параметрами работает нормально даже при высоконагруженном опер процессе.
Ведь RSS это тоже hdr но с возможностью задержки наката(т.е. наоборот легче чем hdr и использует duplex в сети вместо того,чтобы ждать подтверждения о доставке,как это делает hdr),но почему логи не передаются нормально при RSS?
23 май 11, 14:43    [10694620]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
GVF112GVF
Guest
Денис_88
Вадим,

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


Думаю, что это какой-то баг - Fix list for Informix 11.50.xC8 and PIDs 11.50.xC8W1 - 11.50.xC8W4
https://www-304.ibm.com/support/docview.wss?uid=swg27020411

For example: IC73455: RSS SECONDARY DOES NOT SYNC AFTER THE FLIP OF PRIMARY AND RSS SECONDARY
... workaround is to bounce the secondary.

С уважением,
Вадим.
23 май 11, 20:46    [10696813]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
Денис_88
Member

Откуда:
Сообщений: 70
GVF112GVF,

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

Спасибо
24 май 11, 11:37    [10698880]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
Денис_88
Member

Откуда:
Сообщений: 70
Вадим,

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

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

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

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

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

Спасибо большое
24 май 11, 12:25    [10699207]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
GVF112GVF
Guest
Денис_88
GVF112GVF,

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

Спасибо


Попробуй зайти на линк - https://www-304.ibm.com/support/docview.wss?uid=swg27020411
и выполнить поиск для RSS.

Fix list for Informix 11.50.xC8 and PIDs 11.50.xC8W1 - 11.50.xC8W4
------------------------------------------------------------------------------
IC74179 VALUES FOR THE ONCONFIG PARAMETER RSS_FLOW_CONTROL AT 2G AND ABOVE DO NOT WORK PROPERLY
IC67644 BTREE SCANNER THREAD IS ACTIVE BUT DISABLED AFTER SWITCHING HDR/RSS TO STANDARD TYPE
IC68057 LOCKS ON MACH11 NODES (HDR, RSS, SDS) DO NOT RAISE ERRORS, AND ARE NOT RESPECTED.
IC70316 RSS FAILS TO RE-CONNECT TO PRI WITH PRIMARY SMXSND THREAD IN COND WAIT SMX PIPE1
IC71885 PRIMARY SERVER SLOWDOWN INSERTION IN UNBUFFERED DATABASE WHEN RSS IS LOCATED ON SLOW NETWORK
---------------------------------------------

IC73455: RSS SECONDARY DOES NOT SYNC AFTER THE FLIP OF PRIMARY AND RSS SECONDARY

Error description:

After the flip of the primary and secondary RSS servers, RSS
secondary doesn't sync.

secondary onstat -g rss verbose shows:

Server Status : Active
Source server name: <primary>
Connection status: Connected
Last log page received(log id, page): 64,-1
Sequence number of last buffer received: 0
Sequence number of last buffer acked: 0

On the new primary: onstat -g rss verbose shows:

RSS sever name: <secondary>
RSS server status: Active
RSS connection status: Connected
Log transmission status: Active
Next log page to send(log id, page) : 64,50
Last log page acked(log id, page) : 0,0
Pending Log Pages to be ACKed: 50
Approcimate Log Page Backlog:50
Sequence number of the next buffer to send: 11
Sequence number of the last buffer acked: 0

primary has sent 50 pages, (64,50) and the RSS secondary is at
(64,-1) so RSS secondary did not process any of the log pages.
---------------------------------------------------------------------------

С уважением,
Вадим.
24 май 11, 22:01    [10702991]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
GVF112GVF
Guest
Денис_88
Вадим,

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

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

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

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

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

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


Если нет доступного HDR-буфера, тогда sqlexec-поток, выполнющий копирование из буфера логического журнала в HDR-буфер,
переходит в режим ожидания (до момента, когда HDR-буфер будет доступен). Все остальные потоки, которые пишут в логический журнал, так же будут находиться в состоянии ожидания.

HDR-буфер, будет передан на вторичный сервер, когда:
- используется асинхронный режим репликации HDR(onconfig: DRINTERVAL -1), или
- данные логического журнала содержат контрольную точку, или
- HDR-буфер заполнен, или
- используется асинхронный режим репликации HDR и DRINTERVAL достигнут (onconfig: DRINTERVAL >= 0)

В данном случае, нарушение целостности нет.

Для RSS-репликации, используется специальный параметр - RSS_FLOW_CONTROL (Flow control provides a way to limit log activity on the primary server so that RS secondary servers in the cluster can catch up their log replay positions) и т.д.

С уважением,
Вадим.
24 май 11, 22:22    [10703056]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
Денис_88
Member

Откуда:
Сообщений: 70
GVF112GVF,

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

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

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

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

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

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

Спасибо
25 май 11, 00:40    [10703406]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
GVF112GVF
Guest
Денис_88
GVF112GVF,

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

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

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

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

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

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

Спасибо


Перечень багов Я привел для того, чтобы показать, что не все так просто и гладко с RSS ... ;)
Количество буферов логических журналов - фиксированное (всегда три).
Размер буфера репликации равен размеру буфера логических журналов и определяется значением параметра - LOGBUFF.

Отличие работы пары HDR/RSS от HDR на primary - в параметрах окружения (конфигурации) и используемых потоках.
Можно предположить следующее - либо что-то не так в окружении (например, RSS_FLOW_CONTROL, параметры OS, TCP/IP),
или очередной баг при работе с потоками на primary.

По умолчанию RSS_FLOW_CONTROL = 0 (Flow control is activated when the difference between the current log position and the most recent acknowledged log exceeds eight times the size of the log buffer.).

Попробуйте отключить его RSS_FLOW_CONTRO = -1

Если это не поможет, тогда нужно открывать PMR в IBM Technical Support.

Аналог onstat ...
onstat -g dri
onstat -g ath

Надеюсь, что дата и время на серверах (primary/rss) - одинаковые.

PS: мой рабочий IP заблокирован на sql.ru (могу отвечать вне рабочего времени).

С уважением,
Вадим.
25 май 11, 09:00    [10703792]     Ответить | Цитировать Сообщить модератору
 Re: размер передаваемого буфера при RSS  [new]
яфшуеі
Guest
Принципиальное различие HDR и RSS - передача БУФЕРОВ в первом случае и передача ЛОГОВ во втором.
Можно даже сказать, что у информикс есть несколько механизмов докатки транзакций.
Как минимум это:
1. Через буфер HDR когда сервера PRI и HDR синхронны.
2. Механизм передачи логов на тот же HDR, когда HDR докатывается в силу каких-то причин.
3. Механизм передачи логов на RSS.
4. Механизм передачи логов на SDS.
5. Логическое восстановление по архиву логов.

Дайте ссылку что все эти механихмы одинаковы.

Даже приведенные 1 и 2 как по мне разные. 1 работает быстрее чем 2.
2 работает быстрее чем 5.
При желании и возможности протестить различия найти можно.

Механизмы 1 и 2 наиболее старые и как по мне наиболее стабильные.

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

Кроме того, я б вам посоветовал еще раз почитать документацию.
Так как даже самое первое высказанное вами предположение/вопрос
"подскажите размер передаваемого за раз пакета(hdr buffer) равен log_buffer или stmt_cach_size?"
некорректно
25 май 11, 10:29    [10704338]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: размер передаваемого буфера при RSS  [new]
яфшуеі
Guest
яфшуеі
Принципиальное различие HDR и RSS - передача БУФЕРОВ в первом случае и передача ЛОГОВ во втором.
Можно даже сказать, что у информикс есть несколько механизмов докатки транзакций.
Как минимум это:
1. Через буфер HDR когда сервера PRI и HDR синхронны.
2. Механизм передачи логов на тот же HDR, когда HDR докатывается в силу каких-то причин.
3. Механизм передачи логов на RSS.
4. Механизм передачи логов на SDS.
5. Логическое восстановление по архиву логов.

Дайте ссылку что все эти механихмы одинаковы.

Даже приведенные 1 и 2 как по мне разные. 1 работает быстрее чем 2.
2 работает быстрее чем 5.
При желании и возможности протестить различия найти можно.

Механизмы 1 и 2 наиболее старые и как по мне наиболее стабильные.

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

Кроме того, я б вам посоветовал еще раз почитать документацию.
Так как даже самое первое высказанное вами предположение/вопрос
"подскажите размер передаваемого за раз пакета(hdr buffer) равен log_buffer или stmt_cach_size?"
некорректно


При определенніх условиях механизм 5 является самым быстрым :(
12 дек 17, 15:46    [21027644]     Ответить | Цитировать Сообщить модератору
Все форумы / Informix Ответить