Core Mechanisms of Dameng Data Watch

Dameng (DM) database high availability clusters are established through the Data Watch framework. The foundational mechanism involves transmitting Redo logs from the primary instance to standby instances, which then apply these logs to maintain data synchronization. By manipulating specific parameters and interface configurations, DM supports various deployment topologies: Real-Time, Read-Write Split, Asynchronous, and Synchronous standby modes.

Daemon Process (dmwatcher)

The daemon process acts as the core communication bridge between database instances and the monitor. It handles instance monitoring, state broadcasting, failure detection, and automated recovery procedures.

Monitor (dmmonitor)

The monitor is a command-line utility interacting with the Data Watch API. It comes in two variants: standard monitor for observation and management, and confirmation monitor capable of issuing automatic failover commands during primary node outages.

Log Archiving Strategies

When operating in archive mode, the primary database writes Redo logs to local archive files and dispatches them to standby nodes. Depending on the transmission trigger point, archiving is categorized into four types:

• Real-Time Archiving (REALTIME): Logs are dispatched to the standby before being written to the local online log file.
• Timely Archiving (TIMELY): Logs are dispatched via the MAL system immediately after being written to the local online log file.
• Asynchronous Archiving (ASYNC): Log transmission is triggered by a scheduled timer, scanning local archives based on the standby's KEEP LSN.
• Synchronous Archiving (SYNC): Logs are dispatched via the MAL system after the local archive file is flushed to disk.

For Real-Time and Timely archiving, the system offers two response modes: Transaction Consistency (standby acknowledges after log replay completes) and High Performance (standby acknowledges immediately upon receiving logs). Real-Time defaults to High Performance, while Timely defaults to Transaction Consistency.

Configuration Parameters

Data Watch relies on several critical configuration files:

dm.ini (Instance Parameters)

Core parameters for any primary/standby node:

NODE_NAME       = PRI_GRP_A   # Unique instance identifier
DB_PORT         = 5236        # Database listening port
WATCHER_TIMEOUT = 60          # Daemon communication timeout
ALTER_MODE_REST = 0           # Restrict manual mode/status modifications
OFFLINE_TS_REST = 2           # Prevent standby tablespace offline
MAL_ENABLED     = 1           # Enable MAL system
ARCH_ENABLED    = 1           # Enable archive configuration
LOG_SEND_STAT   = 64          # Track recent 64 log dispatches

dmmal.ini (MAL Network Configuration)

Must be consistent across all nodes. Defines internal communication endpoints:

MAL_CHECK_PERIOD     = 5
MAL_FAIL_THRESHOLD   = 5
[PRI_NODE_A]
  MAL_INST_NAME     = PRI_GRP_A
  MAL_HOST          = 10.0.1.11
  MAL_PORT          = 61141
  MAL_INST_HOST     = 10.0.2.11
  MAL_INST_PORT     = 5236
  MAL_DW_PORT       = 52141
  MAL_INST_DW_PORT  = 33141

[STB_NODE_B]
  MAL_INST_NAME     = STB_GRP_B
  MAL_HOST          = 10.0.1.12
  MAL_PORT          = 61142
  MAL_INST_HOST     = 10.0.2.12
  MAL_INST_PORT     = 5237
  MAL_DW_PORT       = 52142
  MAL_INST_DW_PORT  = 33142

dmarch.ini (Archive Configuration)

Controls log archiving behavior. The ARCH_WAIT_APPLY parameter dictates the response mode (0 for High Performance, 1 for Transaction Consistency). Archive names cannot use the reserved word STANDBY_ARCHIVE.

[ARCH_REALTIME1]
ARCH_TYPE         = REALTIME
ARCH_DEST         = STB_GRP_B

[ARCH_LOCAL]
ARCH_TYPE         = LOCAL
ARCH_DEST         = /opt/dameng/arch
ARCH_FILE_LIMIT   = 256
ARCH_DISK_LIMIT   = 0

dmwatcher.ini (Daemon Configuration)

Defines failover and protection logic:

[GRP_ALPHA]
DW_TYPE           = GLOBAL
DW_MODE           = AUTO
DW_FAIL_TIMEOUT   = 15
INST_RECOVER_GAP  = 60
INST_FAIL_TIMEOUT = 15
INST_CLUSTER_ID   = 998877
INST_CONFIG_PATH  = /opt/dameng/dm.ini
INST_AUTOSTART    = 1
INST_START_CMD    = /opt/dameng/bin/dmserver
LOG_SEND_LAG      = 0
LOG_APPLY_LAG     = 0

dmmonitor.ini (Monitor Configuration)

Specifies monitor behavior and daemon connection details:

MON_CONFIRM_MODE  = 1
MON_LOG_DIR       = /opt/dameng/log
MON_LOG_INTERVAL  = 60
MON_LOG_MAX_SIZE  = 32
MON_LOG_TOTAL_MAX = 0
[GRP_ALPHA]
MON_CLUSTER_ID    = 998877
MON_DW_IP         = 10.0.1.11:52141
MON_DW_IP         = 10.0.1.12:52142

dmtimer.ini (Timer Configuration)

Used primarily for asynchronous standby scheduling. Example triggering daily at midnight:

[ASYNC_SCHEDULE]
TYPE                    = 2
FREQ_INTERVAL           = 1
FREQ_SUB_INTERVAL       = 0
FREQ_MINUTE_INTERVAL    = 0
START_TIME              = 00:00:00
END_TIME                = 00:00:00
DURING_START            = 2023-01-01 00:00:00
DURING_END              = 9999-12-31 23:59:59
NO_END_DATE_FLAG        = 1
DESCRIPTION             = Async Daily Sync
IS_ACTIVE               = 1

Cluster Implementations

Common Setup Procedures

All Data Watch topologies share foundational setup steps: restoring a backup to create the standby, configuring parameter files, setting the OGUID and database role, mounting the instances, and starting the daemons.

SP_SET_PARA_VALUE(1, 'ALTER_MODE_REST', 1);
sp_set_oguid(998877); 
alter database primary;
SP_SET_PARA_VALUE(1, 'ALTER_MODE_REST', 0); 

Real-Time Primary-Standby

Configures ARCH_TYPE = REALTIME in dmarch.ini. By default, this operates in High Performance mode (ARCH_WAIT_APPLY=0), ensuring primary responsiveness.

Read-Write Separation Cluster

Typically relies on Timely archiving (ARCH_TYPE = TIMELY) defaulting to Transaction Consistency mode (ARCH_WAIT_APPLY=1). Client interfaces must be configured to route transactions appropriately:

• JDBC: jdbc:dm://10.0.1.11:5236?rwSeparate=1&rwPercent=20
• ODBC: DSN=DM8;UID=SYSDBA;PWD=PWD;TCP_PORT=5236;RW_SEPARATE=TRUE;RW_SEPARATE_PERCENT=25
• dmPython: conn = dmPython.connect(rwseparate=True, rwseparate_percent=25)

Asynchronous Standby

Deployed to offload reporting tasks without strict latency requirements. Requires enabling TIMER_INI = 1 in dm.ini, adding the async node to dmmal.ini, configuring ARCH_TYPE = ASYNC with the timer name in dmarch.ini, and defining the schedule in dmtimer.ini. Async standbords do not support automatic failover and must use DW_MODE = MANUAL and DW_TYPE = LOCAL.

Synchronous Standby

Configured via ARCH_TYPE = SYNC in dmarch.ini, dispatching logs only after the local archive is saved. Like asynchronous standbys, synchronous standbys do not support automatic failover and require local daemon protection.

Cross-Database Replication Comparison