RE: Log compression for replication ??
Posted in 2003
Topics: High Availability & Replication, Logging & Checkpoints
Jack, It's really hard to believe that HDR can cause a bad network problem. AFAIK the amount of data transferred should be close to the amount of data accumulated in logical logs. How often do Your logical logs switch of what is the size of the logical log on Your system? If You still feel that HDR is responsible for Your network problem, You can use dedicated physical network adapter for HDR on both machines and connect those adapters by dedicated network cable. You should attach dedicated IDS network listener to that dedicated network adapter on each machine. For better diagnostics, use different listener TCP port numbers for 'user' and 'replication' ports. ------------------------------------------ Alexey Sonkin Senior Database Administrator > -----Original Message----- > From: Jack A [mailto:hrehal@yahoo.com] > Sent: Thursday, August 14, 2003 11:02 PM > To: informix-list@iiug.org > Subject: Re: Log compression for replication ?? > > Oh no. I think i havent given you the complete picture. The backbone gets > used for a lot of stuff. There are many other applications that use the > back > bone apart from Informix users. Connections to the primary are working > fine. > There are no problems with that. But we have other servers here in the > head > office which are accessed using the same back bone by different users. > When > the purge runs and the network gets clogged, these users are the ones > which > have a problem. > > So seperating replicaton traffic from user traffic is really not my goal. > I > only want to minimize replication traffic any way I can. > > "Madison Pruet" <mpruet@comcast.net> wrote in message > news:Gp5%a.149060$o%2.64395@sccrnsc02... > > Jack, > > > > You should be able to separate the replication traffic from the user > traffic > > by setting up separate ports (listener threads), one for the HDR > traffic > > and the other for the user apps. > > > > I'm a bit puzzled by this, however. If the network bandwidth is the > cause > > of the problem, then I would expect only connections to the secondary to > be > > a problem, not the primary. Could it be that the real problem is that > the > > users are locking because the purge program is not committing often > enough > > and thus causing users to be in a wait state on rows to be deleted? > > > > > > "Jack A" <hrehal@yahoo.com> wrote in message > > news:5b83c3e5548b78f5201f76f39bc79d8d@news.teranews.com... > > > As I mentioned a few days ago, replication traffic has spiked up on > our > > > network. It was because of periodic purges that were running. This is > > > becoming a big issue in my company that we are eating up bandwidth > because > > > online users get bloced. Is there any way to have Informix compress > the > > logs > > > before they are shipped out to the secondary ? I've looked through the > > > manuals and havent found anything and was surprised. > > > > > > This might be a good enhancement to suggest to the Informix > development > > > group. > > > > > > TIA, > > > Jack > > > > > > > > > > sending to informix-list
We'd had HDR cause a port to close on a hardware firewall when running over a VPN - very irritating Alexey Sonkin wrote: > > Jack, > > It's really hard to believe that HDR can cause > a bad network problem. > > AFAIK the amount of data transferred should be close to the > amount of data accumulated in logical logs. > How often do Your logical logs switch of what is the size of the logical > log on Your system? > > If You still feel that HDR is responsible for Your network problem, > You can use dedicated physical network adapter for HDR on > both machines and connect those adapters by dedicated network cable. > You should attach dedicated IDS network listener to that dedicated > network adapter on each machine. > > For better diagnostics, use different listener TCP port > numbers for 'user' and 'replication' ports. > > ------------------------------------------ > Alexey Sonkin > Senior Database Administrator > > > -----Original Message----- > > From: Jack A [mailto:hrehal@yahoo.com] > > Sent: Thursday, August 14, 2003 11:02 PM > > To: informix-list@iiug.org > > Subject: Re: Log compression for replication ?? > > > > Oh no. I think i havent given you the complete picture. The backbone gets > > used for a lot of stuff. There are many other applications that use the > > back > > bone apart from Informix users. Connections to the primary are working > > fine. > > There are no problems with that. But we have other servers here in the > > head > > office which are accessed using the same back bone by different users. > > When > > the purge runs and the network gets clogged, these users are the ones > > which > > have a problem. > > > > So seperating replicaton traffic from user traffic is really not my goal. > > I > > only want to minimize replication traffic any way I can. > > > > "Madison Pruet" <mpruet@comcast.net> wrote in message > > news:Gp5%a.149060$o%2.64395@sccrnsc02... > > > Jack, > > > > > > You should be able to separate the replication traffic from the user > > traffic > > > by setting up separate ports (listener threads), one for the HDR > > traffic > > > and the other for the user apps. > > > > > > I'm a bit puzzled by this, however. If the network bandwidth is the > > cause > > > of the problem, then I would expect only connections to the secondary to > > be > > > a problem, not the primary. Could it be that the real problem is that > > the > > > users are locking because the purge program is not committing often > > enough > > > and thus causing users to be in a wait state on rows to be deleted? > > > > > > > > > "Jack A" <hrehal@yahoo.com> wrote in message > > > news:5b83c3e5548b78f5201f76f39bc79d8d@news.teranews.com... > > > > As I mentioned a few days ago, replication traffic has spiked up on > > our > > > > network. It was because of periodic purges that were running. This is > > > > becoming a big issue in my company that we are eating up bandwidth > > because > > > > online users get bloced. Is there any way to have Informix compress > > the > > > logs > > > > before they are shipped out to the secondary ? I've looked through the > > > > manuals and havent found anything and was surprised. > > > > > > > > This might be a good enhancement to suggest to the Informix > > development > > > > group. > > > > > > > > TIA, > > > > Jack > > > > > > > > > > > > > > > > sending to informix-list -- Paul Watson # Oninit Ltd # Growing old is mandatory Tel: +44 1436 672201 # Growing up is optional Fax: +44 1436 678693 # Mob: +44 7818 003457 # www.oninit.com #