前言openGauss是一款高可靠、高性能、高安全、易运维的开源关系型数据库管理系统，然而其全功能部署对系统要求非常高。本实操教程能够使个人开发者以及高校师生能够以成本最小的方式快速将openGauss部署到华为云的ECS上，以便快速进行功能验证以及小规模数据库应用开发。本教程预计实现的目标：开通安装有CentOS 8.2的华为云ECS安装并启动openGauss 5.0.0 LTS放通公网访问（本文部署到25432端口）能够使用Navicat等数据库软件以PostgreSQL兼容的方式进行连接本教程仅供实验测试使用，安全性较低，请勿在生产环境按该教程部署一、 开通华为云ECS在华为云控制台中搜索弹性云服务器产品并购买相关参数解释说明与推荐区域：服务器所在的区域，不同区域定价差异较大，可以选择成本较低的区域如西南-贵阳一计费模式：若需要长期部署应用（如课程作业开发），推荐选择包月规格：服务器的配置，为了运行openGauss，内存必须2GB以上，推荐至少4GB，经测试若配置过低会导致数据库无法安装、运行或中途崩溃。成本较低的可以选择通用计算型s6（s6.medium.4），基础报价约86元每月。镜像：服务器预装的操作系统，openGauss只支持OpenEuler和CentOS系列。考虑到一些软件的支持性，本教程采用CentOS 8.2 64bit，尽管官方只说明能够在CentOS7.6上运行，但实测该系统也能够正常运行部署。系统盘：服务器运行的硬盘，若要节省成本可以选择高IO点击下一步（网络配置）网络、子网：保持默认配置即可安全组：为了能够使服务器能够在外网访问数据库端口，我们必须预先放通相关端口，本教程以部署在25432端口为例（修改了默认的端口以降低扫描器发现并爆破密码的几率），此外我们可以顺便放通22、80等常用端口（使用“一键放通常用端口”按钮）IP：为了公网访问，必须购买弹性IP。若服务器应用流量不大，推荐按流量计费，带宽可以选最高的（300M），建议勾选“随实例释放”避免在服务器过期后继续计费。按带宽计费成本非常高，不建议测试使用。点击下一步（高级配置）登录凭证：自行设定云备份：为节省成本可以关闭（不购买）支付：拥有基座课程代金券的同学可以使用代金券连续购买多个月，节省部署成本。（按流量计费的服务器产生的流量可能仍会额外消耗余额）至此，华为云ECS已经创建完成二、安装openGauss创建数据库专用账户openGauss的安全性设计必须以root以外的用户运行首先用刚才的凭证使用root用户连接到服务器在终端中运行以下命令groupadd dbgroup useradd -g dbgroup omm passwd omm 输入你的omm账户密码 这创建了一个omm账户以及一个用户组下载openGauss下载、解压并调整相关文件权限curl -o opengauss.tar.gz https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.0.0/x86/openGauss-5.0.0-CentOS-64bit-all.tar.gz mkdir /opt/software/ mkdir /opt/software/openGauss tar -xvf opengauss.tar.gz -C /opt/software/ cd /opt/software/ tar -jxf openGauss-5.0.0-CentOS-64bit.tar.bz2 -C /opt/software/openGauss chown -R omm /opt/software/ 安装依赖对于本文档中的CentOS 8，由于已经停止支持，我们需要切换yum源，以清华大学源为例minorver=8.5.2111 sudo sed -e "s|^mirrorlist=|#mirrorlist=|g" \ -e "s|^#baseurl=http://mirror.centos.org/\$contentdir/\$releasever|baseurl=https://mirrors.tuna.tsinghua.edu.cn/centos-vault/$minorver|g" \ -i.bak \ /etc/yum.repos.d/CentOS-*.repo CentOS 8安装供CentOS 7.6使用的OpenGauss会遇到一些问题，我们必须安装一些依赖yum install -y readline-devel libaio libnsl compat-openssl10 cd /usr/lib64 ln -s libreadline.so.7 libreadline.so.6 安装以下的命令将openGauss安装到25432端口，密码请在命令行中“设定的高强度密码”修改su omm cd /opt/software/openGauss/simpleInstall sh install.sh -w 设定的高强度密码 -p 25432 vim ~/.bashrc # *注释*ulimit那行（在行最前加一个#）若没有可以忽略 source ~/.bashrc 配置兼容、外网访问众所周知，openGauss拥有PostgreSQL兼容的接口，若在此进行相关修改便可以在应用处无需修改使用主流软件的PG驱动连接数据库服务器使用。我们下面来修改默认配置使其兼容PG的连接器。cd /opt/software/openGauss/data/single_node vim postgresql.conf 添加/取消注释以下行listen_addresses = '*' local_bind_address = '0.0.0.0' password_encryption_type = 0 vim pg_hba.conf host all all 0.0.0.0/0 md5 启动或重启数据库（omm用户）gs_ctl restart -D $GAUSSHOME/data/single_node 进入数据库命令行（omm用户）创建一个名为postgres的管理用户（因为默认的omm用户无法从外部登录），密码请在命令行中定义gsql -d postgres -p 25432 create user postgres password '你的高强度密码'; GRANT ALL PRIVILEGES TO postgres; \q 退出 至此，你已经可以使用Navicat等软件连接到数据库了。若提示找不到gs_ctl、gsql等命令，请在/opt/software/openGauss/下找到bin目录，并将其加入Path至此，本教程结束~欢迎各位同学交流学习作者：黄浩

作者：DoDoQ前置校验项目及不通过的处理1、Kafka服务可用性检查：[test@dev-openeuler-arm ~]$ jps3757401 SchemaRegistryMain3757072 SupportedKafka3756341 QuorumPeerMain-- 可以先执行停止kafka的命令，确保Kafka进程已停止，避免启动时出错，停止kafka的命令如下java -Dpath=/{portal_path}/portal/ -Dorder=stop_kafka -Dskip=true -jar /{portal_path}/portal/portalControl-*-exec.jar-- 启动kafka进程的命令java -Dpath=/{portal_path}/portal/ -Dorder=start_kafka -Dskip=true -jar /{portal_path}/portal/portalControl-*-exec.jar-- 出现类似如下日志信息，表示启动kafka成功log4j: reset attribute= "false".log4j: Threshold ="null".log4j: Level value for root is  [debug].log4j: root level set to DEBUGlog4j: Class name: [org.apache.log4j.ConsoleAppender]log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"log4j: Setting property [conversionPattern] to [%d{HH:mm:ss,SS} %-5p (%C{1}:%M) - %m%n].log4j: Setting property [levelMin] to [INFO].log4j: Setting property [levelMax] to [ERROR].log4j: Setting property [acceptOnMatch] to [true].log4j: Adding filter of type [class org.apache.log4j.varia.LevelRangeFilter] to appender named [log.console].log4j: Adding appender named [log.console] to category [root].log4j: Class name: [org.apache.log4j.DailyRollingFileAppender]log4j: Setting property [file] to [/data/test/portal/portal//logs/portal_.log].log4j: Setting property [append] to [true].log4j: Setting property [datePattern] to [yyyy-MM-dd].log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"log4j: Setting property [conversionPattern] to [%d{HH:mm:ss,SS} %-5p (%C{1}:%M) - %m%n].log4j: Setting property [levelMin] to [INFO].log4j: Setting property [levelMax] to [ERROR].log4j: Setting property [acceptOnMatch] to [true].log4j: Adding filter of type [class org.apache.log4j.varia.LevelRangeFilter] to appender named [log.file].log4j: setFile called: /data/test/portal/portal//logs/portal_.log, truelog4j: setFile endedlog4j: Appender [log.file] to be rolled at midnight.log4j: Adding appender named [log.file] to category [root].19:35:00,492 INFO (ParamsUtils:initMigrationParamsFromProps) - properties = {awt.toolkit=sun.awt.X11.XToolkit, java.specification.version=11, sun.cpu.isalist=, sun.jnu.encoding=UTF-8, java.class.path=/data/test/portal/portal/portalControl-6.0.0rc1-exec.jar, java.vm.vendor=BiSheng, sun.arch.data.model=64, path=/data/test/portal/portal/, java.vendor.url=https://gitee.com/openeuler/bishengjdk-11/, user.timezone=Asia/Shanghai, os.name=Linux, java.vm.specification.version=11, sun.java.launcher=SUN_STANDARD, user.country=US, order=start_kafka, sun.boot.library.path=/data/test/env/java/bisheng-jdk-11.0.20/lib, sun.java.command=/data/test/portal/portal/portalControl-6.0.0rc1-exec.jar, jdk.debug=release, sun.cpu.endian=little, user.home=/home/test, user.language=en, java.specification.vendor=Oracle Corporation, java.version.date=2023-07-18, java.home=/data/test/env/java/bisheng-jdk-11.0.20, file.separator=/, java.vm.compressedOopsMode=Zero based, line.separator=, java.specification.name=Java Platform API Specification, java.vm.specification.vendor=Oracle Corporation, java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment, java.protocol.handler.pkgs=org.springframework.boot.loader, sun.management.compiler=HotSpot 64-Bit Tiered Compilers, java.runtime.version=11.0.20+11, user.name=test, skip=true, path.separator=:, os.version=4.19.90-2110.8.0.0119.oe1.aarch64, java.runtime.name=OpenJDK Runtime Environment, file.encoding=UTF-8, java.vm.name=OpenJDK 64-Bit Server VM, java.vendor.version=BiSheng, java.vendor.url.bug=https://gitee.com/openeuler/bishengjdk-11/issues/, java.io.tmpdir=/tmp, java.version=11.0.20, user.dir=/data/test/portal, os.arch=aarch64, java.vm.specification.name=Java Virtual Machine Specification, java.awt.printerjob=sun.print.PSPrinterJob, sun.os.patch.level=unknown, java.library.path=/data/test/portal/portal/tools/chameleon/chameleon-6.0.0rc1:/data/test/portal/portal/tools/chameleon/chameleon-5.1.1:/data/test/portal/portal/tools/chameleon/chameleon-6.0.0rc1:/data/test/portal/portal/tools/chameleon/chameleon-6.0.0rc1:/data/test/portal/portal/tools/chameleon/chameleon-6.0.0rc1:/data/test/portal/portal/tools/chameleon/chameleon-6.0.0:/data/xz_u2/base/opt/huawei/install/om/lib:/data/xz_u2/base/opt/huawei/install/om/script/gspylib/clib::/usr/java/packages/lib:/lib:/usr/lib:/usr/lib64:/lib64, java.vm.info=mixed mode, java.vendor=BiSheng, java.vm.version=11.0.20+11, java.specification.maintenance.version=2, sun.io.unicode.encoding=UnicodeLittle, java.class.version=55.0}19:35:00,567 INFO (MigrationConfluentInstanceConfig:getSystemParamAndParseEntity) - get MigrationConfluentInstanceConfig from system param = MigrationConfluentInstanceConfig(id=null, zookeeperPort=null, kafkaPort=null, zkIp=null, kafkaIp=null, installDir=null, bindPortalId=null, zkIpPort=null, kafkaIpPort=null, schemaRegistryIpPort=null, schemaRegistryIp=null, schemaRegistryPort=null, bindPortalHost=null, thirdPartySoftwareConfigType=null)19:35:00,569 INFO (KafkaUtils:changeConfluentDirFromSysParam) - no need change param19:35:00,576 INFO (FileUtils:createFile) - File /data/test/portal/portal/portal.portId.lock already exists.19:35:00,587 INFO (FileUtils:createFile) - File /data/test/portal/portal/workspace/1 already exists.19:35:00,587 INFO (FileUtils:createFile) - File /data/test/portal/portal/workspace/1/tmp/ already exists.19:35:00,592 INFO (FileUtils:createFile) - File /data/test/portal/portal/workspace/1/logs already exists.19:35:00,631 INFO (FileUtils:createFile) - File /data/test/portal/portal/workspace/1/status/ already exists.19:35:00,632 INFO (FileUtils:createFile) - File /data/test/portal/portal/workspace/1/status/incremental/ already exists.19:35:00,632 INFO (FileUtils:createFile) - File /data/test/portal/portal/workspace/1/status/portal.txt already exists.19:35:00,632 INFO (FileUtils:createFile) - File /data/test/portal/portal/workspace/1/status/full_migration.txt already exists.19:35:00,632 INFO (FileUtils:createFile) - File /data/test/portal/portal/workspace/1/status/incremental_migration.txt already exists.19:35:00,632 INFO (FileUtils:createFile) - File /data/test/portal/portal/workspace/1/status/reverse_migration.txt already exists.19:35:00,632 INFO (FileUtils:createFile) - File /data/test/portal/portal/workspace/1/logs/debezium/ already exists.19:35:00,633 INFO (FileUtils:createFile) - File /data/test/portal/portal/workspace/1/logs/datacheck/ already exists.19:35:00,650 INFO (ParamsUtils:changeDatacheckLogLevel) - global log level param is empty19:35:00,796 INFO (MigrationConfluentInstanceConfig:getSystemParamAndParseEntity) - get MigrationConfluentInstanceConfig from system param = MigrationConfluentInstanceConfig(id=null, zookeeperPort=null, kafkaPort=null, zkIp=null, kafkaIp=null, installDir=null, bindPortalId=null, zkIpPort=null, kafkaIpPort=null, schemaRegistryIpPort=null, schemaRegistryIp=null, schemaRegistryPort=null, bindPortalHost=null, thirdPartySoftwareConfigType=null)19:35:00,851 INFO (RuntimeExecUtils:executeStartOrder) - start command = /data/test/portal//portal/tools/debezium/confluent-5.5.1/bin/zookeeper-server-start -daemon /data/test/portal//portal/tools/debezium/confluent-5.5.1/etc/kafka/zookeeper.properties19:35:00,938 INFO (RuntimeExecUtils:executeStartOrder) - Start zookeeper.19:35:02,964 INFO (MqTool:start) - kafkaOrder====/data/test/portal//portal/tools/debezium/confluent-5.5.1/bin/kafka-topics --list --bootstrap-server 192.168.0.118:909219:35:03,07 INFO (RuntimeExecUtils:executeStartOrder) - start command = /data/test/portal//portal/tools/debezium/confluent-5.5.1/bin/kafka-server-start -daemon /data/test/portal//portal/tools/debezium/confluent-5.5.1/etc/kafka/server.properties19:35:03,93 INFO (RuntimeExecUtils:executeStartOrder) - Start kafka.19:35:05,102 INFO (RuntimeExecUtils:removeFile) - Remove file /data/test/portal/portal/tmp/test_.txt finished.19:35:07,108 INFO (RuntimeExecUtils:removeFile) - Remove file /data/test/portal/portal/tmp/test_.txt finished.19:35:07,174 INFO (RuntimeExecUtils:executeStartOrder) - start command = /data/test/portal//portal/tools/debezium/confluent-5.5.1/bin/schema-registry-start -daemon /data/test/portal//portal/tools/debezium/confluent-5.5.1/etc/schema-registry/schema-registry.properties19:35:07,181 INFO (RuntimeExecUtils:executeStartOrder) - Start kafka schema registry.19:35:10,281 INFO (MqTool:start) - Start kafka success.2、检查源端和目标端数据库是否可连接MySQL: mysql -h ip -P port -u user -ppassword -S /~/mysql.sock\ OpenGauss: gsql -r -d database -p port -U user -W password3、权限检查Mysql连接用户权限要求如下：为确认数据的顺利迁移，源端数据库（Mysql）的数据源添加时，请按照迁移需要添加所需权限，也可以直接给all权限；1）全量迁移： select 、reload、 lock tables 、replication client2）增量迁移： select 、replication client 、replication slave3）反向迁移： select 、update 、insert 、delete查询和修改用户权限的命令如下，如果连接用户权限不满足，请修改对应权限值。-- 查询用户权限的命令SELECT * FROM mysql.user WHERE USER = '{用户名}';-- 修改用户权限的命令语法格式如下，其中privileges：用户的操作权限，如SELECT，INSERT，UPDATE等，如果要授予所的权限则使用ALL；databasename：数据库名；tablename：表名，如果要授予该用户对所有数据库和表的相应操作权限则可用*表示，如*.*。GRANT privileges ON databasename.tablename TO '{用户名}';-- 赋予用户全量迁移权限的命令GRANT SELECT, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO '{用户名}';-- 赋予用户增量迁移权限的命令GRANT SELECT, REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO '{用户名}';-- 赋予用户反向迁移权限的命令GRANT SELECT, UPDATE, INSERT, DELETE ON *.* TO '{用户名}';-- 赋予所有权限的命令GRANT ALL ON *.* TO '{用户名}';-- 在赋权后，确保刷新权限以使更改生效FLUSH PRIVILEGES;openGauss连接用户权限要求如下：通过Datakit平台安装的目标端数据库（openGauss）可以直接迁移，导入的数据库以及在创建任务时添加的自定义openGauss数据源，需要提前将用户权限改为SYSADMIN角色；-- 首先使用连接用户连接openGauss-- 查询rolreplication权限的命令select rolreplication from pg_roles;-- 修改权限的命令alter role '{用户名}' replication;修改openGauss用户权限的方式如下：方式一：（推荐，符合最小权限）#给要迁移的目标库target_source赋all权限给迁移用户openGauss_testgrant all on database target_source to openGauss_test;方式二：（不推荐）#修改用户角色为SYSADMINalter user {用户名} SYSADMIN;#查询用户角色，字段值为t时说明具有sysadmin角色，f时则没有select rolsystemadmin from PG_ROLES where rolname='{用户名}';有sysadmin角色权限：查询结果为t；无sysadmin角色权限：查询结果为f；4、日志参数检查增量迁移时，源数据库Mysql需要开启复制功能，在配置中增加以下配置参数，并重启log_bin=ONbinlog_format= ROWbinlog_row_image=FULL查询参数值是否设置成功的命令如下：SHOW VARIABLES LIKE 'log_bin';SHOW VARIABLES LIKE 'binlog_format';SHOW VARIABLES LIKE 'binlog_row_image';反向迁移时，需要在openGauss数据库增加如下配置，并重启-- 根据连接用户和实际网络配置命令gs_guc set -D /opt/datakit/opengauss/datanode/dn1 -h "host replication {connected username} {ip/port} sha256"-- 直接允许所有用户和网络配置命令gs_guc set -D /opt/datakit/opengauss/datanode/dn1 -h "host replication all 0.0.0.0/0 sha256"-- 修改参数的sql语句alter system set wal_level to logical;-- 或直接修改配置文件中的参数，其中“/opt/datakit/opengauss/datanode/dn1”为实际数据库节点目录gs_guc set -D /opt/datakit/opengauss/datanode/dn1 -c "wal_level = logical"查询日志参数wal_level是否设置成功的命令如下：-- 查询是否允许复制的参数，为1表示设置成功select rolreplication from pg_roles where rolname='{用户名}'-- 查询wal_level参数show variables like 'wal_level';5、大小写参数检查需确保Mysql和OpenGauss的大小写参数一致，查询大小写参数的命令如下：-- 查询Mysql的大小写参数show variables like 'lower_case_table_names';-- 查询openGauss的大小写参数show dolphin.lower_case_table_names;修改大小写参数，使两者保持一致，修改方式如下：修改Mysql的大小写参数更改数据库参数文件my.cnf在mysqld下添加或修改 lower_case_table_names = 1 之后重启数据库修改openGauss的大小写参数alter user {用户名} set dolphin.lower_case_table_names to 0;6、磁盘空间校验迁移过程中会产生一些临时文件，需要占用一定的磁盘空间，要求磁盘满足---源端单表的最大数据量。7、B库校验迁移的目标数据库要求是B库，查询是否为B库的命令如下：show sql_compatibility;创建B库的命令create database {dbname} with dbcompatibility = 'b';8、Mysql加密方式校验查询系统默认加密方式的命令select @@default_authentication_plugin;修改系统默认加密方式更改数据库参数文件my.cnf在mysqld下添加或修改 default-authentication-plugin=mysql_native_password 之后重启数据库同时修改连接用户的加密方式为mysql_native_password，修改的sql语句如下：ALTER USER '用户名'@'%' IDENTIFIED WITH mysql_native_password BY '新密码';9、复制参数校验启动反向迁移会占用逻辑复制槽位，需要确保openGauss有可使用的槽位。-- 查询当前使用的槽位select count(*) from pg_get_replication_slots();-- 查询系统最大槽位show max_replication_slots;槽位很少出现被占满的情况，如若被占满，通过如下操作删除无用槽位。-- 获取当前复制槽列表select * from pg_get_replication_slots();-- 删除流复制槽，其中slot_name为流复制槽名称select pg_drop_replication_slot('slot_name');获取复制槽列表的示例如下：openGauss=# select * from pg_get_replication_slots(); slot_name | plugin | slot_type | datoid | active | xmin | catalog_xmin | restart_lsn | dummy_standby | confirmed_flush-----------+----------------+-----------+--------+--------+------+--------------+-------------+---------------+----------------- dn_s1 | | physical | 0 | t | | | 0/23DB14E0 | f | slot1 | mppdb_decoding | logical | 16304 | f | | 60966 | 0/1AFA1BB0 | f | 0/23DA5700(2 rows)注：逻辑复制槽的占用会在增量迁移停止后创建，如果此时结束迁移任务，就会有槽位占用的残留。而如果正常进行反向迁移，然后停止迁移任务，则会自动删除占用的槽位。可以将portal的migrationConfig.properties配置文件中的drop.logical.slot.on.stop参数设置为true，以保证迁移任务结束时，自动删除占用的槽位。进一步学习，请参考openGauss社区，社区地址：https://opengauss.org/zh/。10、迁移过程中，请勿关闭源数据库或目标数据库；11、执行迁移任务的服务器应具备一定的性能和配置，以保证迁移过程的顺利执行；12、迁移任务是在非root用户下执行，任务的执行机器来源于平台资源中心的设备管理，因此需要在设备管理的用户管理中添加非root用户。

作者：DoDoQ说明：此文档仅包含使用DataKit进行数据迁移时，搭建迁移任务相关教程，不包含一些必须的前置配置步骤，和环境要求等，请优先学习“DataKit数据迁移-1使用说明”文档。数据迁移实例搭建步骤1 离线模式迁移步骤创建源端数据库用例，并初始化数据详细说明，参考“迁移各步骤详细说明”目录下：“1 创建源端数据库用例，并初始化数据”，下同。创建目标端数据库B库详细说明：“2 创建目标端数据库B库”使用B库连接openGauss数据库，并在目标端创建与mysql对象definer同名的用户，并赋权详细说明：“3 在目标端创建与MySQL对象definer同名的用户，并赋权”DataKit新增目标端和源端数据源详细说明：“4 DataKit新增目标端和源端数据源”创建迁移任务详细说明：“5 创建迁移任务步骤”启动迁移任务，查看任务详情详细说明：“6 启动迁移任务，查看任务详情”解决前置校验失败详细说明：“7 解决前置校验失败”重置迁移任务， 查看任务详情详细说明：“8 重置迁移任务， 查看任务详情”等待迁移任务完成，手动校验迁移结果详细说明：“9 校验全量迁移结果”2 在线模式迁移步骤创建源端数据库用例，并初始化数据同离线模式步骤创建目标端数据库B库同离线模式步骤使用B库连接openGauss数据库，并在目标端创建与mysql对象definer同名的用户，并赋权同离线模式步骤DataKit新增目标端和源端数据源同离线模式步骤创建迁移任务同离线模式步骤启动迁移任务，查看任务详情同离线模式步骤解决前置校验失败同离线模式步骤重置迁移任务， 查看任务详情同离线模式步骤校验全量迁移结果同离线模式“校验迁移结果”步骤修改源端数据库数据，校验增量迁移结果详细说明：“10 修改源端数据库数据，校验增量迁移结果”结束增量迁移，启动反向迁移详细说明：“11 结束增量迁移，启动反向迁移”修改目标端数据库数据，检验反向迁移结果详细说明：“12 修改目标端数据库数据，检验反向迁移结果”结束迁移任务详细说明：“13 结束在线模式迁移任务”迁移各步骤详细说明1 创建源端数据库用例，并初始化数据连接MySQL数据库，并执行如下sql语句，在源端创建source_db数据库，作为迁移的源端数据库用例。DROP DATABASE IF EXISTS source_db;CREATE DATABASE source_db;USE source_db;CREATE TABLE table1(id INT, name VARCHAR(10), col VARCHAR(20), PRIMARY KEY(id));INSERT INTO table1 VALUES(1,'data', 'data1');INSERT INTO table1 VALUES(2,'data', 'data2');INSERT INTO table1 VALUES(3,'data', 'data3');INSERT INTO table1 VALUES(4,'data', 'data4');INSERT INTO table1 VALUES(5,'data', 'data5');INSERT INTO table1 VALUES(6,'data', 'data6');CREATE VIEW view1 AS SELECT * FROM table1;CREATE FUNCTION mysql_func1(s CHAR(20)) RETURNS CHAR(50) DETERMINISTIC RETURN CONCAT('mysql_func1, ',s,'!');CREATE TRIGGER trigger1 BEFORE INSERT ON table1 FOR EACH ROW SET new.col = CONCAT(new.name, new.id);CREATE PROCEDURE procedure1() SELECT * FROM table1;2 创建目标端数据库B库连接openGauss数据库，并执行如下sql语句，创建B库。create database target_db with dbcompatibility = 'b';3 在目标端创建与MySQL对象definer同名的用户，并赋权当源端数据库中有视图（view），触发器（trigger）或存储过程（procedure）的对象时，需要在目标端创建与其对象definer同名的用户。查询MySQL端对象definer-- 查询MySQL对象definer的sql语句show create view view1;查询结果类似如下：View Create View character_set_client collation_connectionview1 CREATE ALGORITHM=UNDEFINED DEFINER=`test`@`%` SQL SECURITY DEFINER VIEW `view1` AS select `table1`.`id` AS `id`,`table1`.`name` AS `name`,`table1`.`col` AS `col` from `table1` utf8mb3 utf8mb3_general_ci其中：“'test'@'%'”即为MySQL对象definer使用B库连接openGauss数据库-- 通过gsql连接B库gsql -d target_db -p 5680 -r-- 或，在gsql已连接情况下切换至B库\c target_db在目标端创建与mysql对象definer同名的用户，并赋权-- 创建与mysql对象definer同名的用户，并赋权的sql语句-- 设置b_compatibility_user_host_auth参数值为onset b_compatibility_user_host_auth to on;-- 创建同名用户create user 'username'@'%' with password 'Sample@123';-- 给新增用户赋权grant all privileges to 'username'@'%';4 DataKit新增目标端和源端数据源请按照如下步骤，分别添加源端MySQL数据源和目标端openGauss数据源。访问DataKit服务，点击进入“资源中心->实例管理”目录下点击“创建”按钮，弹出“新增数据源”窗口进行新增数据源配置集群名称可忽略，也可自定义数据库类型选择“MYSQL”或“OPENGAUSS”准确配置数据库服务的ip地址，端口，用户名，密码信息连接拓展属性，及使用jdbc连接数据库服务时，做的一些时区，字符集限制等，可忽略连接地址，即通过上述配置的连接信息拼出的jdbc连接数据库的url配置完成后，点击“测试连通性”“待检测”显示为“可用”，说明可以成功建立连接“待检测”显示为“不可用”，说明存在网络问题，或配置信息有误，请校验后重试。“测试连通性”可用后，点击“确认”按钮，成功添加数据库实例5 创建迁移任务步骤Datakit成功加载data-migration插件点击进入DataKit服务“数据迁移 -> 迁移任务中心”目录下点击“创建数据迁移任务”按钮开始“选择迁移源库和目的库”步骤选择源端数据库（MySQL端），选择目的端数据库（openGauss端），并点击“添加子任务”按钮，支持添加多条子任务。成功添加子任务后，在页面下方选择对应子任务的“迁移过程模式”，支持选择“在线模式”和“离线模式”。“选择迁移源库和目的库”配置成功，点击下一步。注：如果无数据源，点击“新增数据源”，输入所需参数进行新增，或参考目录“4 DataKit新增目标端和源端数据源”。目的端选择目录“2 创建目标端数据库B库”已创建好的B库。迁移过程模式，支持在线模式和离线模式。离线模式：自动执行全量迁移 + 全量校验，完成后自动结束。在线模式：可执行全量迁移 + 全量校验 + 增量迁移 + 增量校验 + 反向迁移。其中portal自动执行全量迁移 + 全量校验 + 增量迁移 + 增量校验，然后一直处于增量迁移状态（此时增量迁移和增量校验同时运行）。用户需要手动停止增量迁移，然后手动启动反向迁移，此后一直处于反向迁移状态。如果需要结束任务，需要用户手动结束迁移。开始“配置迁移过程参数”步骤直接使用默认参数即可，点击“下一步”。开始“分配执行机资源”步骤页面会展示所有的执行机列表信息，页面左侧复选框，勾选一台已安装迁移套件（portal）的执行机，点击完成，创建迁移任务成功。注：执行机，是指安装有portal（portal时具体执行迁移任务的插件）的服务器。即，迁移任务实际上是在安装portal的服务器上，使用portal插件执行的，DataKit这里只是作为一个集中管理迁移任务的客户端。如果没有已安装迁移套件的执行机，详细见文档“DataKit数据迁移-1使用说明”中，目录：“DataKit安装Portal教程”。查看迁移任务点击进入目录“数据迁移 -> 迁移任务中心”下，可以看到已创建成功的迁移任务列表信息。修改迁移任务配置迁移任务列表中，字段“执行状态”为未启动的任务，点击对应数据行右侧“详请”，可以看到上述“创建迁移任务步骤”的过程配置信息，并支持修改配置。6 启动迁移任务，查看任务详情点击进入DataKit服务“数据迁移 -> 迁移任务中心”目录下找到上述创建的迁移任务记录，点击记录右侧的“启动”，迁移任务启动成功点击记录右侧的“详情”，进入迁移任务详情页点击对应子任务右侧的“详情”，可查看子任务迁移的详细过程数据“在线/离线迁移过程记录”中，会展示详细的迁移情况其中全量迁移会展示表，视图，函数，触发器和存储过程的迁移情况，迁移状态为绿色“√”图标时，说明迁移成功，为橙色“×”图标时，说明迁移失败。全量校验则只校验拥有主键的表，同样校验状态为绿色“√”图标时，说明迁移成功，为橙色“×”图标时，说明校验失败。当存在失败的情况时，点击对应子任务右侧的“日志”，可以选择下载所需日志，查看日志中的报错信息并解决。7 解决前置校验失败如果未出现“前置校验失败”的状态，则不需要解决，跳过此步骤即可。当出现前置校验失败时，鼠标悬浮于对应子任务“前置校验失败”提示的右侧橙色“×”图标上，即可查看校验失败的详细信息，根据详细信息中提示的校验失败项，参考文档“DataKit数据迁移-3前置校验失败的处理”，对失败项进行解决。8 重置迁移任务， 查看任务详情如果未出现“前置校验失败”的状态，则不需要此操作，跳过此步骤即可。当解决完成“前置校验失败”的项目后，在页面的标签页栏中关闭此任务的“任务详情”页面，点击回到“迁移任务中心”页面，找到对应迁移任务记录，点击对应页面右侧的“结束迁移”，然后点击“重置”，再点击“启动”，重新启动此迁移任务，再次点击“详情”，即可查看迁移任务详细的过程信息。9 校验全量迁移结果当离线模式迁移任务完成，或在线模式全量校验完成后，可以手动连接到迁移的目标端数据库，通过如下sql语句，手动查看并校验库中数据是否于源端数据库中数据相同。-- 使用B库连接openGauss数据库gsql -d target_db -p 5680 -r-- 或在已连接的情况下，切换到目标端B库\c target_db-- 设置默认的schemaSET CURRENT_SCHEMA TO source_db;-- 查看表格和视图SHOW TABLES;-- 查询触发器SHOW TRIGGERS;-- 查看函数SHOW FUNCTION STATUS WHERE Db = 'source_db';-- 查看存储过程SHOW PROCEDURE STATUS WHERE Db = 'source_db';-- 查询表中数据SELECT * FROM table1;注：此处设置默认的schema，是由于数据迁移会默认在目标端数据库中创建与源端数据库同名的的schema，并将源端数据库中的数据迁移到此schema中。10 修改源端数据库数据，校验增量迁移结果在源端依次执行增删改和创建表格等操作，可以查看对应迁移任务详情中，“累计增量迁移对象数”会随着操作逐次增加，当“剩余待写入数据”条数为0时，说明所有数据库操作均已增量迁移成功。也可以每次源端做出操作后，在目标端手动校验数据是否同步，以验证增量迁移情况。修改源端数据库数据-- 增删改操作-- 插入数据INSERT INTO table1 VALUES(7, 'data', 'data7');-- 修改数据UPDATE table1 SET NAME = 'new_data' WHERE id = 7;-- 删除数据DELETE FROM table1 WHERE id = 7;-- DDL操作-- 创建表CREATE TABLE table2 ( id INT, NAME VARCHAR(10));-- 删除表DROP TABLE table2;手动校验增量迁移结果-- 增删改操作校验-- 查询表中修改的数据是否同步select * from table1;-- DDL操作校验-- 查询目标端表格的增删情况SHOW TABLES;-- 查询目标端表结构，与新增表结构是否一致SHOW CREATE TABLE table2;11 结束增量迁移，启动反向迁移点击对应子任务右侧的“停止增量”，点击“确认”按钮，等待增量迁移停止。增量迁移成功停止后，对应子任务右侧的“启动反向”，点击查看详情，可以查看反向迁移详细过程。12 修改目标端数据库数据，检验反向迁移结果在目标端依次执行增删改操作，可以查看对应迁移任务详情中，“累计反向迁移对象数”会随着操作逐次增加，当“剩余待写入数据”条数为0时，说明所有数据库操作均已反向迁移成功。也可以每次目标端做出操作后，在源端手动校验数据是否同步，以验证反向迁移情况。修改目标端数据库数据-- 增删改操作-- 插入数据INSERT INTO table1 VALUES(7, 'data', 'data7');-- 修改数据UPDATE table1 SET NAME = 'new_data' WHERE id = 7;-- 删除数据DELETE FROM table1 WHERE id = 7;手动校验反向迁移结果-- 增删改操作校验-- 依次查询修改是否同步select * from table1;13 结束在线模式迁移任务在线模式迁移任务不同与离线模式，当不手动进行停止操作时，会始终处于反向迁移状态下。点击对应子任务右侧“结束迁移”，等待迁移任务停止，则此在线模式迁移任务完成。

作者：DoDoQDataKit简介DataKit是开源的openGuass数据库管理工具，支持用户对openGuass进行安装，运维，卸载等其他功能。DataKit的开源Gitee地址为https://gitee.com/opengauss/openGauss-workbench，其中对DataKit的介绍如下：openGauss DataKit是基于Web的openGauss的可视化的平台系统，目的是方便客户使用和管理openGauss可视化工具，可以为客户降低openGauss数据库安装使用门槛，做到安全中心管理，插件管理，以及其它功能包括一键化部署、卸载、组件化安装、多版本升级、日常运维和监控。本文的概述本文主要对DataKit工具的数据迁移功能的使用进行详细讲解，DataKit数据迁移可以完成迁移MySQL数据到openGauss数据库中的功能。本文是博主整理的DataKit数据迁移功能使用的详细教程，主要包含的内容有：环境准备，迁移前配置，执行迁移任务，DataKit安装portal教程，DataKit数据迁移常见问题。阅读本文需要结合博主的另外两篇文章，分别是“DataKit数据迁移-2实例搭建步骤”，“DataKit数据迁移-3前置校验失败的处理”。三篇文章从不同方面，对DataKit数据迁移功能进行了全方位的使用教程。使用DataKit数据迁移功能，只需按照文章目录顺序阅读阅读即可。若有错误，不详，疑问或建议等，欢迎留言交流。1 环境准备DataKit服务要求：成功加载data-migration插件DataKit安装教程，请参考码云仓库（https://gitee.com/opengauss/openGauss-workbench）openGauss企业版服务要求：可以被DataKit服务所在服务器访问openGauss企业版安装请参考官方社区（https://opengauss.org/zh/）教程，也可使用DataKit base-ops插件的“集群安装-安装部署”功能进行安装。MySQL服务要求：可以被DataKit服务所在服务器访问CentOS或openEuler系统服务器要求：可以被DataKit服务所在服务器访问；JDK 11+环境用途：用于安装迁移插件（portal）2 迁移前配置2.1 openGauss配置2.1.1 参数配置修改配置文件pg_hba.conf和postgresql.conf相关参数，以支持迁移过程。配置白名单，以支持通过openGauss用户进行远程连接，配置命令如下：-- 修改pg_hba.conf文件gs_guc set -D <datanode> -h "host all all 0.0.0.0/0 sha256"-- 修改postgresql.conf文件gs_guc set -D <datanode> -c "listen_addresses = '*'"-- 其中，“<datanode>”为数据库节点路径，请替换为实际值，如“/opt/huawei/install/data/dn”，此文档中后续此参数含义不变。配置日志参数及复制权限，以支持反向迁移，配置命令如下：-- 修改pg_hba.conf文件gs_guc set -D <datanode> -h "host replication all 0.0.0.0/0 sha256"-- 修改postgresql.conf文件gs_guc set -D <datanode> -c "wal_level = logical"配置完成后，重启数据库，重启命令如下：gs_ctl restart -D <datanode>2.1.2 创建管理员用户连接数据库gsql -d postgres -p <port> -r-- 其中，“<port>”请替换为实际端口，如“5432”，此文档中后续此参数含义不变。创建用户并赋予管理员权限create user opengauss_test with password 'Sample@123';grant all privileges to opengauss_test;-- 其中，“opengauss_test”为用户名，可自定义，后续此文档中涉及到连接openGauss的用户，便使用此用户。-- “Sample@123”为用户密码，可自定义。3 执行迁移任务请参考文档：“DataKit数据迁移-2实例搭建步骤”4 DataKit安装Portal教程4.1 DataKit安装Portal注意事项root用户下，依次安装如下依赖yum install -y mysql-develyum install -y mysql5-develyum install -y mariadb-develyum install -y python3-develyum install -y python-devel注：如果mysql5-devel与mariadb-devel冲突，保留一个即可。其他包如果未找到，则可忽略。请确保安装用户的~/.bashrc已经配置java环境变量，并且版本满足11+。安装6.0.0-RC1的portal包，并确认在线安装的安装包是否匹配对应主机架构。可能存在DataKit未成功获取目标执行机系统及架构信息的情况，导致在线安装给出的包是默认的centos-x86的安装包。遇到此情况，请自行前往portal仓库，下载匹配目标执行机系统及架构的安装包，然后使用datakit的portal离线安装，上传下载的安装包进行安装。# portal码云仓库地址https://gitee.com/opengauss/openGauss-migration-portal安装目录尽量不要再用户的home目录下，即~目录下，并确保安装用户对安装目录有操作权限。因此建议使用安装用户创建目录，供安装portal使用。请确保第三方工具的三个端口未被占用，如果默认端口已被占用，支持自定义端口。4.2 DataKit安装Portal步骤访问Datakit服务，点击进入“数据迁移->迁移任务中心”目录下点击“创建数据迁移任务”按钮开始“选择迁移源库和目的库”步骤，分别选择源端数据库（database），选择目的端数据库（database），并点击“添加子任务”按钮。如果无数据源，点击“新增数据源”，输入所需参数进行新增。添加子任务成功后，在页面下方选择对应子任务的“迁移过程模式”，支持在线模式和离线模式。离线模式：自动执行全量迁移，完成后自动结束，释放资源。 在线模式：自动执行全量迁移+增量迁移，用户手动启动反向迁移，需要用户操作结束迁移，释放资源。“选择迁移源库和目的库”配置成功，点击下一步。进入“配置迁移过程参数”步骤，可直接使用默认参数，直接点击“下一步”。进入“分配执行机资源”步骤，页面会展示所有的执行机列表信息，选择对应执行机点击“开始安装”，进入“迁移套件安装”步骤。此处如果无执行机信息显示，请前往“资源中心->服务器管理”添加服务器资源，注意添加服务器时需要勾选“记住密码”，添加服务器成功后，页面会显示添加成功的服务器记录。点击所需服务器记录右侧的“用户管理”，添加普通用户。至此，此服务器可作为安装portal的执行机。进行portal安装,“安装用户”选择上述添加的服务器的普通用户。“安装目录”选择使用“安装用户”创建的已有目录，不建议使用默认的“安装用户”的home目录。“第三方工具配置方式”选择“本机新安装”，选择后会出现“zookeeper 端口”，“kafka 端口”，“schema_registry 端口”三条配置项，请确保配置的三个端口未被占用，如默认端口被占用，支持自定义端口。“第三方工具安装目录”使用默认的即可，支持自定义，但同样请配置到使用“安装用户”创建的目录下。选择安装方式，“在线安装”是在线下载安装包，完成安装，需要确保对应的服务器网络正常。“离线安装”支持手动上传portal安装包进行安装，注意自行下载时请下载匹配对应服务器系统及架构的安装包。“导入安装”支持导入对应服务器上已安装的portal，但要求已安装的portal成功安装了所有的mysql迁移插件，否则导入安装无法成功。“安装包名称”建议选用最新版本的安装包。至此“迁移套件安装”步骤配置成功，点击“确认”按钮，开始portal安装。进行portal安装时，“分配执行机资源”页面的对应执行机的“是否安装迁移套件”字段会显示为“安装中”，安装成功则显示为“已安装”。如果安装失败，可下载“安装日志”，排除故障后，点击“清理环境”，然后再次安装即可。4.3 DataKit安装Portal可能出现的问题无论遇到任何问题，请先按照“DataKit安装Portal注意事项”进行排查后，再次尝试安装。4.3.1 kafka启动失败的问题问题描述：安装portal，所有迁移工具安装成功，但是启动kafka失败，报错类似如下：Socket server failed to bind to 10.126.28.177:9089: Cannot assign requested address问题原因：网络问题，使用外网ip连接服务器时，本机无法感知，导致kafka无法成功启动，修改ip为本机ip，如192.168.0.123后，停止残留的zookeeper kafka等进程，重新启动kafka，启动kafka成功。解决方式：修改了配置文件的listeners属性中的ip地址为本机ip地址，配置文件位置：/portalpath/portal/tools/debezium/confluent-5.5.1/etc/kafka/server.properties。修改成功后，执行如下命令重启kafka：-- 可以先执行停止kafka的命令，确保Kafka进程已停止，避免启动时出错，停止kafka的命令如下java -Dpath=/data/dgq/portal/portal/ -Dorder=stop_kafka -Dskip=true -jar /data/dgq/portal/portal/portalControl-6.0.0rc1-exec.jar-- 启动kafka进程的命令java -Dpath=/data/dgq/portal/portal/ -Dorder=start_kafka -Dskip=true -jar /data/dgq/portal/portal/portalControl-6.0.0rc1-exec.jar5 DataKit数据迁移常见问题5.1 在线模式，任务长时间卡顿在全量迁移过程中的问题问题描述：成功创建在线迁移任务后，点击启动，无前置校验失败，任务状态长时间卡顿在全量迁移进行中，页面无报错，后台full_migration.log无报错。查看portal中对应任务workspace.id的log日志，日志目录为/portal_install_path/portal/logs/portal_3.log，其中的portal_install_path请替换为实际的portal安装路径，3请替换为实际的子任务worksapce.id（可以在子任务详情页面的左上角查看）。日志中包含报错信息“begin 0, end -1, length 0”，详细信息类似如下：16:56:15,851 ERROR (ThreadExceptionHandler:uncaughtException) - thread main occur excetion: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:49) at org.springframework.boot.loader.Launcher.launch(Launcher.java:108) at org.springframework.boot.loader.Launcher.launch(Launcher.java:58) at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:88)Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 0 at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3319) at java.base/java.lang.String.substring(String.java:1874) at org.opengauss.portalcontroller.tools.mysql.IncrementalMigrationTool.changeGtidSet(IncrementalMigrationTool.java:165) at org.opengauss.portalcontroller.tools.mysql.IncrementalMigrationTool.findOffset(IncrementalMigrationTool.java:139) at org.opengauss.portalcontroller.tools.mysql.IncrementalMigrationTool.init(IncrementalMigrationTool.java:302) at org.opengauss.portalcontroller.task.Plan.execPlan(Plan.java:448) at org.opengauss.portalcontroller.PortalControl.startPlan(PortalControl.java:384) at org.opengauss.portalcontroller.command.mysql.StartCommandReceiver.action(StartCommandReceiver.java:41) at org.opengauss.portalcontroller.command.ConcreteCommand.execute(ConcreteCommand.java:24) at org.opengauss.portalcontroller.PortalControl.main(PortalControl.java:181) ... 8 more16:56:16,599 INFO (ChangeStatusTools:reduceDiskSpace) - isReduced:false,Plan.stopPlan:false,PortalControl.status:216:56:18,654 INFO (ChangeStatusTools:reduceDiskSpace) - isReduced:false,Plan.stopPlan:false,PortalControl.status:2问题原因：直接原因：查询openGauss的t_gtid_set为空所致-- 首先连接目标端数据库-- 查询openGauss的t_gtid_set的sql如下select t_binlog_name,i_binlog_position,t_gtid_set from sch_chameleon.t_replica_batch;根本原因：查询MySQL的Executed_Gtid_Set为空所致-- 查询MySQL的Executed_Gtid_Set的sql，其中字段Executed_Gtid_Set对应的值就是Executed_Gtid_SetSHOW MASTER STATUS;问题解决：设置MySQL 端的gtid_mode参数值为on，设置的sql如下:-- 逐行执行如下sql语句，完成设置SET GLOBAL ENFORCE_GTID_CONSISTENCY = ON;SET GLOBAL gtid_mode=OFF;SET GLOBAL gtid_mode=OFF_PERMISSIVE;SET GLOBAL gtid_mode=ON_PERMISSIVE;SET GLOBAL gtid_mode=ON;设置完成后，通过如下sql查询是否设置成功：-- 查询gitid_mode状态的sql语句SHOW GLOBAL VARIABLES LIKE 'gtid_mode';设置成功后，任意执行一条插入语句，再次查询Executed_Gtid_Set，使得字段Executed_Gtid_Set对应的值变为类似如下格式bb95ff80-f621-11ee-a803-fa163e5bb329:1-3，冒号后为1-n的格式，迁移过程中会强校验此值的格式，格式变成上述格式则问题解决。结束历史迁移任务，重新创建迁移任务并启动，问题解决。5.2 全量迁移未开始，便提示迁移失败的问题问题描述：启动迁移任务，迁移状态至“全量迁移开始”，然后便提示迁移失败的情况。查看全量迁移日志，日志进行到创建schema步骤，且报错信息为“syntax error at or near “-””，详细日志类似如下。 2024-05-20 16:57:25.322 MainProcess DEBUG mysql_lib.py (826): Creating the loading schema demo-portal_tmp.Traceback (most recent call last): File "/ops/portal/tools/chameleon/chameleon-6.0.0rc1/venv/bin/chameleon.py", line 76, in <module> getattr(replica, args.command)() File "/ops/portal/tools/chameleon/chameleon-6.0.0rc1/venv/lib64/python3.9/site-packages/pg_chameleon/lib/global_lib.py", line 575, in init_replica self.__init_mysql_replica() File "/ops/portal/tools/chameleon/chameleon-6.0.0rc1/venv/lib64/python3.9/site-packages/pg_chameleon/lib/global_lib.py", line 585, in __init_mysql_replica self.mysql_source.init_replica() File "/ops/portal/tools/chameleon/chameleon-6.0.0rc1/venv/lib64/python3.9/site-packages/pg_chameleon/lib/mysql_lib.py", line 3013, in init_replica self.create_destination_schemas() File "/ops/portal/tools/chameleon/chameleon-6.0.0rc1/venv/lib64/python3.9/site-packages/pg_chameleon/lib/mysql_lib.py", line 827, in create_destination_schemas self.pg_engine.create_database_schema(loading_schema) File "/ops/portal/tools/chameleon/chameleon-6.0.0rc1/venv/lib64/python3.9/site-packages/pg_chameleon/lib/pg_lib.py", line 5291, in create_database_schema self.pgsql_conn.execute(sql_create) File "/ops/portal/tools/chameleon/chameleon-6.0.0rc1/venv/lib64/python3.9/site-packages/py_opengauss/driver/pq3.py", line 2318, in execute self._pq_complete() File "/ops/portal/tools/chameleon/chameleon-6.0.0rc1/venv/lib64/python3.9/site-packages/py_opengauss/driver/pq3.py", line 2623, in _pq_complete self.typio.raise_error(x.error_message, cause = getattr(x, 'exception', None)) File "/ops/portal/tools/chameleon/chameleon-6.0.0rc1/venv/lib64/python3.9/site-packages/py_opengauss/driver/pq3.py", line 544, in raise_error self.raise_server_error(error_message, **kw) File "/ops/portal/tools/chameleon/chameleon-6.0.0rc1/venv/lib64/python3.9/site-packages/py_opengauss/driver/pq3.py", line 535, in raise_server_error raise server_errorpy_opengauss.exceptions.SyntaxError: syntax error at or near "-" CODE: 42601 LOCATION: SERVER POSITION: 20CONNECTION: [idle] client_address: 192.168.0.66/22 client_port: 6666 version: (openGauss 5.0.2 build 48a25b11) compiled at 2024-05-14 10:26:01 commit 0 last mr on x86_64-unknown-linux-gnu, compiled by g++ (GCC) 7.3.0, 64-bitCONNECTOR: [IP4] pq://gaussdb:***@192.168.0.66:5432/test1?[sslmode]=disable category: NoneDRIVER: py_opengauss.driver.pq3.DriverProcess Process-2:Traceback (most recent call last): File "/usr/lib64/python3.9/multiprocessing/process.py", line 315, in _bootstrap self.run() File "/usr/lib64/python3.9/multiprocessing/process.py", line 108, in run self._target(*self._args, **self._kwargs) File "/ops/portal/tools/chameleon/chameleon-6.0.0rc1/venv/lib64/python3.9/site-packages/pg_chameleon/lib/global_lib.py", line 380, in dump_Json self.write_Json() File "/ops/portal/tools/chameleon/chameleon-6.0.0rc1/venv/lib64/python3.9/site-packages/pg_chameleon/lib/global_lib.py", line 356, in write_Json dump_object = self.mysql_source.getmanagerJson().copy() File "<string>", line 2, in copy File "/usr/lib64/python3.9/multiprocessing/managers.py", line 809, in _callmethod conn.send((self._id, methodname, args, kwds)) File "/usr/lib64/python3.9/multiprocessing/connection.py", line 210, in send self._send_bytes(_ForkingPickler.dumps(obj)) File "/usr/lib64/python3.9/multiprocessing/connection.py", line 415, in _send_bytes self._send(header + buf) File "/usr/lib64/python3.9/multiprocessing/connection.py", line 372, in _send n = write(self._handle, buf)BrokenPipeError: [Errno 32] Broken pipe2024-05-20 16:57:38.525 MainProcess DEBUG pg_lib.py (704): There is already a database connection active.2024-05-20 16:57:38.529 MainProcess INFO global_lib.py (517): Dropping the replica schema2024-05-20 16:57:38.529 MainProcess DEBUG pg_lib.py (2831): Trying to connect to the destination database.2024-05-20 16:57:38.684 MainProcess INFO chameleon.py (91): drop_replica_schema finished.问题原因：问题是由于源端MySQL数据库名中包含“-”连字符导致，迁移过程中，迁移插件会根据源端MySQL数据库名，在目标端openGauss数据库中，创建于MySQL数据库名同名的schema，但是openGauss的schema命名不支持使用“-”连字符，因此会报错。问题解决：修改源端数据的命名，重新创建迁移任务并启动。或选择远端数据库命名无“-”连字符的数据库。5.3 全量校验失败的问题问题描述：成功创建迁移任务，并成功执行全量迁移，迁移校验失败，报错提示类似如下：failed (insert=0 update=6 delete=0)If you want to repair data.please read the following files:/data/dgq/portal/portal/workspace/25/check_result/result/repair_source_db_table1_0_0.txtrepair_source_db_table1_0_0.txt中内容如下:update `source_db`.`table1` set name='data' , col='data1' where id=1 ;update `source_db`.`table1` set name='data' , col='data2' where id=2 ;update `source_db`.`table1` set name='data' , col='data3' where id=3 ;update `source_db`.`table1` set name='data' , col='data4' where id=4 ;update `source_db`.`table1` set name='data' , col='data5' where id=5 ;update `source_db`.`table1` set name='data' , col='data6' where id=6 ;然而手动校验迁移后table1表中的数据，数据正确。问题原因：MySQL创建表table1时，字段NAME的字段名使用的是大写，建表语句如下：CREATE TABLE table1 ( id INT, NAME VARCHAR(10), col VARCHAR(20), PRIMARY KEY(id));由于，迁移到openGauss端后，迁移过程创建的table1表格的建表语句如下：CREATE TABLE table1 ( id integer NOT NULL, "NAME" character varying(10), col character varying(20))WITH (orientation=row, compression=no);ALTER TABLE table1 ADD CONSTRAINT pk_table1_1712058063_0 PRIMARY KEY USING btree (id);可见大写的NAME被双引号括起来，因此导致全量校验的时候，由于双引号的问题，导致检验时无法匹配两边的name字段名，导致校验无法通过。问题解决：MySQL端创建表格时，字段名使用小写，问题解决。5.4 全量检验未校验，便进行下一步骤增量迁移的问题问题原因： 内存不够问题解决： 释放服务器内存后，再次尝试5.5 增量迁移删除拥有主键的表失败的问题问题原因：对于drop table操作，当表含有关联对象是，例如视图，MySQL端可以用drop table只删除表而保留视图，openGauss端用drop table仅删除表会失败，此问题属于内核兼容性问题。因此对于MySQL端的drop table语句，openGauss端将采用drop table cascade一并删除表及其关联的对象。因此增量迁移源端删除有关联对象的表，目标端无法删除，导致此问题的出现。问题解决：删除表格关联对象后，再删除此表。5.6 增量迁移创建view失败的问题问题原因：由于增量迁移解析出的创建view的语句语法类似如下：CREATE ALGORITHM=UNDEFINED DEFINER=`test`@`%` SQL SECURITY DEFINER VIEW `view1` AS SELECT * FROM table1;由于语句中包含@符号，而openGauss端执行此创建view的语句，会在@符号处报出语法错误。因此导致失败。问题解决：通过如下命令设置openGauss的b_compatibility_user_host_auth参数值为on使其支持此语法，问题便得到解决。set b_compatibility_user_host_auth to on;b_compatibility_user_host_auth参数说明：参数说明：控制是否允许创建user@host、‘user’@'host’之类的用户并兼容mysql的user@host认证鉴权，对兼容mysql的user@host进行认证时，需要在配置文件postgresql.conf中设为on。取值范围：布尔型默认值：off示例：openGauss=# show b_compatibility_user_host_auth; b_compatibility_user_host_auth-------------------------------- off(1 row)5.7 反向迁移成功启动，数据反向迁移未成功的问题问题描述：创建迁移任务，无前置校验问题，成功进行全量迁移，增量迁移，数据同步后，停止增量迁移，反向迁移成功启动，在openGauss端添加数据记录，反向迁移条数仍为0，且MySQL端未成功同步数据。问题原因：openGuass数据库未开启用户复制权限的支持，即使用户的权限管理中具有复制的权限，但是数据库也需要通过修改配置文件pg_hba.conf，在文件末尾配置host replication {用户名} 0.0.0.0/0 sha256，如此用户才能进行复制相关操作。其中，用户名也可以换成all，以支持所有用户的复制权限。个人理解： 用户虽然具有复制权限，但是数据库服务不支持用户使用复制权限进行复制相关操作，因此需要开启数据库对复制权限的管理。就比如我有从仓库拿东西的权限，所以我可以往外拿东西，但是后来仓库管理员说所有东西都不可以往外拿东西，那么即使我有往外拿东西的权限，他也不让我往外拿东西。配置的目的便是，领导告诉仓库管理员，现在可以让我往外拿东西，那么我再往外拿东西的时候，便能拿出来了。相当于用户有用户的权限管理，然后仓库管理员有仓库管理员的权限管理，两层权限都有，我才能往外拿东西。问题解决：修改配置文件pg_hba.conf，在文件末尾配置host replication {用户名} 0.0.0.0/0 sha256。或通过如下命令配置，命令如下：gs_guc set -D /opt/datakit/opengauss/datanode/dn1 -h "host replication {用户名} 0.0.0.0/0 sha256"配置完成后重启数据库，使配置生效，重启数据库的命令如下：gs_ctl restart -D /opt/datakit/opengauss/datanode/dn1

作者：宥谦openGauss 6.0.0-RC1是openGauss 2024年3月发布的创新版本，闲来无事翻阅文档，被一条新增特性内吸引了目光：内核工具：支持一站式交互安装用户通过交互界面输入数据库的相关信息，系统自动生成xml配置文件，并自动进行数据库的初始化安装。我是从去年开始接触国产数据库openGauss，之前一直使用的是成熟的Mysql，Oracle等数据库，对比之下，openGauss的安装方式要比他们麻烦不少，在折腾5.0的时候，预安装（初始化安装）这一步也阻塞了不少时间，看到这个特性，那必须要体验一番。环境准备先附上官方文档：一站式安装指南；可以看到默认的选项是一主两备集群；因此，先准备三台虚拟机用于测试；IP信息如下：10.125.10.1410.125.10.6710.125.10.229系统操作信息如下：[root@localhost ~]# cat /etc/os-release NAME="openEuler" VERSION="22.03 (LTS-SP1)" ID="openEuler" VERSION_ID="22.03" PRETTY_NAME="openEuler 22.03 (LTS-SP1)" ANSI_COLOR="0;31" [root@localhost ~]# uname -a Linux localhost.localdomain 5.10.0-136.12.0.86.oe2203sp1.x86_64 #1 SMP Tue Dec 27 17:50:15 CST 2022 x86_64 x86_64 x86_64 GNU/Linux规格为8C16G；基于之前安装5.0.0版本的经验，将官方文档中准备软硬件安装环境这一步骤整合在一起使用shell脚本一键执行，方便操作；其中python使用openEuler 22.03 LTS SP1镜像自带版本，版本信息如下：[root@gauss1 rpms]# python3 --version Python 3.9.9一键脚本主要内容如下（加粗部分是与官方文档存在差异及踩坑的部分）:安装软件依赖;除官方文档内的三个依赖外，经过测试，expect依赖也是必须；[root@gauss1 rpms]# ll 总用量 488 -rw-r--r--. 1 root root 247025 4月 18 20:52 expect-5.45.4-7.oe2203sp1.x86_64.rpm -rw-r--r--. 1 root root 22141 4月 19 10:37 libaio-0.3.113-5.oe2203sp1.x86_64.rpm -rw-r--r--. 1 root root 10817 4月 19 10:36 libaio-devel-0.3.113-5.oe2203sp1.x86_64.rpm -rw-r--r--. 1 root root 211561 4月 19 13:52 readline-devel-8.1-2.oe2203sp1.x86_64.rpm修改防火墙配置设置主机名(由于使用云平台模板创建的虚拟机,三台虚拟机名称统一为localhost.localdomain,修改为不同主机名)关闭RemoveIPC创建用户组和用户(必须为omm用户和dbgroup用户组),之前使用的是安装5.0.0时设置的dbgrp用户组，在测试过程中出现了错误关闭THP拷贝安装包内的pssh工具到虚拟机内：在前面的多次测试中，总会报错pssh命令不存在的错误，翻阅安装包及后续成功的经验来看，openGauss初始化安装过程中其中一步是设置自身携带的pssh工具路径，但在这之前会尝试直接使用pssh，而pssh并不是镜像必备软件，会报错命令不存在，因此要手动拷贝安装包内此软件到/usr/bin/目录下；其中，安装包内工具路径为openGauss-6.0.0-RC1-openEuler-64bit-om/script/gspylib/pssh/bin/pssh，同级目录下还有pscp和TaskPool.py脚本，为了方便，一起拷贝；拷贝完成后，执行chmod +x pssh pscp TaskPool.py赋予执行权限；将此脚本依次在三台虚拟机上执行，就完成了环境准备的全部内容；一站式初始化安装在三台虚机内创建/opt/openGauss目录；mkdir -p /opt/openGauss将安装包上传到第一台虚拟机(10.125.10.14)root目录下，执行解压命令，将安装包解压到/opt/openGauss目录下；[root@gauss1 ~]# ll |grep openEuler -rw-r--r--. 1 root root 151532247 4月 18 20:29 openGauss-6.0.0-RC1-openEuler-64bit-all.tar.gz [root@gauss1 ~]# tar -zxf openGauss-6.0.0-RC1-openEuler-64bit-all.tar.gz -C /opt/openGauss/进入/opt/openGauss，解压OM安装包到当前目录；[root@gauss1 ~]# cd /opt/openGauss/ [root@gauss1 ~]# tar -zxf openGauss-6.0.0-RC1-openEuler-64bit-om.tar.gz进入script目录，执行初始化安装命令，我并没有使用环境分离，因为去掉环境分离参数(--sep-env-file=ENVFILE)；[root@gauss1 ~]# cd script[root@gauss1 ~]# ./gs_preinstall -U omm -G dbgroup --one-stop-install到这一步根据提示，全部选择默认，跟随提示交互输入即可；​初始化安装成功如下图：执行数据库安装初始化安装完成后，安装就简单了，切换到omm用户下执行安装命令即可；根据初始化安装过程中的提示，生成的xml路径为：/opt/openGauss/script/base_utils/template/cluster.xml使用此路径进行安装即可[root@gauss1 ~]# su - omm [root@gauss1 ~]# gs_install -X /opt/openGauss/script/base_utils/template/cluster.xml安装成功截图如下：使用gs_om -t status --detail查询数据库状态可以看到数据库正常：注意实践过程中，饶是我已经有了很多安装5.0.0的经验，但还是耗费了一整体时间才安装成功，因此，感觉还是有几点需要注意，写在这里备忘。请选择是否部署资源池化和请选择是否部署CM的选项，1和2不是相同含义，如果不选择默认，一定要注意；除官方提醒的三个依赖外，还需要安装expect依赖，且三个节点都需要安装；所有的初始化安装和安装命令均需要解压OM安装包后进入script包执行；openGauss依赖SSE4_2指令集，使用不同厂商云平台创建虚机安装的时候一定要注意如何设置，使虚拟机支持此指令集；pssh提前拷贝(这是不是BUG)

GaussDB中的视图管理引言数据库管理是企业数据存储和分析的核心。GaussDB作为华为推出的一款高性能分布式数据库，它提供了强大的数据管理功能，包括数据的存储、查询、更新和删除等。在这些功能中，视图（View）是一个重要的概念，它允许用户以一种逻辑上简化的方式访问和操作数据。视图的概念视图是基于数据库中一个或多个表的查询结果集。它是一个虚拟表，其内容由SQL查询定义。使用视图可以简化复杂的查询，提高数据安全性，并且能够为不同的用户或应用提供定制化的数据视图。视图的优点简化复杂查询：视图可以将复杂的SQL查询简化为单一的视图，使得用户无需编写复杂的SQL语句即可访问数据。逻辑数据独立性：视图提供了逻辑数据独立性，即使底层表结构发生变化，视图的逻辑定义可以保持不变。安全性：视图可以用来限制用户对某些数据的访问，只展示他们需要看到的数据。重用SQL语句：视图允许用户重用SQL语句，避免重复编写相同的查询逻辑。创建视图在GaussDB中创建视图非常简单，使用CREATE VIEW语句即可。下面是一个创建视图的基本语法：CREATE VIEW view_name AS SELECT column1, column2, ... FROM table_name WHERE condition;例如，如果你想创建一个视图来显示所有客户的姓名和电子邮件地址，你可以这样写：CREATE VIEW customer_emails AS SELECT name, email FROM customers WHERE active = TRUE;使用视图一旦视图被创建，你可以像使用普通表一样使用它。你可以对视图执行SELECT、INSERT、UPDATE和DELETE操作，就像对普通表一样。-- 使用视图查询数据 SELECT * FROM customer_emails; -- 向视图中插入数据 INSERT INTO customer_emails (name, email) VALUES ('John Doe', 'john@example.com'); -- 更新视图中的数据 UPDATE customer_emails SET email = 'newemail@example.com' WHERE name = 'John Doe';视图的局限性尽管视图提供了许多便利，但它们也有一些局限性：更新限制：有些视图可能不允许更新，特别是那些包含GROUP BY、DISTINCT或JOIN的视图。性能问题：如果视图定义的查询非常复杂，使用视图可能会影响性能。数据不一致：如果视图基于的表数据频繁变化，视图可能不会实时反映这些变化。结语视图是数据库中一个非常有用的工具，它可以帮助我们以一种更加直观和安全的方式来管理和访问数据。GaussDB通过支持视图，为用户提供了一种灵活且强大的数据管理方式。正确使用视图可以大大提高数据库的可用性和效率。希望这篇博客能够帮助你更好地理解GaussDB中的视图管理。如果你有任何问题或需要进一步的帮助，请随时联系我们。

OpenGauss 逻辑复制在数据库管理领域，数据复制是一项关键技术，用于实现数据的备份、分发和高可用性。OpenGauss 提供了逻辑复制功能，为数据的灵活处理和分发提供了强大的支持。一、什么是 OpenGauss 逻辑复制OpenGauss 的逻辑复制是一种基于表级别的数据复制机制。它允许将指定表中的数据更改（插入、更新和删除操作）以逻辑日志的形式从一个数据库实例复制到另一个数据库实例。二、逻辑复制的工作原理发布（Publication） 在源数据库中，定义要复制的表集合，并创建发布对象。订阅（Subscription） 在目标数据库中，创建订阅对象，指定要连接的源数据库和要订阅的发布。当源数据库中对已发布的表进行数据更改操作时，这些更改会被记录在逻辑日志中。目标数据库通过连接源数据库，并读取和应用这些逻辑日志，实现数据的同步更新。三、配置逻辑复制的步骤启用逻辑复制 在源数据库和目标数据库的配置文件中，确保相关参数已正确设置以支持逻辑复制。创建发布CREATE PUBLICATION publication_name FOR TABLE table1, table2,...;创建订阅CREATE SUBSCRIPTION subscription_name CONNECTION 'host=source_host port=source_port dbname=source_database user=source_user password=source_password' PUBLICATION publication_name;四、逻辑复制的优势灵活性 可以选择特定的表进行复制，而不必复制整个数据库。数据分发 便于将数据分发到不同的系统或应用，以满足特定的业务需求。降低系统负载 与物理复制相比，对系统资源的消耗相对较小。五、应用场景数据迁移和同步 在不同的数据库环境之间迁移或同步部分数据。数据分发和共享 将数据提供给多个下游系统或应用，实现数据的共享和利用。数据分析和处理 将生产数据复制到分析环境，进行数据分析和处理，而不影响生产系统的性能。六、注意事项数据一致性 确保源数据库和目标数据库之间的网络连接稳定，以避免数据丢失或不一致。性能优化 根据数据量和更新频率，合理调整相关参数，优化复制性能。冲突处理 当多个并发操作同时发生时，可能会出现冲突，需要制定相应的冲突处理策略。总之，OpenGauss 的逻辑复制为数据库管理员和开发者提供了一种高效、灵活的数据复制解决方案，能够满足各种复杂的业务需求。

OpenGauss 常用语法总结OpenGauss 是一款强大的数据库，以下是一些常用的语法总结：一、创建数据库CREATE DATABASE database_name;二、创建表CREATE TABLE table_name ( column1 data_type, column2 data_type, ... );三、插入数据INSERT INTO table_name (column1, column2,...) VALUES (value1, value2,...);四、查询数据SELECT column1, column2,... FROM table_name WHERE condition;五、更新数据UPDATE table_name SET column1 = value1, column2 = value2,... WHERE condition;六、删除数据DELETE FROM table_name WHERE condition;七、创建索引CREATE INDEX index_name ON table_name (column_name);八、创建视图CREATE VIEW view_name AS SELECT column1, column2,... FROM table_name WHERE condition;九、聚合函数SELECT COUNT(column_name), SUM(column_name), AVG(column_name), MAX(column_name), MIN(column_name) FROM table_name;十、排序结果SELECT column1, column2,... FROM table_name ORDER BY column_name ASC|DESC;十一、条件判断CASE WHEN condition1 THEN result1 WHEN condition2 THEN result2 ... ELSE default_result END十二、子查询SELECT column_name(s) FROM table_name WHERE column_name OPERATOR ( SELECT column_name FROM table_name WHERE condition );

OpenGauss 主备数据库同步的最佳实践在部署和维护 OpenGauss 主备数据库架构时，遵循一些最佳实践可以确保高效的数据同步和系统的高可用性。以下是一些关键的最佳实践：一、硬件和基础设施1. 相似的硬件配置主备节点应具有相似的硬件性能，包括 CPU、内存、存储和网络带宽。这有助于避免因性能差异导致的数据同步延迟或不一致。2. 独立的网络链路为主备节点之间的数据传输提供专用且稳定的网络链路，减少网络拥塞和干扰。二、数据库配置1. 合理设置 WAL 参数wal_level：如前面提到的，设置为 replica 以支持完整的 WAL 日志记录。wal_buffers：根据系统内存和事务负载进行适当调整，以确保 WAL 生成的效率。wal_sync_method：选择适合您系统的同步方法，如 fsync 或 open_datasync 。2. 优化主节点参数调整 checkpoint_timeout 和 checkpoint_completion_target ，以平衡检查点操作对性能的影响和数据的一致性。三、监控和告警1. 实时监控同步状态使用工具持续监控主备节点之间的 WAL 发送和接收情况，以及复制延迟。例如，通过 pg_stat_replication 视图获取详细的同步信息。2. 设定告警阈值为复制延迟、WAL 积压等关键指标设置告警阈值，及时通知管理员处理异常。四、定期测试和演练1. 主备切换测试定期进行主备切换的演练，以验证切换过程的顺利性和数据的完整性。2. 数据验证定期比较主备节点的数据，确保数据的一致性。五、备份策略1. 主备节点备份同时对主备节点进行定期备份，以防止数据丢失或损坏。2. 异地存储将备份数据存储在异地，以应对本地灾难情况。六、安全考虑1. 网络安全确保主备节点之间的网络通信是加密和安全的，防止数据泄露。2. 访问控制对主备节点的数据库访问进行严格的权限控制，只授予必要的权限。

OpenGauss 主备数据库同步问题的解决方法在使用 OpenGauss 构建主备数据库架构时，可能会遇到数据同步的问题。本文将探讨一些常见的解决方法，帮助您确保主备数据库之间的数据一致性和同步的稳定性。一、常见的数据同步问题1. 网络延迟或中断网络问题可能导致 WAL 日志传输延迟或中断，影响数据同步。2. 配置错误主备节点的配置不一致，如 postgresql.conf 和 recovery.conf 中的参数设置错误。3. 主节点负载过高主节点处理大量事务，导致 WAL 生成速度过快，备节点无法及时处理。二、解决方法1. 检查网络连接确保主备节点之间的网络连接稳定，可通过网络监控工具检查延迟和丢包情况。2. 核对配置参数仔细检查主备节点的以下关键配置：在主节点的 postgresql.conf 中：wal_level：确保设置为 replica 以支持备节点同步。max_wal_senders：根据备节点数量合理设置。在备节点的 recovery.conf 中：standby_mode：确认设置为 on 。primary_conninfo：准确配置主节点的连接信息，包括 IP 地址、端口、用户名和密码。3. 优化主节点性能调整数据库参数，如 shared_buffers、work_mem 等，以提高主节点的处理能力。对频繁操作的表进行索引优化，减少事务处理时间。4. 监控同步状态使用 OpenGauss 提供的工具和命令，如 pg_stat_replication 视图，实时监控主备节点之间的同步状态，及时发现并解决潜在问题。5. 调整 WAL 发送和接收参数根据网络带宽和主备节点的性能，适当调整 wal_keep_segments、wal_sender_timeout 等参数。三、案例分析假设遇到主备节点数据不同步，通过检查发现是网络延迟导致 WAL 日志传输不及时。解决方法是优化网络设置，增加网络带宽，并调整 wal_sender_timeout 参数以适应较高的网络延迟。总之，解决 OpenGauss 主备数据库同步问题需要综合考虑网络、配置和性能等多方面因素。通过仔细排查和合理优化，可以确保主备数据库之间的数据同步正常，提高数据库系统的可用性和可靠性。

OpenGauss 主备搭建OpenGauss 是一款高性能、高安全、高可靠的企业级开源关系型数据库。在实际应用中，为了确保数据库的高可用性，通常会搭建主备架构。下面将详细介绍 OpenGauss 主备搭建的过程及相关命令。一、环境准备准备两台服务器，分别作为主节点和备节点。安装相同版本的 OpenGauss 数据库。二、主节点配置编辑 postgresql.conf 文件sudo vi $PGDATA/postgresql.conf修改以下参数：listen_addresses = '*' wal_level = replica max_wal_senders = 10 wal_keep_segments = 32编辑 pg_hba.conf 文件，添加备节点的访问权限sudo vi $PGDATA/pg_hba.conf例如：host replication all 192.168.1.2/32 md5重启主节点数据库gs_ctl restart -D $PGDATA三、备节点配置初始化备节点数据库gs_initdb -D $PGDATA编辑 postgresql.conf 文件sudo vi $PGDATA/postgresql.conf修改以下参数与主节点保持一致（除了 port 等特定参数）：wal_level = replica编辑 recovery.conf 文件sudo vi $PGDATA/recovery.conf添加以下内容：standby_mode = 'on' primary_conninfo = 'host=192.168.1.1 port=5432 user=replication_user password=replication_password' recovery_target_timeline = 'latest'启动备节点数据库gs_ctl start -D $PGDATA四、验证主备同步在主节点上执行一些数据库操作，然后在备节点上查看数据是否同步。通过以上步骤，就成功搭建了 OpenGauss 的主备架构，提高了数据库的可用性和可靠性。需要注意的是，在实际生产环境中，还需要根据具体的网络环境、安全要求等进行更详细的配置和优化。

mysql版本是8.0的。opengauss版本是6.0.0的，使用的工具是portal

断电后，opengauss数据库起不来了？报错：[omm@bogon root]$ gs_om -t start Starting cluster. ========================================= ========================================= [GAUSS-53600]: Can not start the database, the cmd is source /home/omm/.bashrc; python3 '/opt/huawei/install/om/script/local/StartInstance.py' -U omm -R /opt/huawei/install/app -t 300 --security-mode=off,  Error: [GAUSS-51400] : Failed to execute the command: source /home/omm/.bashrc; python3 '/opt/huawei/install/om/script/local/StartInstance.py' -U omm -R /opt/huawei/install/app -t 300 --security-mode=off. Error: [FAILURE] localhost.localdomain: .. [omm@bogon root]$ gs_om -t status [GAUSS-51652] : Failed to get cluster node info.exception is: list index out of range. 

1. 环境：      OS: openeuler 20.03 LTS      DB: opengauss 5.0.0 lts      服务器：物理pc2. 问题复现过程：    2.1 安装opengauss 5.0.0 lts，断电前数据库状态正常，可登录，可查询； 2.2 长按power键断电，重新接电启动系统，执行gs_om命令查询数据库状态即报错： 2.3 再执行启动/重启命令时报错： 2.4 直接把StartInstance.py命令copy出来执行，报错： 2.5 于是查询下hostname和clusterconfig.xml文件：但是尝试了修改hostname和xml文件后重启，仍然没有成功。补充： 1. 仅长按power键关机复现，直接拔电源线不复现。          2. 用gs_ctl命令可以重启，但gs_om命令执行就报错。

openGauss主备容灾搭建是一个确保数据库系统高可用性和数据安全性的重要步骤。以下是关于openGauss主备容灾搭建的详细步骤和注意事项，参考了上述文章中的相关信息：前期准备1.1 评估数据量与网络带宽 数据量：主数据库实例存储的数据量直接影响容灾搭建需要传输的数据量。 网络带宽：数据量结合异地网络带宽，直接影响容灾搭建时长。例如，100TB数据在512Mbps带宽下传输大约需要19天。 1.2 设置超时时间 在搭建容灾接口的"time-out"设置超时时间，当前默认值为20min。超时时间的评估与主数据库实例搭容灾前的数据量与异地可使用带宽相关，计算公式为“数据量/传输速率 = 耗时”。 1.3 保留日志 容灾搭建过程中，主数据库实例需要保留在本地的日志量。如果搭建过程预计持续2天，那么这2天内的日志需要在搭建完成前保留在主数据库实例本地磁盘。 2. 搭建步骤 2.1 部署方案 一主一备：主备模式相当于两个数据副本，主机和备机各一个数据副本，备机接受日志、执行日志回放。 多副本：一般多副本部署时使用1主2备模式，总共3个副本，可靠性为99.99%。 2.2 创建容灾用户 在主集群创建具有流复制权限的容灾用户，用于容灾鉴权。主备集群必须使用相同的容灾用户名和密码。 2.3 发送搭建请求 使用gs_sdr工具对主备数据库实例发送搭建请求。 2.4 验证安装 安装完成后，验证主备节点的状态和数据同步情况。 3. 注意事项 3.1 网络时延 主数据库实例或灾备数据库实例内网络时延要求<=10毫秒，主备数据库实例之间异地网络时延要求<=100毫秒。 3.2 磁盘规格 如果磁盘混合部署，应采用低配部分的规格。例如，如果数据库实例内有NVMe和SATA盘，请参考SATA盘配置的规格。 3.3 灾备升主 灾备数据库实例升主允许丢失一定的数据，RPO<=10秒；灾备数据库实例处于normal态，灾备升主RTO<=10分钟。 3.4 用户与密码 搭建容灾前需要在主集群创建容灾用户。一次容灾搭建后，该用户密码不可修改，伴随整个容灾生命周期。 3.5 升级与维护 容灾状态下仅支持灰度升级，且需要遵循先升级主集群，再升级备集群的顺序。 3.6 安全性 建议对于流式容灾流复制IP的选择，考虑使集群内的网络平面与跨集群网络平面分离，提高安全性。 4. 总结 openGauss主备容灾搭建是一个复杂但重要的过程，需要仔细评估数据量、网络带宽、磁盘规格等因素，并遵循正确的搭建步骤和注意事项。通过合理的容灾策略和技术手段，可以确保数据库系统的高可用性和数据安全性。