DM集群搭建与数据迁移

DM集群搭建

数据守护

DM 数据守护（Data Watch）是一种集成化的高可用、高性能数据库解决方案，是数据库异地容灾的首选方案。通过部署 DM 数据守护，可以在硬件故障（如磁盘损坏）、自然灾害（地震、火灾）等极端情况下，避免数据损坏、丢失，保障数据安全，并且可以快速恢复数据库服务，满足用户不间断提供数据库服务的要求。与常规的数据库备份（Backup）、还原（Restore）技术相比，数据守护可以更快地恢复数据库服务。随着数据规模不断增长，通过还原手段恢复数据，往往需要数个小时、甚至更长时间，而数据守护基本不受数据规模的影响，只需数秒时间就可以将备库切换为主库对外提供数据库服务。

1.1 数据守护概述

DM数据守护系统主要由主库、备库、Redo日志、Redo日志传输、Redo日志重演、守护进程（dmwatcher）、监视器（dmmonitor）组成。

DM数据守护实现原理：将主库（生产库）产生的Redo日志传输到备库，备库接收并重新应用Redo日志，从而实现备库与主库的数据同步。DM数据守护的核心思想是监控数据库状态，获取主、备库数据同步情况，为Redo日志传输与重演过程中出现的各种异常情况提供一系列的解决方案。

DM数据守护可以配置成实时主备、MPP主备、读写分离、DSC守护。

1.2 数据守护模式

• Normal模式：提供正常的数据库服务，操作没有限制。正常生成本地归档，但不发送实时归档（Realtime）、即时归档（Timely）和异步归档（Async）。
• Primary模式：提供正常的数据库服务，操作有极少限制。正常生成本地归档，支持实时归档（Realtime）、即时归档（Timely）和异步归档（Async）。Primary模式下，对临时表空间以外的所有的数据库对象的修改操作都强制生成Redo日志。
• Standby模式：可以执行数据库备份、查询等只读数据库操作。正常生成本地归档，正常发送异步归档Redo日志；但实时归档（Realtime）、即时归档（Timely）均强制失效。该模式下时间触发器、事件触发器等都失效。

1.3 数据守护基本概念

1. 主库即Primary模式：提供完整数据库服务的实例，一般来说主库是用来直接支撑应用系统的生产库。
2. 备库即Standby模式：提供只读数据库服务的实例。备库除了用于容灾，还可以提供备份、查询等只读功能，并且备库还支持临时表的Insert/Delete/Update操作。
3. Redo日志：是数据守护的实现基础，数据库中DML、DDL等操作最终都会体现为对某一个或者多个物理数据页的修改，因此备库通过重做Redo日志可以与主库数据保持一致。日志传输：主库通过MAL系统发送Redo日志到备库，Redo日志以日志包为单位。日志重演：备库收到主库发送的Redo日志后，在物理数据页上，重新修改数据。守护进程
4. 守护进程（dmwatcher）是数据守护系统的核心工具，监控数据库实例的运行状态和主备库数据同步情况，在出现故障时启动各种处理预案。守护进程是各种消息的中转站，接收数据库实例、其他守护进程、以及监视器发送的各种消息；同时，守护进程也会将收到的数据库实例消息转发给其他守护进程和监视器。守护进程必须和被守护的数据库实例部署在同一台机器上。

• 数据库实例向本地守护进程发送信息，接收本地守护进程的消息和命令；
• 监视器（dmmonitor）接收守护进程的消息，并向守护进程发送命令；
• 守护进程解析并执行监视器发起的各种命令（Switchover/Takeover/Opendatabase等），并在必要时通知数据库实例执行相应的操作；
• 数据库实例与监视器之间没有直接的消息交互

1. 监视器（dmmonitor）：用来监控守护系统内守护进程、数据库实例信息，执行用户输入命令、监控实例故障、实现自动切换等。监视器一般配置在数据库实例和守护进程以外的机器上。

1.4 数据守护状态

Startup状态：系统刚启动时设置为Startup状态。

After Redo状态：系统启动过程中联机日志重做完成后，回滚活动事务前设置为After Redo状态。非Standby模式的实例在执行alter database open操作前，也会将系统设置为After Redo状态。

Open状态：数据库处于正常提供服务的状态，但不能进行归档配置等操作。

Mount状态：数据库在Mount状态下，不能修改数据，不能访问表、视图等数据库对象，但可以执行修改归档配置、控制文件和修改数据库模式等操作，也可以执行一些不修改数据库内容的操作，比如查询动态视图或者一些只读的系统过程。

Suspend状态：数据库在Suspend状态下，可以访问数据库对象，甚至可以修改数据，但限制Redo日志刷盘，一旦执行COMMIT等触发Redo日志刷盘的操作时，当前操作将被挂起。

Shutdown状态：实例正常退出时设置为Shutdown状态。

1.5 数据守护归档

归档是实现数据守护系统的重要技术手段，根据功能与实现方式的不同，DM数据库的归档可以分为5类：本地归档、远程归档、实时归档、即时归档和异步归档。

LOCAL：将Redo日志写入到本地归档日志文件的过程。

REMOTE：将归档日志发送到远程实例保存(DSC集群)

REALTIME：实时归档将主库产生的Redo日志通过MAL系统传递到备库，实时归档是实时主备和MPP主备的实现基础。

TIMELY：即时归档在主库将Redo日志写入联机日志文件后，通过MAL系统将Redo日志发送到备库。即时归档与实时归档的主要区别是Redo日志的发送时机不同。

ASYNC：异步归档由主、备库上配置的定时器触发，根据异步备库的KEEPLSN信息，扫描本地归档目录获取Redo日志，并通过MAL系统将Redo日志发送到异步备库。Ø本地归档、实时归档和即时归档均包含两种状态：Valid和Invalid。异步归档只有Valid一种归档状态。Valid归档有效，正常执行各种数据库归档操作；Invalid归档无效，主数据库不发送联机Redo日志到备数据库

2. 读写分离

读写分离集群是基于即时归档或实时归档实现的高性能数据库集群，不但提供数据保护、容灾等数据守护基本功能，还具有读写操作自动分离、负载均衡等特性。读写分离集群最多可以配置 8 个即时备库或 8 个实时备库，提供数据同步、备库故障自动处理、故障恢复自动数据同步等功能，也支持自动故障切换和手动故障切换两种守护模式。具体流程包括数据准备，配置主库，启动主库，配置备库，启动备库，配置监视器。

2.1 数据准备

1.正常关闭数据库

2.进行脱机备份

./dmrman CTLSTMT=“BACKUP DATABASE ‘/data/sdc/zsn/zb1/dm.ini’ FULL TO BACKUP_FILE1 BACKUPSET ‘/data/sdc/zsn/zb1_bak’” use_ap=2

3.拷贝备份文件到备库所在机器

scp -r /data/sdc/zsn/zb1_bak test@192.168.100.118:/data/sdc/zsn

4.执行脱机数据库还原与恢复

2.2 配置主库

1.配置dm.ini

2.配置 dmmal.ini

3.配置 dmarch.ini

4.配置 dmwatcher.ini

2.3 启动主库

1.启动主库

./dmserver /data/sdc/zsn/zb1/dm.ini mount

2.设置OGUID

启动命令行工具DIsql，登录主库设置OGUID值。

3.修改数据库模式

启动命令行工具DIsql，登录主库修改数据库为Primary模式

2.4 配置备库

同主库流程

2.5 启动备库

1.启动备库

./dmserver /data/sdc/zsn/zb1/dm.ini mount

2.设置OGUID

启动命令行工具DIsql，登录备库设置OGUID值为1191181

3.设置备库模式

2.5 配置监视器

修改dmmonitor.ini配置确认监视器，其中MON_DW_IP中的IP和PORT和dmmal.ini中的MAL_HOST和MAL_DW_PORT配置项保持一致。

2.6 读写分离搭建

1.启动主备守护进程

./dmwatcher /data/sdc/zsn/zb1/dmwatcher.ini

2.启动监视器

./dmmonitor /data/sdc/zsn/zb1/dmmonitor.ini

3. DMDSC(DM8)

DM 共享存储数据库集群的英文全称 DM Data Shared Cluster，简称 DMDSC。DM 共享存储数据库集群，允许多个数据库实例同时访问、操作同一数据库，具有高可用、高性能、负载均衡等特性。DMDSC 支持故障自动切换和故障自动重加入，某一个数据库实例故障后，不会导致数据库服务无法提供。

3.1 DMDSC概述

DMDSC 集群是一个多实例、单数据库的系统。多个数据库实例可以同时访问、修改同一个数据库的数据。用户可以登录集群中的任意一个数据库实例，获得完整的数据库服务。数据文件、控制文件在集群系统中只有一份，不论有几个节点，这些节点都平等地使用这些文件，这些文件保存在共享存储上。每个节点有自己独立的联机日志和归档日志，其中联机日志保存在共享存储上，归档日志可以保存在本地存储上也可以保存在共享存储上。

scp -r /data/sdc/zsn/zb1_bak test@192.168.100.118:/data/sdc/zsn

4.执行脱机数据库还原与恢复

3.2 DMDSC组件

1. DMCSS（Dameng Cluster Synchronization Services）达梦集群同步服务，使用DMASM集群或DMDSC集群都必须要配置DMCSS服务。在DMASM集群或DMDSC集群中，每个节点都需要配置一个DMCSS服务。这些DMCSS服务自身也构成一个集群，DMCSS集群中负责监控、管理整个DMASM集群和DMDSC集群的节点称为控制节点(control node)，其他DMCSS节点称为普通节点(normal node)。DMCSS普通节点不参与DMASM集群和DMDSC集群管理，当DMCSS控制节点故障时，会从活动的普通节点中重新选取一个DMCSS控制节点。DMCSS主要功能包括：写入心跳信息、选举DMCSS控制节点、选取DMASM/DMDSC控制节点、管理被监控对象的启动流程、集群状态监控、节点故障处理、节点重加入等，DMCSS还可以接收并执行DMCSSM指令。

2. DMCSSM（DM Cluster Synchronization Services Monitor）是DM集群监视器的简称。DMCSSM与DMCSS相互通信，获取并监控整个集群系统的状态信息。DMCSSM还提供了一系列的命令来管理、维护集群。同一个集群中，允许最多同时启动10个监视器，一般建议将监视器放在独立的第三方机器上。

3.配置 dmarch.ini

4.配置 dmwatcher.ini

3.3 DMDSC配置文件

与 DMDSC 相关的配置文件包括：

1.DMDCR_CFG.INI

2.DMDCR.INI

3.DMINIT.INI

4.MAL 系统配置文件（DMMAL.INI、DMASVRMAL.INI）

5.DM.INI

6.DMARCH.INI

达梦数据迁移

1. 概述

DM 数据库和 MySQL 体系结构上存在差异，SQL 语法也存在一定的差异。DM 数据库针对 MySQL 做了部分兼容性。但由于有根本性的差异，兼容度不高。从 MySQL 迁移到 DM 数据库，DM 数据库提供了自动数据迁移工具，但在开发级别还需要一定的人工干预。MySQL 到 DM 的移植主要有以下几个方面的工作：

1．分析待移植系统，确定移植对象。

2．通过数据迁移工具 DTS 完成常规数据库对象及数据的迁移。

3．通过人工完成 MSQL 的移植。

4．移植完成后对移植的结果进行校验，确保移植的完整性和正确性。5．对应用系统进行移植、测试和优化。

2. 移植准备

1.应用系统情况分析：包括操作系统，开发平台，数据库版本，需要移植的数据库对象。

2.数据库对象分析：分析系统中历史数据库中含有哪些表，包括业务表和系统表，以及关联结构。同时明确是否将所有数据表均导入国产化数据库，并提出解决方案。

3.初始化库，创建用户和表空间

3. 迁移过程

图1 mysql迁移dm工程创建

图2 选择迁移方式

图3 连接迁移数据源

图4 连接迁移数据目的端

图5 从数据源复制对象

图6 选择迁移对象

图7 审阅迁移任务

图8 执行迁移任务

图9 查看日志

图10 查看迁移报告

社区地址：https://eco.dameng.com/