Modify iptables - Upgrading CA API Gateways

[Anon Anon]

Hi,

 

I want to update a two gateways cluster from version 8.2 to 9.0. While reading how to do so I came across with this two sentences in two different sections of the document:

• Cluster Upgrade - Split the cluster: Configure the Primary node to block database access and replication traffic from the Secondary node (use iptables command and modify /etc/sysconfig/iptables configuration)
• Cluster Upgrade – Establish Replication: Configure the Primary node to permit the Secondary node to re-connect for database purposes (use iptables command and modify /etc/sysconfig/iptables configuration)

 

It's the first time I work with iptables and I'm not quite sure how to accomplish this two steps. Do I have to execute in first process this?

 

$ iptables -A INPUT -p tcp -m tcp --sport 3306 -j REJECT

 

And when doing the second one, execute this?

 

$ iptables -A INPUT -p tcp -m tcp --sport 3306 -j ACCEPT

 

Thanks in advance.

 

Best regards,

Andrés-J. Cremades

[Anon Anon]

Hi Andrés,

 

Port 3306 is used for querying the remote database. Port 3307 is used for the replication.

During the time of the upgrade you want to block any SQL traffic between the two machines. For that we recommend using:

 

iptables -I INPUT -i eth0 -p tcp -m tcp -s SECONDARY-IP --dport 3306 -j REJECT
iptables -I INPUT -i eth0 -p tcp -m tcp -s SECONDARY-IP --dport 3307 -j REJECT

In order to reverse that, use:

iptables -D INPUT -i eth0 -p tcp -m tcp -s SECONDARY-IP --dport 3306 -j REJECT
iptables -D INPUT -i eth0 -p tcp -m tcp -s SECONDARY-IP --dport 3307 -j REJECT

Instructions how to reinitialise replication, if broken:
https://na32.salesforce.com/kA00000000001mF

 

Can you point me to the document you’re using so I can request adding the above directly to the document?

 

—Samuel

Vote for my feature suggestions

[Anon Anon]

Hi Samuel,

 

Thanks for your helpful answer. The document is a pptx “Cluster Upgrade No Downtime”

 

Best Regards,

Andrés-J. Cremades

Attachment(s)

Layer 7 Cluster Upgrade No Downtime.pptx   256 KB 1 version

[Anon Anon]

Hi Andrés,

Please note that if you work according to the document, when restoring the replication you will lose the information added to the secondary database during the time the primary was inactive. When the secondary and processing nodes was active, audit records were written in the secondary database. When replication is restored, the primary database will be cloned to the secondary database and will wipe out the data added on the secondary while it was the only one running.

 

Our official documentation recommends another way to perform upgrade on cluster, but does not suggest a procedure to do it without downtime. I will send a request through our internal channels to amend it in a way that will also instruct how to do it without downtime, but if you could submit an 'idea' to the community to add it to the documentation as well, it would assist us prioritising it. I will be the first one to vote for that idea.

 

Thank you for bringing that up,

—Samuel

Vote for my feature suggestions