Author Topic: Active / Passive setup - Who's doing what?  (Read 731 times)

jsquizz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 577
    • View Profile
Active / Passive setup - Who's doing what?
« on: January 24, 2024, 02:56:31 PM »
Hi Folks,

I saw some posts around here regarding HADR + CMOD, which were very old. I am wondering - Is anyone using HADR with the product?

My thought was-2 servers, \arscache mounted to both - then a primary and standby node. Data center 1 goes down, takeover on data center 2, and the data will be right there too.

I'm not a db2 dba and unfortunately i dont have access to one for this project.

I think that this might be a viable solution as long as replication is done properly, and only one arssockd is touching the database at the a time.

Dual loading is also an option I've seen many of the customers I've worked with do. My only concern is inconsistencies between data centers. Data center 1 goes down, docs queue, there's no recon process, things get messy - etc. I've usually seen custom coding put around it. I think overall the best solution probably is dual loading - especially since they mentioned their daily backups of the database, OS images, and cache

Unfortunately - zookeeper/purescale is not an option.

wondering what everyone thinks. Thanks in advance
#CMOD #DB2 #AFP2PDF #TSM #AIX #RHEL #AWS #AZURE #GCP #EVERYTHING

teera_aoo

  • Jr. Member
  • **
  • Posts: 18
    • View Profile
Re: Active / Passive setup - Who's doing what?
« Reply #1 on: February 29, 2024, 02:01:25 AM »
You may use DB2HADR for sync CMOD database, but you need another technic to managed arscache, one thing is storage replicate

But I never use DB2 HADR with CMOD, only storage replication for all (Both DB2, arscache)
I have some customer install CMOD, DB2 on 2 sites, and put data to SAN Storage.
In normal case, this storage will mounted on production, replicate to DR, and mount to DR on disaster case. (Then start services)

One issue that cannot prevent in this scenario is data corruption, destination will got same data from source storage.
Another point is RPO, since DB replicate by storage, so some last transaction that's incomplete may lost in rollforward/recover when start DB at DR site.

« Last Edit: February 29, 2024, 02:05:19 AM by teera_aoo »