• [运维管理] HCS DWS OS故障替换主机
    有一个困扰,纯软形态下,DWS主机OS故障且不可修复后,可通过手动安装OS、配置好IP后再进行gs_replace修复。但HCS中的BMS形态部署的DWS集群,如果某台主机OS故障且无法修复的情况下,如何进行主机替换呢?有以下几点考虑,但不知道如何解决:1. 新的主机进行bms入云初始化后,如何成为故障主机对应的裸金属实例,即部署dws服务前的纯净节点?2. 因为bms形态下的dws集群是自动下发的OS及dws服务实例,里面的ip配置是从cidr地址池中获取的,此时是直接修改为故障主机的ip么?包括内大网地址、interMgntSubnet、internalSubnet、managerSubnet、业务vpc地址及主机名-裸机实例名,改这些如何实现,会有其他影响么?3. 前述完成后再如纯软形态下执行gs_replace修复,该主机上的管控面插件又如何恢复部署?
  • 如何选择分布键
    选择分布键是设计分布式表的重要决策之一。如果表没有主键,可以考虑使用序列或轮询作为分布键。序列分布键    序列分布键是根据某个列的值进行哈希分布,这样相同值的行将被分配到同一个分区中。    这种方式适用于具有高度重复值的列,例如日期或状态列。    使用序列分布键可以提高查询性能,因为相关数据在同一个分区中,减少了数据的移动和网络传输。轮询分布键    轮询分布键是按照顺序将行分配到不同的分区中。    这种方式适用于没有明显的重复值的列,例如自增主键。    使用轮询分布键可以实现数据的均匀分布,避免了数据倾斜的问题。哪种方式更优取决于具体的业务需求和数据特点。    如果表中的数据具有明显的重复值,使用序列分布键可能更合适。    如果数据没有明显的重复值,使用轮询分布键可以实现更均匀的数据分布。需要注意的是,选择分布键时还需要考虑数据的增长和变化情况,以及查询的频率和类型。最好进行测试和评估,根据实际情况选择最优的分布键策略。
  • DWS分区过多的危害
    危害1:DWS分区过多会导致锁等待问题的出现    主要原因是分区过多会增加锁的竞争,从而导致锁等待的情况。当一个事务需要访问多个分区时,需要获取多个分区的锁,如果这些分区的锁被其他事务占用,就会出现锁等待的情况,从而导致事务的阻塞和性能下降。危害2:分区过多还会导致存储空间的浪费和查询性能的下降    分区过多会增加元数据的存储空间,从而导致存储空间的浪费。同时,查询时需要扫描更多的分区,从而导致查询性能的下降。因此,在设计DWS分区时,需要根据实际情况合理划分分区,避免分区过多导致的问题。一般来说,可以根据数据的访问模式、数据量、查询需求等因素来确定分区策略,以达到最优的性能和存储效率。
  • SQL高并发压测性能优化
    1. 数据库设计优化:    在设计数据库时,应考虑表的结构、索引、数据类型和分区等因素,以确保数据库能够快速响应大量并发请求。2. SQL语句优化:    应使用合适的索引、避免使用不必要的JOIN语句和子查询、避免使用过多的函数和表达式等。3. 数据库分区:    将大表分成多个小表,以减少查询时的数据量,提高查询速度。4. 数据库服务器优化:    应调整服务器参数,如内存、CPU、磁盘和网络等,以提高服务器的吞吐量和响应时间。5. 数据库缓存优化:    应使用适当的缓存策略,如缓存数据、查询结果和查询计划等,以减少数据库访问时间。6. 数据库连接池优化:    应设置合理的连接池大小和超时时间,以确保数据库连接的可用性和响应时间。7. 负载均衡优化:    应使用适当的负载均衡策略,如轮询、权重和故障转移等,以确保请求的平衡分发和高可用性。8. 监控和调试优化:    应使用适当的监控工具,如性能监视器和日志分析器等,以及适当的调试技术,如断点和日志记录等,以快速诊断和解决性能问题。
  • 网络IO和磁盘IO
    网络IO和磁盘IO是计算机系统中常见的两种IO(输入/输出)操作。定义:    网络IO是指计算机通过网络接口进行数据的输入和输出操作,例如从网络下载文件或上传文件到网络。    磁盘IO是指计算机通过磁盘接口进行数据的输入和输出操作,例如从磁盘读取文件或将文件写入磁盘。联系:    网络IO和磁盘IO都涉及到数据的输入和输出。    网络IO和磁盘IO也都会影响计算机系统的性能。区别:    网络IO和磁盘IO的主要区别在于数据的输入和输出方式不同。    网络IO是通过网络接口进行数据的输入和输出,而磁盘IO是通过磁盘接口进行数据的输入和输出。    网络IO涉及网络传输速度和网络延迟等问题,而磁盘IO则涉及磁盘读写速度和磁盘容量等问题。网络IO通常需要考虑网络安全等问题,而磁盘IO则通常需要考虑数据的持久性和可靠性等问题。
  • 查看存储过程的执行计划
    在DWS中,可以通过以下两种方式来查看存储过程的执行计划:1. 使用pgAdmin工具    在pgAdmin中,可以通过以下步骤来查看存储过程的执行计划:    连接到DWS数据库    在左侧的对象浏览器中,展开“Schema”和“Public”,找到要查看的存储过程    右键单击该存储过程,选择“Scripts”->“Explain”或“Explain Analyze”    在弹出的窗口中,可以查看存储过程的执行计划和统计信息2. 使用EXPLAIN命令    在DWS中,可以通过在存储过程前加上EXPLAIN关键字来查看其执行计划。        例如:EXPLAIN SELECT * FROM my_proc();         这将返回存储过程的执行计划和统计信息。    另外,如果需要更详细的执行计划信息,可以在EXPLAIN关键字后加上ANALYZE关键字,        例如:EXPLAIN ANALYZE SELECT * FROM my_proc();        这将返回更详细的执行计划和统计信息,包括每个步骤的实际执行时间和行数等。
  • 降低ETL对资源的消耗
      ETL是Extract(提取)、Transform(转换)、Load(加载)的缩写,是一种数据处理方式,用于将数据从一个或多个来源提取出来,经过转换处理后,加载到目标数据仓库或数据库中。  数据集成通常是指将来自不同数据源的数据整合到一个统一的数据集中,以便进行分析和决策。ETL是数据集成的一种常见方式,ETL工具可以帮助数据工程师更快速、高效地完成数据集成任务。  DWS中常用的ETL工具包括:Informatica PowerCenter,IBM InfoSphere DataStage。  以下是一些降低ETL对资源消耗的方法:    1. 优化数据源:      ETL工作的第一步是从数据源中提取数据。如果数据源中的数据结构和格式不合适,那么ETL过程将变得更加复杂和耗费资源。      因此,优化数据源是降低ETL对资源消耗的重要步骤。      优化数据抽取:在抽取数据时,只选择需要的列和行,避免不必要的数据抽取,减少资源消耗。      优化数据转换:在进行数据转换时,使用高效的算法和数据结构,避免使用过于复杂的转换逻辑,减少资源消耗。      优化数据加载:在进行数据加载时,使用批量加载方式,减少单次加载的数据量,避免频繁的数据库操作,减少资源消耗。    2. 减少数据量:      在ETL过程中,处理大量数据会消耗大量的资源。      因此,减少数据量可以大大降低ETL对资源的消耗。可以通过过滤无用数据、压缩数据等方式来实现。    3. 优化ETL流程:      通过优化ETL流程,可以减少ETL过程中的重复计算和不必要的数据转换,从而降低资源消耗。      例如,可以使用增量抽取、分批处理等方式来优化ETL流程。    4. 使用合适的硬件和软件:      选择合适的硬件和软件可以提高ETL的效率,从而降低资源消耗。      例如,可以使用高性能的服务器和数据库,使用ETL工具的缓存和优化功能等。    5. 定期清理数据:      定期清理不必要的数据可以减少数据存储空间和ETL过程中的数据处理量,从而降低资源消耗。      可以使用数据清理工具或手动清理数据。    6. 监控ETL过程:      通过监控ETL过程,可以及时发现并解决资源消耗过高的问题。      可以使用ETL监控工具或手动监控ETL过程。
  • DWS监控看板怎么看
    DWS(Data Warehouse Service)的监控看板可以通过以下步骤进行查看和使用:         1. 登录DWS控制台:                 打开浏览器,访问DWS的控制台网址,并使用您的账号和密码登录。         2. 进入监控看板:                 在DWS控制台的左侧导航栏中,点击“监控看板”选项,进入监控看板页面。         3. 选择监控指标:                 在监控看板页面,您可以选择不同的监控指标进行查看。                 常见的监控指标包括CPU利用率、内存利用率、磁盘空间利用率等。         4. 设置时间范围:                 在监控看板页面的顶部,您可以设置要查看的时间范围。                 可以选择最近1小时、最近24小时、最近7天等不同的时间范围。         5. 查看监控图表:                 在监控看板页面,您可以看到各个监控指标的图表展示。                 您可以通过鼠标悬停在图表上,查看具体的数值信息。         6. 添加自定义监控:                 如果您需要添加自定义的监控指标,                 可以点击监控看板页面右上角的“添加自定义监控”按钮,按照提示进行设置。         7. 导出监控数据:                 如果您需要导出监控数据进行分析或保存,                 可以点击监控看板页面右上角的“导出”按钮,选择导出的格式和时间范围。         8. 设置报警规则:                 如果您希望在监控指标达到一定阈值时收到报警通知,                 可以点击监控看板页面右上角的“设置报警规则”按钮,按照提示进行设置。 通过以上步骤,您可以方便地查看和使用DWS的监控看板,及时了解和监控您的数据仓库服务的运行状态。
  • GaussDB(DWS) 的并发管控和内存管控笔记
    内存管控是基于语句的估算内存的前提下进行管控的,通俗的说就是语句有个估算内存,当资源池的剩余内存小于语句的估算内存时,这个语句就会排队等待,等资源池内的语句执行完,资源池有足够的剩余内存的时候,才会让这个语句执行。所以内存管控的实际效果和语句的估算内存有很大关系,估算的大了就会造成大量语句排队,实际没有使用那么多内存,造成内存资源浪费,相反估算的小了,就会有很多语句下发,实际内存使用就会变多,就有语句报内存不足的错误风险。数据库系统的并发控制,在整个系统中起着很重要的作用,比如很多用户的业务压力过大时,有时会导致连接数量被占满,有时会导致某种计算资源被占满,有时会导致存储空间被占满,这些情况都会导致整个集群进入异常甚至不可用的状态:正在执行的作业互相争抢CPU,会导致大家都不能好好执行;大量作业执行时,占用大量内存,很容易触发到内存瓶颈,造成作业内存不可用问题,导致业务报错等等。在不进行并发控制的情况下,这些情况都很可能会出现,影响到正常业务。DWS的负载管理分为两层,第一层为cn的全局并发控制,第二层为资源池级别的并发控制。在通过第一层控制的时候,会继续向前走到第二层资源池控制,根据资源池当前的负载资源情况决定作业继续执行或者排队。基于DWS并发控制逻辑看出,实际作业执行中,可能会在两种队列中排队:一种是全局队列(global queue)这种队列不区分简单和复杂作业,也不区分是DDL或者是普通语句,这种是每个cn生效。一种是资源池队列(resource pool queue),用户下发的一般语句会根据资源消耗估算以及复杂程度在这里进行判断是否排队。在两层队列的过滤下,DWS会筛选出当前能执行的语句,使其正常运行,运行时也会受到其所属资源池资源的限制(只能使用资源池配置的CPU、内存、IO配额)。
  • [问题求助] GaussDB(DWS)如何与其他数据仓库和工具进行集成?
    GaussDB(DWS)是否支持与其他数据仓库和工具的集成,并有哪些常用的集成方式或者协议可供选择
  • [问题求助] GaussDB(DWS)是如何保障数据安全和隐私的?
    GaussDB(DWS)提供哪些高级分析函数和算法,以便能够利用这些功能进行复杂的实时数据分析和预测。
  • [问题求助] GaussDB(DWS)如何支持实时数据流处理和批量数据处理?
    GaussDB(DWS)如何支持实时数据流和批量数据这两种数据的处理模型。
  • [问题求助] 在使用GaussDB(DWS)时,如何处理高并发访问的情况的?
    想了解如何利用GaussDB(DWS)来处理高并发访问。
  • DWS-ccn排队处理
    已下是整理总结的,非原创问题现象业务整体缓慢,只有少量语句在执行,其余业务语句都在排队中(wait in ccn queue)。原因分析动态负载管理下,语句会根据估算内存计数排序,例如,最大动态可用内存为10G(单实例),语句估算使用内存大小为5G,这样的语句运行2个,其余语句就会等待前两个语句运行完毕才能执行,此时的状态即为 wait in ccn queue。什么是CCN进入沙箱使用此命令判断那个节点是ccn,到此节点上ccn是什么:ccn作为集群并发控制大脑,所有复杂作业都会到ccn去申请资源,申请到资源的语句才能下发。复杂语句都会在ccn统一记录。处理方法一、官方文档提供方法(pg_session_wlmstat)·场景一:语句估算内存过大,造成排队o查询pg_session_wlmstat视图,查看status为running的语句是否个数很少,而且statement_mem字段数值是否较大(单位为MB,一般认为大于max_dynamic_memory 1/3即为大内存语句)。如果都符合就可以判断是此类语句占据内存导致整体运行缓慢。oselect usename,substr(query,0,20),threadid,status,statement_mem from pg_session_wlmstat whereusename not in (''omm'',''Ruby'') order by statement_mem,status desc;如上图所示,只有最后一个语句是running状态,其余语句都是pending状态。根据statement_mem可以看到该语句占据2576MB内存。此时根据语句的threadid,使用以下语句进行查杀,查杀后即可释放资源,其余语句正常运行。pg_terminate_backend(threadid);·场景二:所有语句状态都是pending状态,没有运行的语句。此时应是管控机制出现异常,直接查杀所有线程,即可恢复正常。pg_terminate_backend(threadid);二、方法(pg_stat_get_wordload_struct_info)视图介绍pg_stat_get_workload_struct_info()l  totalsize代表ccn总体能分配的内存,totalsize:即最大动态内存;freesize_limit即最大可用于ccn分配的内存,为最大动态内存的80%。freesize代表当前剩余内存。l  只需要关注图中的central waiting/running number(global的可以不用关注,属于另一个数据结构,和central waiting是重复信息。)。每一行代表一个语句。running代表语句正在运行,waiting代表语句正在排队。queryId代表语句的线程号,对应pg/pgxc_thread_wait_status中的lwtid、pg_sessiion_wlmstat中的processid。select * from pg_stat_get_workload_struct_info();如上图:总共可用内存为2576MB,目前正在运行的一个语句占用内存为1288MB,剩余内存freesize=0MB此时,其余语句内存估算大小也都是1288MB,因此内存不足全都无法下发执行,只有等到正在运行的语句结束,内存计数释放才能继续下发。(PS:实际场景中,大多是running的语句内存远大于排队的语句,并且长时间没有执行完毕,占据计数不释放,造成大量的不合理排队。)第二步根据语句对应的qid.queryId,找到语句的pid。如上图为3595/3592select coorname,pid,usename,substr(query,0,30) from pgxc_stat_activity a,pgxc_thread_wait_status b where a.pid = b.tid and b.lwtid = $qid.query_id;第三步根据pid和cn,查杀大内存语句。释放内存后即可恢复。存在一种场景场景二:如果存在少量running,多数pending,且正处于running中的语句qid.queryId都是同样的,可以考虑是资源池并发度太少select * from pg_resource_pool;该语句可查看资源池详细信息如果只是达到了资源池并发上限,例如,资源池并发设置为10,残留的running语句数量是10,因为并发达到上限,语句都处于等待状态,那么调整队列并发为-1,不限制之后,等待并发的语句即可下发下去。修改办法,以son_pool为例:alter resource pool son_pool with(active_statements=-1);在workload视图中qid.queryId重复的语句便是问题语句,问题线程,重复两条,可能其中一条是正常的,另一条是残留的。也可能都是有问题的,但是终究实际上只有一个活跃的语句在排队或者执行。根据pid和cn,使用pg_terminate_backend(pid)查杀残留语句。释放并发以及内存资源之后恢复。三、脚本gs_ccnqueue.sh当集群部署了gs_tools运维套件,可以直接跑一下该脚本从图中我们可以看到正在有一个作业在排队,(current wait global num is:1)当前总共内存有13688MB(all Memory is:[13688]MB),剩余内存13142MB,(current free memory is:[13142]MB)之后就输出了正在执行的一些sql,比如下边这个sql的信息当前sql是在cn_5001上下发的,线程id是18553,估算内存为273MB,sql的信息有pid(线程id),usename(用户名称),dur(执行时间),state(执行状态),enqueue(排队状态),substr(执行的sql)具体的详细信息都是通过pg_stat_get_workload_struct_info视图找到的,详细信息都存储到了当前目录下的ccnServerinfo...这个文件中,正在执行的sql存储在了running_sql_..log文件中。
  • DWS云上数据库登陆一览
    DWS云上数据仓库登陆指南适用于首次登陆二、环境配置1.打开文件地址在堡垒机中打开文件C:\Windows\System32\drivers\etc\hosts在文件尾部进行IP地址映射,其中24-28为添加的一部分IP地址,如下图:该部分不添加直接通过 IP地址也可以访问到,添加域名映射的目的是为了区分各个IP地址,建议不要跳过其中,需添加的信息见下Excel表格2.各页面介绍ManageOne运营面:负责云服务的登陆入口,可登陆dws管控面web端,主要功能上有集群下发、扩容、删除,快照,dms监控,参数修改等ManageOne运维面:主要是运维监控告警。页面右下角链接多个链接,可通过sso单点登陆跳转至service om、fusioncare等Fusioncare:巡检ServiceOm:查看虚拟机、裸金属、规格、网络等IP地址;dws服务内核升级、节点修复等三、寻找EICommon的IP地址1.登录ManageOne运维面。 打开谷歌浏览器,使用IPv6登陆cloud-oc.xxstack.hcslab.com:31943账号密码是admin/xxxx2. 进入ServiceOM在首页选择该Region的ServiceOM。3. 搜索地址在ServiceOM首页选择计算资源->虚拟机->搜索EICommon。找到EICommon-Region-Master-01机器的地址。四、寻找容器参数使用op_cdk_sso用户(密码xxxx,注该密码有效期只有180天,若失效请使用admin账户登录重置)登录cloudscope页面,进入运维服务->变更管理->CDK单击 变更管理->服务升级。集群选择ei-dbs-region,命名空间为dws,选择dwscontroller,下一步。搜索框中搜索db,将途中三个参数记下。五、登录EICommon在桌面找到MobaXterm_Portable应用程序,打开后选择session->SSH->输入IP地址->ok使用ssh登录opsadmin用户到该机器,密码是opdadmin默认密码。进入并切换到root。Root密码为统一密码表查到的。就是root的默认密码。六、进入容器1.找到主机名使用kubectl get pods --all-namespaces找到容器主机名,如图2.进入容器使用kubectl exec -ti 主机名 -n ecf bash登录容器七、进入沙箱1. 进入目录输入命令cd /opt/cloud/3rdComponent/opsTool/进入dws-maintain容器后,执行以下命令,解密dws密码:java –jar AESTool.jar若出现该错误Error: Could not find or load main class解决办法:将当前目录加入系统变量CLASSPATH,系统才能找到当前目录下的Java类 , vi /etc/profile ,按照将jar包的目录加到PATH中,保存退出后source /etc/profile让文件生效。2 { dbPasswordEncrypt}其中user字段在630及之前版本为root,在930及之后版本为ecf,若需要输入密码,则粘贴步骤七中密码即可,{db IP}是4中查询的IP,{instance name}是dws001dws001集群名的获取方法是登录ManageOne运营面->进入EI高阶服务->数据仓库服务,进行查看sh connectTool.sh –u{user} -drms –h{db ip} -p7306 -n {instance name} -tStandalone八、登录数据仓库1.切换用户与主机名su - Ruby2.登录ssh `hostname -i`
总条数:2746 到第
上滑加载中