1 / 26

Are You Ready for Changes In Your Cluster?

Are You Ready for Changes In Your Cluster?. Nicholas Geib Session: B06 Prasad Mujumdar IBM 05/16 4:40 PM. Agenda. Overview of the Informix Cluster Planned Cluster Changes Unplanned Cluster Changes Miscellaneous. What is an Informix Cluster?. Connection Manager.

caitir
Download Presentation

Are You Ready for Changes In Your Cluster?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Are You Ready for Changes In Your Cluster? Nicholas Geib Session: B06 Prasad Mujumdar IBM 05/16 4:40 PM

  2. Agenda Overview of the Informix Cluster Planned Cluster Changes Unplanned Cluster Changes Miscellaneous

  3. What is an Informix Cluster? Connection Manager • A set of Informix instances that are tightly coupled replicating logged data across network connections and/or share data using common storage subsystem • 1 primary + secondary(ies) • secondary types & quantities • HDR: 0 or 1 (since ver 6.0) • SDS: 0 or more (ver 11.10) • RSS: 0 or more (ver 11.10) • Perform updates on secondary • DML (11.50) • DDL (11.70) • or configure as read-only • aka “MACH11”, “MACH” Primary HDR Secondary Remote Standalone Secondary Shared Disk Secondary

  4. More About A Cluster Must run same Informix binaries If you plan to fail over to secondary it should be powerful enough to handle the load Secondary gets copy of all logged data Types of Secondaries SDS: very quick to set up, requires shared disk HDR: sync or async mode RSS: delay/stop apply, external backup Interoperates with Flexible Grid/Enterprise Replication Related binaries: oncmsm, ifxclone, cdr HDR: eliminate backlog during checkpoint with LOG_STAGING_DIR RSS: control flow control with RSS_FLOW_CONTROL

  5. Planned Cluster Changes Types of Changes Add a new secondary to cluster Work with ER start new domain expand existing domain Change secondary’s type Upgrade Informix

  6. Example: Introduce New Hardware Move to new hardware and/or OS in a risk-minimizing way AIX Power6 PRI: AIX Power6 RSS: AIX Power7 PRI: AIX Power7

  7. Make New Instance via Cloning • Given an existing server make a new… • Standard – a “snapshot” of the original • RSS server – automatically added to the cluster • New server has the same characteristics as the old one: • <db/sb/…>spaces, chunks • Schema (database, tables, indexes, etc.) and data • all data transferred as of that point in time • ER and RSS continue to receive updates • ONCONFIG settings (optional: change some) • No backup or restore required • Target can be on a different or the same machine • Requires • same hardware, OS, Informix version at source and target • source permits cloning (ENABLE_SNAPSHOT_COPY) • all chunks have been created on the target Clone standard standard Clone Primary RSS

  8. Start or Expand ER Add a new node to an existing domain ifxclone … -d ER Start a new domain requires an HDR or RSS in the cluster by “splitting” a cluster into two ER nodes 1st node: all other members of the original cluster 2nd node: HDR/RSS cdr check sec2er - is conversion possible? cdr start sec2er – split the HDR/RSS into a separate ER node Use cdr … sec2er with ifxclone ifxclone creates the RSS node sec2er transforms RSS into a new ER node Different from ifxclone ifxclone clones only the existing replication rules sec2er creates a new replicate between primary/secondary for every table Clone Node 1 Node 2

  9. Changing a Secondary’s Type PRI SDS HDR RSS standard Transition occurs online Transition involves server going offline

  10. Changing a Secondary’s Type * Transition involves server going offline

  11. HDR Changes To RSS PRI $ onmode -d add RSS <HDR> HDR $ onmode -d RSS <primary> To standard PRI $ onmode -d standard HDR $ onmode -d standard HDR RSS HDR standard

  12. RSS Changes To HDR RSS $ onmode -d secondary <primary> To standard RSS $ onmode -d standard HDR RSS RSS standard

  13. PRI Changes To standard Remove all secondaries Remove RSS: PRI $ onmode -d delete RSS <RSS> Remove HDR: PRI $ onmode -d standard HDR $ onmode -d standard Remove SDS: SDS $ onmode –ky Or PRI $ onmode -d clear SDS alias <PRI> PRI standard

  14. Planned Cluster Changes: Upgrading When conversion is NOT required Typical when upgrading to PID or fix pack, though exceptions exist (e.g. 11.50.xC4 TODO) 1) Shutdown CM 2) Bring cluster offline, ending with PRI 3) Upgrade Informix binaries etc. on all nodes 4) Bring cluster online, starting with PRI. Start CM. When conversion is required E.g. 11.50 to 11.70 Cluster must be rebuilt from level 0 backups Delete all secondary nodes before upgrading If 11.50.xC6 or later secondaries automatically removed during conversion.

  15. Rolling Upgrade The data remains online while the upgrade occurs Mixed Version ER Upgraded Cluster 11.70.xC2 Cluster11.70.xC1 ER 11.70.xC1 Primary ER Server 11.70.xC1ER Server Primary HDR ER Server 11.70.xC2ER Server HDR

  16. Example: Transparent Maintenance • Perform SW/HW maintenance without impacting clients Offline for maintenance PRI SDS PRI PRI SDS

  17. Unplanned Cluster Changes Use the CM to arbitrate failover Automatically monitors all servers in the cluster Promotes the new primary according to FOC Use multiple CMs to eliminate a single point of failure Put the CM on a different machines than cluster members To whom should I failover? Generally… Secondary that can handle same workload as PRI, i.e. about same CPU, memory, disk resources Secondary that is closest to PRI’s logical log position SDS, then HDR, then RSS (CM can even tell among RSSes)

  18. SDS Becomes PRI SDS $ onmode -d make primary <SDS> [-force] What happens to PRI? Taken offline What happens to other secondaries? New PRI connects to them, informs them of change. “-force”: don’t coordinate with PRI. Just do it. How do I get things back to the original state? Bring up orig-PRI as SDS. Failover to it. PRI SDS

  19. HDR Becomes PRI HDR $ onmode -d make primary <HDR> [-force] What happens to PRI? Taken offline What happens to other secondaries? SDS: go offline RSS: New PRI connects to them, informs them of change. How do I get things back to the original state? 1) srvA $ oninit -PHY 2) srvA $ onmode -d secondary srvB Now srvA is the HDR. 3) Fail over to srvA PRI (svrA) HDR (srvB)

  20. Secondary Offline During Failover? The secondary won’t automatically learn of the new PRI. HDR: $ oninit -PHY $ onmode -d secondary <PRI> RSS: $ oninit -PHY $ onmode -d RSS <PRI>

  21. Miscellaneous

  22. DDL on Secondary All statements except: CREATE DATABASE (with no logging) CREATE EXTERNAL TABLE CREATE RAW TABLE CREATE TEMP TABLE (with logging) CREATE XADATASOURCE CREATE XADATASOURCE TYPE DROP XADATASOURCE DROP XADATASOURCE TYPE UPDATE STATISTICS

  23. Transaction Survival What happens to txns? Primary: terminated Failover node: not affected Other secondaries: not affected Between failure of the primary and the promotion of the failover node a secondary suspends txns. When the failover is complete the suspended txns are sent to the failover node. Then the txns are resumed. If this process exceeds FAILOVER_TX_TIMEOUT seconds the txns are rolled back.

  24. Questions ?!? Template Presentation - Session Z99

  25. Thank You

  26. B06: Are You Ready For Changes In Your Cluster? Nicholas Geib Prasad Mujumdar njgeib@us.ibm.comprasadm@us.ibm.com

More Related