本页为您介绍如何使用使用 IF NOT EXISTS关键字。 带IF NOT EXISTS 关键字作用表示表不存在时才创建。 teledb create table t(id int,mc text); CREATE TABLE teledb create table t(id int,mc text); ERROR: relation "t" already exists teledb create table IF NOT EXISTS t(id int,mc text); NOTICE: relation "t" already exists, skipping CREATE TABLE

d+ tnativemullistgd Table "public.tnativemullistgd" Column Type Collation Nullable Default Storage Stats target Description ++++++ + f1 bigint not null nextval('tnativemullistf1seq'::regclass) plain f2 integer plain f3 text extended f4 text extended f5 timestamp(0) without time zone plain Partition of: tnativemullist FOR VALUES IN ('广东') Partition constraint: ((f3 IS NOT NULL) AND (f3 ANY (ARRAY['广东'::text]))) Partition key: RANGE (f5) Partitions: tnativemullistgd201701 FOR VALUES FROM ('20170101 00:00:00') TO ('20170201 00:00:00'), tnativemullistgd201702 FOR VALUES FROM ('20170201 00:00:00') TO ('20170301 00:00:00') Distribute By: SHARD(f1) Location Nodes: ALL DATANODES TeleDB支持存在1级和2级分区混用，大家不需要都平级。

insert into public.t3 values(1,'test'); INSERT 0 1 由于teledb模式在第一顺位，且存在同名表，所以始终是teledb模式下的空表 teledb select from t3; id content + (0 rows) 指定public模式去查询可以查到插入的数据 teledb select from public.t3; id content + 1 test (1 row) 访问不在搜索路径的对象时，需要写全路径。 teledb create table test1.t4 (id int, name char); CREATE TABLE teledb select from t4; ERROR: relation "t4" does not exist LINE 1: select from t4; ^ teledb select from test1.t4; id name + (0 rows) 上面出错是因为模式test1没有配置在searchpath搜索路径中。

本文为您介绍如何修改模式属性。 您可参考如下操作修改模式属性。 修改模式名 teledb alter schema teledbschema rename to teledbschemanew; ALTER SCHEMA 修改所有者 teledb dn teledbschemanew List of schemas Name Owner + teledbschemanew teledb (1 row) teledb alter schema teledbschemanew owner to teledbuser; ALTER SCHEMA teledb dn teledbschemanew List of schemas Name Owner + teledbschemanew teledbuser (1 row)

本文为您介绍如何删除模式。 您可执行如下操作删除模式。 teledb drop schema teledbschemaowner; DROP SCHEMA 当模式中存在对象时，则会删除失败，提示如下。 teledb create table teledbschemanew.test(id int); CREATE TABLE teledb drop schema teledbschemanew; ERROR: cannot drop schema teledbschemanew because other objects depend on it DETAIL: table teledbschemanew.test depends on schema teledbschemanew HINT: Use DROP ... CASCADE to drop the dependent objects too. 您可参考如下操作强制删除，会将模式中的对象也级联删除。 teledb drop schema teledbschemanew cascade; NOTICE: drop cascades to table teledbschemanew.test DROP SCHEMA

本文为您介绍实例主机手动创建了teledbx用户导致开通实例失败的问题原因和解决方案。 问题现象 创建实例开通失败。 原因分析 经过查看错误日志，发现其手动创建teledbx用户。由于在开通创建实例时，系统会自动创建teledbx用户，无需手动创建。 解决方案 1. 执行如下命令删除实例主机teledbx用户。 userdel teledbx 2. 在管控台中选择实例管理> 工单管理 ，单击所创建实例行所在的操作 列的重新施工即可。

广州12345政府服务热线，业务的核心TeleDB服务器部署内网，敏感数据部署在这个核心TeleDB实例中，并涉及到130个部门，8千余个分类，4万余条知识点。该系统要求系统具备高安全性，目前存储了6000+加密表，同时要求通信链路加密，数据脱敏，访问白名单，TeleDB的多级安全策略在该业务系统有了完美的落地。该系统的核心系统结构如下：

本文为您介绍实例开通时，勾选备份机导致开通实例失败的问题现象、原因和解决方案。 问题现象 提交工单后，在工单管理中显示实例施工失败。 原因分析 勾选备份机导致开通实例失败。 解决方案 去勾选备份机，重新提交工单。

当提交工单显示系统错误时，您可以参考本文，查看问题现象、问题原因和解决方案。 问题现象 提交工单显示系统错误。 查看日志发现是sql插入有问题，instmanager的vip列插入失败。 原因分析 开通实例使用到了8个vip，给的varchar字符窜长度不够。 解决方案 执行如下命令增加vip列的varchar长度，将其修改为255。 use dcp desc instmanager alter table instmanager modify column vip varchar(255);

添加主机时，如果硬件联通及测试主机失败，则您需要添加安全组，放通监控插件端口。 问题现象 添加主机时，测试连通及硬件检测失败。 原因分析 监控插件端口未放通。 解决方案 添加安全组，放通端口。出现如下图所示，则表示执行成功。

安装后校验 1. 检查容器状态：docker ps grep E 'dmsdas' 2. 检查启动日志：docker logs f 卸载服务 1. 查看容器ID，docker ps grep E 'dmsdas' 2. 停止容器：docker stop 3. 移除容器：docker rm 4. 查看镜像ID：docker images grep E 'dmsdas' 5. 移除镜像：docker rmi

当导入的teledbx内核版本与实例开通的版本选择不一致时，您可以参考本文查看问题现象、问题原因和解决方案。 问题现象 导入的teledbx内核版本与实例开通的版本选择不一致。 原因分析 导入配置库的sql语句数据错误，dcp的README.md文件是6.11版本的规格。 解决方案 修改dcp库的prodtemplate表数据。 mysql> use dcp mysql> select id ,prodversion from prodtemplate; ++ id prodversion ++ 8 5.7 9 6.11 10 6.11 ++ 3 rows in set (0.00 sec) mysql> update prodtemplate set prodversion'6.13' where id9; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> update prodtemplate set prodversion'6.13' where id10; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select id ,prodversion from prodtemplate; ++ id prodversion ++ 8 5.7 9 6.13 10 6.13 ++ 3 rows in set (0.00 sec)

迁移方案概述 迁移方案是通过源集群的zookeeper 做副本数据同步，架构如下： 前提条件： 要求源、目标集群在同一个网络，源、目标集群的分片数是相同的，另外建议源、目标集群的ck内核版本也一致，避免不同版本使用到的zstd 版本不一致导致merge出错 迁移条件 & 情况： 目标集群必须跟源集群具备相同的分片数，目标集群跟源集群网络相通； 只支持依赖zk的副本表； partitiong同步过程，源集群可正常读写，迁移过程源集群能正常读，但是不能写； 数据同步和迁移过程，不会删除源集群的数据； 数据同步过程源集群下的数据（本地数据 + cos数据）都会同步到目标集群下，因此目标集群下的容量要足够。 迁移步骤： 整体的迁移环节可概括为：创建临时表 （开始同步数据）和正式表 》修改临时表引擎为 MergeTree — 》从临时表把数据转移到正式表 》删除临时表 具体步骤如下： 1、在目标集群的各个分片选择一个节点，加入到tmpcluster里头去（metrika.xml文件中新增tmpcluster），修改目标集群的config.xml文件，把源集群的zk信息配置进来，如果有多个，那分别加入 ip1 2181 ip2 2181 ip3 2181 60000 30000 2、在目标集群上创建临时的副本表，绑定源集群的zk，以ReplicatedMergeTree为例子： CREATE TABLE tablenametmp on cluster tmpcluster ( ... ) ENGINE ReplicatedMergeTree('zookeeper2:path', '{replica}') ... 备注说明： 创建的临时副本表使用临时表名，在正式表后面加tmp。 创建的临时副本表使用的ZooKeeper路径和源端搬迁表的ZooKeeper路径需保持一致。 创建的临时副本表的表结构需和源端搬迁表保持一致。 3、创建完临时副本表之后，集群会自动通过源zk做part同步到目标集群的副本。期间不用做任何处理，可以准备下一步骤工作 （这个过程不要对临时表做任何数据分区操作，因为操作临时表分区就等于操作源集群对应正式表） 4、在目标集群创建正式名字的 副本表，采用默认zookeeper（可直接通过on cluster defaultcluster去创建） 5、同步完成之后，检查源集群和目标集群，各个表数据分布情况，数据准确性校验（查询part数，以及count总数是否匹配，校验数据准确性时最好做到源集群停写） 6、检查无误之后，在目标集群metadata 目录下，修改所有临时表的sql，把Engine均改成MergeTree （这步是为了迁移过程影响到源集群，保证源集群的数据可读），修改完后重启集群 —— 有现成脚本 7、执行DETACH 命令对临时表中的每个partition DETACH，然后登入目标集群，把临时表下detached目录的所有part mv 到对应的目标表的detached 目录下 —— 如果分区多，可用脚本完成，有现成脚本 例如：default 下lineorder表，可以执行 mv /data/clickhouse/clickhouseserver/data/default/lineordertmp/ detached/ /data/clickhouse/clickhouseserver/data/default/lineorder/detached/ 例如：default 下lineordertmp临时表，分区有'1992','1993','1994','1995','1996' 第一步：在studio上执行（也可以通过脚本去完成）: ALTER TABLE default.lineordertmp on cluster tmpcluster DETACH PARTITION '1992'; ALTER TABLE default.lineordertmp on cluster tmpcluster DETACH PARTITION '1993'; ALTER TABLE default.lineordertmp on cluster tmpcluster DETACH PARTITION '1994'; ALTER TABLE default.lineordertmp on cluster tmpcluster DETACH PARTITION '1995'; ALTER TABLE default.lineordertmp on cluster tmpcluster DETACH PARTITION '1996'; 第二步：登入到目标集群在各个节点上，执行: mv /data/clickhouse/clickhouseserver/data/default/lineordertmp/detached/ /data/clickhouse/clickhouseserver/data/default/lineorder/detached/ 8、执行attach 命令，把目标表下detached的part加载到表内 —— 如果分区多，可用脚本完成，有现成脚本（可找作者提供） 例如：default 下lineorder表，可以执行 alter table default.lineorder attach partition 'partitionname'; 依次把所有的partition 加载到正式表 9、所有的表迁移完成之后，删除临时表，再删除config.xml文件中的 auxiliaryzookeepers配置； 说明： 数据副本同步过程因为某种原因导致副本服务中断（可能是网络、bug、人为手工停止），再次重启后支持断点续传，不会影响源数据同步传输。 操作过程会涉及到多个partition的 DETACH和 attach命令，同时还需要登入到目标节点执行mv 操作，为了简化工作提高效率，减少过多人为操作而导致的失误，建议 通过批量工具（天翼云ClickHouse提供） + 脚本方式执行（找作者提供） 批量工具：批量分发文件到目标集群各个节点，批量在目标集群各个节点执行命令脚本等 参考脚本：查询一个表下的所有partition 列表，然后执行 DETACH命令， mv 命令 和最后的 attach命令 注意： 在添加临时表之后，源集群表的part就会自动通过zk做part复制，因为数据量很大，建议分批创建临时副本表，以免对源zk造成负载过高，从而影响业务 在临时表数据同步的过程中，一定不要对临时表做任何数据或是分区操作，操作临时表就等于操作源集群对应的正式表 在临时表数据同步过程，不能有ddl变化 方案优点：可支持对巨量副本表（几百个以上）的数据迁移，数据同步过程通过zk 做到后台自动同步，无需干预；同时支持对cos 数据的迁移； 不足：只能迁移ReplicatedMergeTree 引擎表，其它表不支持这种方案。

场景三：查询某个表的数据倾斜情况 执行以下SQL查询某个表的数据倾斜情况，其中tablename替换为实际的表名。 SELECT a.count,b.nodename FROM (SELECT count() AS count,xcnodeid FROM tablename GROUP BY xcnodeid) a, pgxcnode b WHERE a.xcnodeidb.nodeid ORDER BY a.count desc; 返回如下类似信息。若各DN上数据分布差小于10%，表明数据分布均衡。若大于10%，则表示数据出现倾斜。 gaussdb>SELECT a.count,b.nodename FROM (select count() as count,xcnodeid FROM staffs GROUP BY xcnodeid) a, pgxcnode b WHERE a.xcnodeidb.nodeid ORDER BY a.count desc; count nodename + 11010 datanode4 10000 datanode3 12001 datanode2 8995 datanode1 10000 datanode5 7999 datanode6 9995 datanode7 10000 datanode8 (8 rows)

本章节主要介绍导入过程存储倾斜即时检测的最佳实践。 导入过程中对DN导入行数进行统计，导入完成后计算倾斜率，超过一定阈值时，立即进行告警。倾斜率通过（DN导入行数最大值DN导入行数最小值）/导入总行数计算。目前，只支持INSERT和COPY导入。 说明 必须设置enablestreamoperatoron，确保计划下发到DN，DN一次性返回导入行数，从而可以在CN计算倾斜率。 使用方法 1.设置参数（表倾斜告警阈值tableskewnesswarningthreshold和表倾斜告警最小行数tableskewnesswarningrows）； −表倾斜告警阈值取值范围0~1，默认值为1，即关闭状态，取其他值时为开启状态。 −表倾斜告警最小行数取值范围0~2147483647，默认值为100,000。当导入总行数超过该值与导入DN数之积时，才可能触发告警，从而不会在小数据量导入的场景进行无意义的告警。 show tableskewnesswarningthreshold; set tableskewnesswarningthreshold xxx; show tableskewnesswarningrows; set tableskewnesswarningrows xxx; 2.执行导入，使用INSERT或者COPY； 3.发现并处理告警，告警信息包括表名、最小行数、最大行数、总行数、平均行数、倾斜率，以及提示信息（检查数据分布或者修改参数）。 WARNING: Skewness occurs, table name: xxx, min value: xxx, max value: xxx, sum value: xxx, avg value: xxx, skew ratio: xxx HINT: Please check data distribution or modify warning threshold

本节主要介绍恢复configsvr副本集 准备目录 rm rf /compile/clusterrestore/cfg mkdir p /compile/clusterrestore/cfg1/data/db mkdir p /compile/clusterrestore/cfg1/log mkdir p /compile/clusterrestore/cfg2/data/db mkdir p /compile/clusterrestore/cfg2/log mkdir p /compile/clusterrestore/cfg3/data/db mkdir p /compile/clusterrestore/cfg3/log 操作步骤 步骤 1 准备单节点配置文件和数据目录，以单节点方式启动进程。 配置文件如下（restoreconfig/single40303.yaml）。 net: bindIp: 127.0.0.1 port: 40303 unixDomainSocket: {enabled: false} processManagement: {fork: true, pidFilePath: /compile/clusterrestore/cfg1/configsvr.pid} storage: dbPath: /compile/clusterrestore/cfg1/data/db/ directoryPerDB: true engine: wiredTiger wiredTiger: collectionConfig: {blockCompressor: snappy} engineConfig: {directoryForIndexes: true, journalCompressor: snappy} indexConfig: {prefixCompression: true} systemLog: {destination: file, logAppend: true, logRotate: reopen, path: /compile/clusterrestore/cfg1/log/configsingle.log} 准备数据，将解压后的configsvr文件拷贝到单节点dbPath目录下。 cp aR /compile/download/backups/cac1efc8e65e42ecad8953352321bfeein0241c8a32fb10245899708dea453a8c5c9no02/ /compile/clusterrestore/cfg1/data/db/ 启动进程。 ./mongod f restoreconfig/single40303.yaml 步骤 2 连接单节点，执行配置命令。 连接命令：./mongo host 127.0.0.1 port 40303 执行如下命令，修改副本集配置信息。 var cfdb.getSiblingDB('local').system.replset.findOne(); cf['members'][0]['host']'127.0.0.1:40303'; cf['members'][1]['host']'127.0.0.1:40304'; cf['members'][2]['host']'127.0.0.1:40305'; cf['members'][0]['hidden']false; cf['members'][1]['hidden']false; cf['members'][2]['hidden']false; cf['members'][0]['priority']1; cf['members'][1]['priority']1; cf['members'][2]['priority']1; db.getSiblingDB('local').system.replset.remove({}); db.getSiblingDB('local').system.replset.insert(cf) 执行如下命令，清理内置账号。 db.getSiblingDB('admin').dropAllUsers(); db.getSiblingDB('admin').dropAllRoles(); 执行如下命令，更新mongos和shard信息。 db.getSiblingDB('config').mongos.remove({}); 先查询config.shards表中的多个shard的id信息，用于下面语句的id的查询条件。逐个更新每条记录。 db.getSiblingDB('config').shards.update({'id' : 'shard1'},{$set: {'host': 'shard1/127.0.0.1:40306,127.0.0.1:40307,127.0.0.1:40308'}}) db.getSiblingDB('config').shards.update({'id' : 'shard2'},{$set: {'host': 'shard2/127.0.0.1:40309,127.0.0.1:40310,127.0.0.1:40311'}}) db.getSiblingDB('config').mongos.find({}); db.getSiblingDB('config').shards.find({}); 执行如下命令，关闭单节点进程。 db.getSiblingDB('admin').shutdownServer(); 步骤 3 搭建configsvr副本集。 准备副本集配置文件和目录，将configsvr1节点的dbPath文件拷贝到其他两个节点目录下。 cp aR /compile/clusterrestore/cfg1/data/db/ /compile/clusterrestore/cfg2/data/db/ cp aR /compile/clusterrestore/cfg1/data/db/ /compile/clusterrestore/cfg3/data/db/ 修改configsvr1节点配置文件，增加副本集配置属性（restoreconfig/configsvr40303.yaml）。 net: bindIp: 127.0.0.1 port: 40303 unixDomainSocket: {enabled: false} processManagement: {fork: true, pidFilePath: /compile/clusterrestore/cfg1/configsvr.pid} replication: {replSetName: config} sharding: {archiveMovedChunks: false, clusterRole: configsvr} storage: dbPath: /compile/clusterrestore/cfg1/data/db/ directoryPerDB: true engine: wiredTiger wiredTiger: collectionConfig: {blockCompressor: snappy} engineConfig: {directoryForIndexes: true, journalCompressor: snappy} indexConfig: {prefixCompression: true} systemLog: {destination: file, logAppend: true, logRotate: reopen, path: /compile/clusterrestore/cfg1/log/configsvr.log} 启动进程。 ./mongod f restoreconfig/configsvr40303.yaml 修改configsvr2节点配置文件，增加副本集配置属性（restoreconfig/configsvr40304.yaml）。 net: bindIp: 127.0.0.1 port: 40304 unixDomainSocket: {enabled: false} processManagement: {fork: true, pidFilePath: /compile/clusterrestore/cfg2/configsvr.pid} replication: {replSetName: config} sharding: {archiveMovedChunks: false, clusterRole: configsvr} storage: dbPath: /compile/clusterrestore/cfg2/data/db/ directoryPerDB: true engine: wiredTiger wiredTiger: collectionConfig: {blockCompressor: snappy} engineConfig: {directoryForIndexes: true, journalCompressor: snappy} indexConfig: {prefixCompression: true} systemLog: {destination: file, logAppend: true, logRotate: reopen, path: /compile/clusterrestore/cfg2/log/configsvr.log} 启动进程 ./mongod f restoreconfig/configsvr40304.yaml 修改configsvr3节点配置文件，增加副本集配置属性（restoreconfig/configsvr40305.yaml）。 net: bindIp: 127.0.0.1 port: 40304 unixDomainSocket: {enabled: false} processManagement: {fork: true, pidFilePath: /compile/clusterrestore/cfg2/configsvr.pid} replication: {replSetName: config} sharding: {archiveMovedChunks: false, clusterRole: configsvr} storage: dbPath: /compile/clusterrestore/cfg2/data/db/ directoryPerDB: true engine: wiredTiger wiredTiger: collectionConfig: {blockCompressor: snappy} engineConfig: {directoryForIndexes: true, journalCompressor: snappy} indexConfig: {prefixCompression: true} systemLog: {destination: file, logAppend: true, logRotate: reopen, path: /compile/clusterrestore/cfg2/log/configsvr.log} 启动进程。 ./mongod f restoreconfig/configsvr40305.yaml 步骤 4 等待选主成功。 ./mongo host 127.0.0.1 port 40303 执行命令rs.status()，查看是否已存在主节点Primary。

本文主要介绍恢复mongos节点 步骤 1 准备mongos节点的配置文件和目录。 rm rf /compile/clusterrestore/mgs mkdir p /compile/clusterrestore/mgs1/log mkdir p /compile/clusterrestore/mgs2/log 步骤 2 配置文件（restoreconfig/mongos40301.yaml）。 net: bindIp: 127.0.0.1 port: 40301 unixDomainSocket: {enabled: false} processManagement: {fork: true, pidFilePath: /compile/clusterrestore/mgs1/mongos.pid} sharding: {configDB: 'config/127.0.0.1:40303,127.0.0.1:40304,127.0.0.1:40305'} systemLog: {destination: file, logAppend: true, logRotate: reopen, path: /compile/clusterrestore/mgs1/log/mongos.log} 步骤 3 配置文件（restoreconfig/mongos40302.yaml）。 net: bindIp: 127.0.0.1 port: 40302 unixDomainSocket: {enabled: false} processManagement: {fork: true, pidFilePath: /compile/clusterrestore/mgs2/mongos.pid} sharding: {configDB: 'config/127.0.0.1:40303,127.0.0.1:40304,127.0.0.1:40305'} systemLog: {destination: file, logAppend: true, logRotate: reopen, path: /compile/clusterrestore/mgs2/log/mongos.log} 步骤 4 启动mongo节点。 ./mongos f restoreconfig/mongos40301.yaml ./mongos f restoreconfig/mongos40302.yaml

本节介绍如何在云审计服务管理控制台查看最近7天的操作记录。 在您开通了云审计服务后，系统开始记录云服务资源的操作。云审计服务管理控制台保存最近7天的操作记录。 操作步骤 步骤 1 登录管理控制台。 步骤 2 单击管理控制台左上角的，选择区域和项目。 步骤 3 单击“服务列表”，选择“管理与部署 > 云审计服务”，进入云审计服务信息页面。 步骤 4 在左侧导航树，单击“事件列表”，进入事件列表信息页面。 步骤 5 事件列表支持通过筛选来查询对应的操作事件。当前事件列表支持四个维度的组合查询，详细信息如下： 事件来源、资源类型和筛选类型。 在下拉框中选择查询条件。 其中，筛选类型选择“按事件名称”时，还需选择某个具体的事件名称。 选择“按资源ID”时，还需选择或者手动输入某个具体的资源ID。 选择“按资源名称”时，还需选择或手动输入某个具体的资源名称。 操作用户：在下拉框中选择某一具体的操作用户，此操作用户指用户级别，而非租户级别。 事件级别：可选项为“所有事件级别”、“normal”、“warning”、“incident”，只可选择其中一项。 起始时间、结束时间：可通过选择时间段查询操作事件。 步骤 6 在需要查看的记录左侧，单击展开该记录的详细信息。 步骤 7 在需要查看的记录右侧，单击“查看事件”，在弹出框中显示该操作事件结构的详细信息。

恢复步骤 命令运行目录：/compile/mongodb/mongodbsrc4.0.3

本文主要介绍计费类问题 在哪里查询不同规格实例的价格？ 不同区域、不同规格的实例价格有所差异，您可以在产品价格详情查询价格 预付费和后付费是什么意思？如何选择？ 预付费：一般为包年包月的购买形式，先购买再使用，系统根据用户选择的规格计算购买金额，对用户帐户金额进行扣除。

本文主要介绍通过云日志服务查看审计日志 通过云日志服务进行分析日志、搜索日志、日志可视化、下载日志和查看实时日志等操作。 查看LTS审计日志 说明 实例已经配置了访问日志，操作详情请参见日志配置管理—新增 步骤 1 在页面左上角单击，选择“管理与监管 > 云日志服务”，进入云服务日志页面。 步骤 2 在“日志组列表”区域，选择目标日志组，单击日志组名称。 查看日志详情 下载LTS日志文件 说明 如果实例已经配置了访问日志，操作详情请参见 步骤 1 在页面左上角单击，选择“管理与监管 > 云日志服务”，进入云服务日志页面。 步骤 2 在“日志组列表”区域，选择目标日志组，单击日志组名称。 下载日志 步骤 3 单击“”。

本节主要介绍恢复shardsvr2副本集 准备目录 rm rf /compile/clusterrestore/shd2 mkdir p /compile/clusterrestore/shd21/data/db mkdir p /compile/clusterrestore/shd21/log mkdir p /compile/clusterrestore/shd22/data/db mkdir p /compile/clusterrestore/shd22/log mkdir p /compile/clusterrestore/shd23/data/db mkdir p /compile/clusterrestore/shd23/log 操作步骤 步骤 1 准备单节点配置文件和目录，以单节点方式启动进程。 配置文件如下（restoreconfig/single40309.yaml）。 net: bindIp: 127.0.0.1 port: 40309 unixDomainSocket: {enabled: false} processManagement: {fork: true, pidFilePath: /compile/clusterrestore/shd21/mongod.pid} storage: dbPath: /compile/clusterrestore/shd21/data/db/ directoryPerDB: true engine: wiredTiger wiredTiger: collectionConfig: {blockCompressor: snappy} engineConfig: {directoryForIndexes: true, journalCompressor: snappy} indexConfig: {prefixCompression: true} systemLog: {destination: file, logAppend: true, logRotate: reopen, path: /compile/clusterrestore/shd21/log/mongod.log} 准备数据，将解压后的shardsvr2文件拷贝到单节点dbPath目录下。 cp aR /compile/download/backups/cac1efc8e65e42ecad8953352321bfeein0292b196d2401041a7af869a2a3cab7079no02/ /compile/clusterrestore/shd21/data/db/ 启动进程。 ./mongod f restoreconfig/single40309.yaml 步骤 2 连接单节点，执行配置命令。 连接命令：./mongo host 127.0.0.1 port 40309 执行如下命令，修改副本集配置信息。 var cfdb.getSiblingDB('local').system.replset.findOne(); cf['members'][0]['host']'127.0.0.1:40309'; cf['members'][1]['host']'127.0.0.1:40310'; cf['members'][2]['host']'127.0.0.1:40311'; cf['members'][0]['hidden']false; cf['members'][1]['hidden']false; cf['members'][2]['hidden']false; cf['members'][0]['priority']1; cf['members'][1]['priority']1; cf['members'][2]['priority']1; db.getSiblingDB('local').system.replset.remove({}); db.getSiblingDB('local').system.replset.insert(cf) 执行如下命令，清理内置账号。 db.getSiblingDB('admin').dropAllUsers(); db.getSiblingDB('admin').dropAllRoles(); 执行如下命令，更新configsvr信息。 var vs db.getSiblingDB('admin').system.version.find(); while (vs.hasNext()) { var curr vs.next(); if (curr.hasOwnProperty('configsvrConnectionString')) { db.getSiblingDB('admin').system.version.update({'id' : curr.id}, {$set: {'configsvrConnectionString': 'config/127.0.0.1:40303,127.0.0.1:40304,127.0.0.1:40305'}}); } } 执行如下命令，关闭单节点进程。 db.getSiblingDB('admin').shutdownServer(); 步骤 3 搭建shardsvr2副本集。 准备副本集配置文件和目录，将shardsvr2节点的dbPath文件拷贝到其他两个节点目录下。 cp aR /compile/clusterrestore/shd21/data/db/ /compile/clusterrestore/shd22/data/db/ cp aR /compile/clusterrestore/shd21/data/db/ /compile/clusterrestore/shd23/data/db/ 修改shardsvr21节点配置文件，增加副本集配置属性（restoreconfig/shardsvr40309.yaml）。 replication.replSetName 的值，参考该章节中的shard的id信息。 net: bindIp: 127.0.0.1 port: 40309 unixDomainSocket: {enabled: false} processManagement: {fork: true, pidFilePath: /compile/clusterrestore/shd21/mongod.pid} replication: {replSetName: shard2} sharding: {archiveMovedChunks: false, clusterRole: shardsvr} storage: dbPath: /compile/clusterrestore/shd21/data/db/ directoryPerDB: true engine: wiredTiger wiredTiger: collectionConfig: {blockCompressor: snappy} engineConfig: {directoryForIndexes: true, journalCompressor: snappy} indexConfig: {prefixCompression: true} systemLog: {destination: file, logAppend: true, logRotate: reopen, path: /compile/clusterrestore/shd21/log/mongod.log} 启动进程。 ./mongod f restoreconfig/shardsvr40309.yaml 修改shardsvr22节点配置文件，增加副本集配置属性（restoreconfig/shardsvr40310.yaml）。 replication.replSetName 的值，参考该章节中的shard的id信息。 net: bindIp: 127.0.0.1 port: 40310 unixDomainSocket: {enabled: false} processManagement: {fork: true, pidFilePath: /compile/clusterrestore/shd22/mongod.pid} replication: {replSetName: shard2} sharding: {archiveMovedChunks: false, clusterRole: shardsvr} storage: dbPath: /compile/clusterrestore/shd22/data/db/ directoryPerDB: true engine: wiredTiger wiredTiger: collectionConfig: {blockCompressor: snappy} engineConfig: {directoryForIndexes: true, journalCompressor: snappy} indexConfig: {prefixCompression: true} systemLog: {destination: file, logAppend: true, logRotate: reopen, path: /compile/clusterrestore/shd22/log/mongod.log} 启动进程。 ./mongod f restoreconfig/shardsvr40310.yaml 修改shardsvr23节点配置文件，增加副本集配置属性（restoreconfig/shardsvr40311.yaml）。 replication.replSetName 的值，参考该章节中的shard的id信息。 net: bindIp: 127.0.0.1 port: 40311 unixDomainSocket: {enabled: false} processManagement: {fork: true, pidFilePath: /compile/clusterrestore/shd23/mongod.pid} replication: {replSetName: shard2} sharding: {archiveMovedChunks: false, clusterRole: shardsvr} storage: dbPath: /compile/clusterrestore/shd23/data/db/ directoryPerDB: true engine: wiredTiger wiredTiger: collectionConfig: {blockCompressor: snappy} engineConfig: {directoryForIndexes: true, journalCompressor: snappy} indexConfig: {prefixCompression: true} systemLog: {destination: file, logAppend: true, logRotate: reopen, path: /compile/clusterrestore/shd23/log/mongod.log} 启动进程。 ./mongod f restoreconfig/shardsvr40311.yaml 步骤 4 等待选主成功。 ./mongo host 127.0.0.1 port 40309 执行命令rs.status()，查看是否已存在主节点Primary。

本文介绍DDS集群架构的组成。 DDS集群由mongos、config、shard组成，节点架构示意图如下： 图 分片集群示意图 mongos mongos负责查询与数据写入的路由，是实例访问的统一入口。 每个实例有2～32个mongos，数量由用户自定义。 用户可直接连接mongos，mongos从config读取配置信息，将读写请求分发到shard。 config config负责存储实例的配置信息，由1个副本集组成。 config可用是部署一个实例或者修改实例元信息的前提。 用户不能直接连接config。 shard 集群实例的shard，负责存储用户的数据。 每个集群实例有2～32个shard，数量由用户自定义。 每个shard由1个副本集组成，副本集为每个shard的数据提供了冗余和高可靠性。 用户不能直接连接shard。

配置Service负载均衡的注意事项 多个Service使用同个负载均衡的同个监听端口。CCMv1.0.7及之后版本，后创建的Service默认会配置失败，可通过设置Service注解“service.beta.kubernetes.io/ctyunloadbalanceroverridelisteners”为“true”指定强制覆盖已有监听。 已创建LoadBalancer类型的Service不支持重新指定负载均衡实例。如果您需要更换负载均衡实例，请重新创建Service。

本文介绍如何为ECI Pod分配IPv6地址。 ECI Pod（即ECI实例）同时支持IPv4和IPv6地址，相比IPv4，IPv6大大扩展了地址的可用空间。本文介绍如何为ECI Pod分配一个IPv6地址。 背景信息 IPv4的应用范围虽广，但网络地址资源有限，制约了互联网的发展。IPv6不仅可以解决网络地址资源有限的问题，还可以解决多种接入设备连入互联网障碍的问题。 前提条件 已为ECI实例所属的VPC和子网开通IPv6网段功能。 指定vCPU和内存创建的ECI实例均支持配置IPv6地址。指定ECS规格创建ECI实例时，请先确保指定的ECS规格支持IPv6。 在满足以上条件后，会自动为创建的ECI实例分配IPv6地址。创建ECI Pod后，您可以通过kubectl get pod命令查看Pod详情。在返回的status中，通过podIPs字段可以获取该Pod的IPv6地址。 使用条件 需放开IPv6的安全组规则。放开IPV6的安全组规则后，ECI实例之间可以通过IPv6地址实现互相访问。

注解名称 描述 示例 支持的CCM版本 ervice.beta.kubernetes.io/ctyunloadbalanceraddresstype 指定新建负载均衡的公网私网类型，取值： intranet：负载均衡地址类型为私网，intranet为默认值 internet：负载均衡地址类型为公网 internet v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalancerbandwidth 计费类型为“bandwidth”时，可指定带宽的大小，值为数字类型，默认为1 Mbps 5 v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalancerchargetype 指定创建公网负载均衡时，公网的计费类型，取值： bandwidth：按带宽计费 traffic：按流量计费，traffic为默认值 traffic v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalancercyclecount 指定负载均衡的计费周期，值为数字类型，表示购买月数，默认为1个月 1 v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalancereipid 指定新建公网负载均衡时，可指定绑定已有的弹性IP，取值为弹性IP的ID，可在网络控制台的弹性IP详情页面查看ID v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalancerenableipv6 指定新建负载均衡时，可指定开启负载均衡的ipv6 "true" v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalancerenablelistenernat64 指定支持ipv6的负载均衡时，可指定开启监听器的nat64，支持负载均衡将ipv6流量转发到ipv4的后端 "true" v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalancerid 指定已有负载均衡，取值为负载均衡实例的ID。删除service时该 ELB不会被删除 v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalanceripv6address 指定新建支持ipv6的负载均衡时，可指定负载均衡的ipv6地址（该地址为负载均衡所在子网的ipv6地址段中未被分配的ip），未指定则由系统随机分配 v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalanceripv6bandwidthid 指定新建支持ipv6的公网负载均衡时，需指定IPv6带宽ID，可在网络控制台的IPv6带宽详情页面查看ID。如果没有IPv6带宽，请先创建一个 v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalanceroverridelisteners 指定已有负载均衡时，可指定是否强制覆盖已有监听 "true" v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalancerprojectid 指定新建负载均衡所属的企业项目，取值为企业项目ID，可在IAM控制台中企业项目详情查看ID 0 v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalancerprotocolport 指定负载均衡监听HTTP协议或HTTPS协议，可指定多个监听，多个监听之间以逗号“,”分割 https:443,http:80 v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalancerspec 指定新建负载均衡的规格，如elb.s2.small elb.s2.small v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalancersslcert 指定SSL证书，取值为SSL证书ID，可在负载均衡控制台的证书管理页面查看证书ID。 仅监听协议为HTTPS协议时需要指定 v1.1.1及以上 service.beta.kubernetes.io/ctyunloadbalancerxforwardedfor 指定负载均衡监听器附加XForwardedFor头字段，通过开启该参数，后端服务可获取客户端源IP。取值为“true”或“false” 仅支持监听协议为HTTP和HTTPS协议 "true" v1.1.1及以上

本文介绍如何创建Nginx Ingress。 Ingress是Kubernetes集群中一种API对象，属于网络路由和负载均衡中的一个概念。它的主要作用是将外部的流量路由到集群内部的服务，您可以通过Ingress资源来配置不同的转发规则，从而根据不同的规则设置访问集群内不同的Service所对应的后端Pod。本文将介绍如何通过控制台和Kubectl方式创建、查看、更新和删除Ingress。 前提条件 确保您已经创建Serverless集群，具体操作请参阅创建Serverless集群。 方式一：控制台操作指导 创建Ingress 1. 登录云容器引擎控制台。 2. 在控制台的左侧导航栏中点击“集群” 。 3. 在集群列表页面中，单击目标集群的名称进入集群详情界面。 4. 在集群管理页面的左侧导航栏中，选择“网络” ，然后单击“路由” 。 5. 单击路由页面左上角的“创建路由” ，跳转到创建Ingress页面。创建路由时，整体上可以分为生产Ingress和灰度Ingress 。 6. 创建灰度Ingress ： 1. 在流量切换方式中选择灰度 。 2. 选择命名空间，创建灰度Ingress时必须关联⼀个生产Ingress，用于实现生产Ingress和灰度Ingress之间的流量切换。 3. 选择流量切换方式，可以选灰度或者蓝绿 。 4. 选择灰度后，支持两种转发方式：Header和Cookie。 1. Header ：根据http请求的头部中是否包含指定keyvalue来选择将请求转发到生产Ingress还是灰度 Ingress。 2. Cookie ：根据http请求的Cookie中是否包含指定keyvalue来选择将请求转发到生产Ingress还是灰度Ingress，Cookie转发时无法更改value和匹配方式。 5. 选择蓝绿后，蓝绿转发可以选择转发到生产Ingress和灰度Ingress的流量权重： 1. 全部切到生产：将请求全部转发到生产Ingress。 2. 全部切到灰度：将请求全部转发到灰度Ingress 。 3. 自定义百分比：如30%表示将30%的请求转发到灰度Ingress，70%的请求转发到生产Ingress。 7. 创建生产Ingress ： 1. 在灰度Ingress选项中选择否 。 2. 填写域名路径规则，包括协议、域名、路径、服务名称以及服务端口等信息，支持添加多个规格。

本文介绍如何采集指定虚拟节点的Metrics。 本文介绍如何通过修改Prometheus监控配置来采集虚拟节点的Metrics。 背景信息 在天翼云Serverless集群虚拟节点的架构设计下，同一Serverless集群内的多个虚拟节点会共享同一个Node IP。由于Prometheus常通过Kubelet Service采集所有节点的Metrics，采集单个虚拟节点的数据会返回所有虚拟节点的全量数据，因此会出现Metrics重复的现象。为了解决这个问题，Serverless集群提供了采集指定虚拟节点的Metrics数据的能力，不但保留了原有的采集端点 :10250/metrics/cadvisor，并且会过滤指定nodeName的数据，避免重复采集数据。 前提条件 确保您已经创建Serverless集群，具体操作请参阅创建Serverless集群。 修改Prometheus监控配置 您可以通过修改监控配置来采集指定虚拟节点的Metrics。Serverless集群支持ccsemonitor插件以及开源Prometheus场景下的配置方式。 Serverless集群安装ccsemonitor插件后配置默认支持采集虚拟节点的Metrics，无需额外操作。开源Promethues配置参考如下： shell scrapeconfigs: ... jobname: cadvisor honortimestamps: true scrapeinterval: 40s scrapetimeout: 10s metricspath: /metrics scheme: https kubernetessdconfigs: role: node bearertokenfile: /var/run/secrets/kubernetes.io/serviceaccount/token tlsconfig: cafile: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecureskipverify: false relabelconfigs: sourcelabels: [ metakubernetesnodelabelkubernetesposeidonctyuncncollectorscrape ] regex: true action: keep

5. Ingress 控制器和服务不同步，如何解决？ 如果你发现 Ingress 控制器和服务不同步，可能是由多种原因导致的。以下是一些可能的问题及其相应的解决方案。 Ingress 控制器没有正确配置或安装 ：确保你正确安装并配置了 Ingress 控制器。检查 Ingress 控制器的 Pods 的状态和日志，以确认它们是否正在正常运行。如果存在任何错误，根据错误信息进行故障排查。 Ingress 规则没有正确配置 ：检查你的 Ingress 资源的配置，确保你已正确定义了路由规则，并且这些规则指向了正确的服务和端口。 服务或 Pods 不可用 ：Ingress 控制器将流量路由到服务，然后由服务路由到 Pods。如果服务或 Pods 不可用，可能会导致 Ingress 控制器和服务不同步。检查服务和 Pods 的状态，确保它们正在正常运行。 Kubernetes API 服务器不可用 ：Ingress 控制器通过 Kubernetes API 服务器获取服务的信息。如果 API 服务器不可用，可能会导致 Ingress 控制器和服务不同步。检查 API 服务器的状态和日志，以确认它是否正在正常运行。 网络问题 ：如果网络配置不正确，可能会导致 Ingress 控制器无法与服务或 Pods 通信。这可能是由于网络策略、防火墙规则或其他网络配置问题导致的。进行网络故障排查，以确认网络配置是否正确。解决这些问题可能需要查看和理解 Ingress 控制器、服务和 Pods 的日志，以及可能需要进行网络和 Kubernetes API 服务器的故障排查。

本节介绍网络的用户指南:NGINX Ingress Controller。 NGINX Ingress Controller是一种常见的Ingress Controller实现，它利用NGINX的高级性能和灵活性来处理服务的路由和负载均衡。当一个Ingress资源在Kubernetes集群中被创建或更新时，Ingress Controller会检测到这些变化。然后，它会根据Ingress资源定义的规则，自动生成对应的NGINX配置，以实现请求的路由和负载均衡。 NGINX配置包括如何处理进入的网络请求（例如，基于主机名或URL路径进行路由），以及如何将请求路由到后端的服务实例。NGINX Ingress Controller会定期检查Ingress资源的变化，如果检测到任何更改，它会自动更新NGINX配置以反映这些更改。此外，NGINX Ingress Controller还支持一些高级特性，如SSL终止、WebSocket、HTTP/2和更复杂的负载均衡算法。这些特性都可以通过Kubernetes Ingress资源的注解来配置。 Nginx Ingress Controller通过Pod部署在工作节点，因此引入了相应的组件运行和运维成本，其工作原理如图所示： 注意 1、用户提交Ingress资源后，Nginx Ingress Controller会获取该资源并解析为转发规则，写入Nginx的配置文件（nginx.conf）； 2、触发Nginx进行reload，以加载更新后的配置文件，完成Nginx转发规则的修改和更新； 3、集群外客户端可通过控制节点IP或VIP（若存在）访问Nginx，Nginx组件根据转发规则将其转发至对应的服务Service，最终转发到对应的后端Pod。

本节介绍Ingress概述。 Ingress简介 Ingress是Kubernetes标准的七层流量入口资源，用于统一管理集群外部到集群内部Service的HTTP/HTTPS访问流量，是容器云平台面向业务应用最核心的南北向流量网关组件。 在不使用Ingress的场景下，业务通常依赖NodePort、LoadBalancer等四层暴露方式，每一个对外服务都需要独立端口、独立负载均衡实例，资源成本高、路由管控弱、证书管理零散。Ingress 提供统一接入点：多个业务域名、路径复用同一组入口网关，基于域名、URI 路径做精细化流量分发，解决多应用对外暴露的成本、治理、证书、路由统一管控问题，是容器应用上云、微服务对外发布的标准方案。 核心概念 1. Ingress（资源对象） ：Kubernetes API资源，以YAML声明路由规则，定义host（域名）、path（路径）、后端Service、TLS证书引用等，是用户面向业务配置的对象。 2. Ingress Controller（控制器） ：Ingress规范的实现，包含控制面 + 数据面。控制面监听 Ingress 资源变更；数据面（Nginx等）承接流量、执行转发。天翼云云容器引擎支持的Ingress Controller有ELB、APIG、Nginx 网关三种类型。 3. Backend（后端） ：路由最终指向集群内Service，再由Service转发至后端Pod；控制器会自动感知Endpoint变化，实现后端实例健康感知与自动管理。 4. TLS Secret ：存放HTTPS证书与私钥，Ingress 关联Secret实现证书引用和卸载，由网关统一完成 SSL/TLS 解密。 注意 Ingress资源本身只是声明式路由规则，不直接处理流量；真正执行代理、转发逻辑的是 Ingress Controller，控制器持续监听API Server，感知Ingress、Service、Endpoint、Secret等资源变更，自动刷新代理配置，实现规则动态生效。

共享盘类型选择 安全需求优先 NAS 共享盘：如果您极其重视数据安全，且希望数据仅在天翼AI云电脑环境内流转，不暴露在公网环境中，NAS 共享盘是匹配高密级数据场景的选择。它只能通过AI云电脑挂载访问，这种特性极大地降低了数据在公网环境下可能面临的安全风险，为数据提供了更可靠的安全保障。例如，对于一些对数据保密性要求极高的企业，如金融、科研等行业，其核心数据的存储和共享使用 NAS 共享盘能有效防止数据泄露。 网络共享盘：虽然网络共享盘也具备一定的安全措施，但由于支持公网访问，相比之下，数据面临的安全风险会略高一些。不过，它的权限管控和访问审计功能非常强大，能通过细致的权限设置和全面的操作记录，对企业内部的数据访问进行严格管理和监控，从而在一定程度上保障数据安全。适用于对合规性管理要求较高的大型企业，即便数据在公网环境下有访问需求，也能通过严格的权限和审计机制降低风险。 功能需求侧重 NAS 共享盘：主要功能在于满足基本的文件共享存储需求。在企业内部，员工可以便捷地共享办公文档、项目资料等，提供一个集中的文件管理平台。如果您的企业或团队主要需求是简单高效地进行文件共享，对其他复杂功能需求较少，NAS 共享盘完全可以满足日常工作中的文件协作需求。 网络共享盘：除了文件共享功能外，更强调权限管控、访问审计以及与其他企业系统的集成功能。对于大型企业而言，不同部门和职位对数据的访问和操作权限有严格要求，网络共享盘能够设置细致的权限，满足这种精细化管理需求。同时，与 ERP、CRM 等系统的集成功能，能实现企业数据的无缝流通，提高整体信息化管理水平，促进业务流程的自动化和数据的统一管理，适合业务流程复杂、信息化程度高的大型企业。