【鲲鹏数据库】【操作步骤&问题现象】1、ps -ef | grep mysql缺失下面两个进程2、/usr/local/mysql/bin/mysql -uroot -p -S /tmp/mysql.sock【截图信息】【日志信息】（可选，上传日志内容或者附件）

问题描述gaussdb进程持续占CPU过高，需找到占用CPU过高的sql语句问题处理找一个gaussdb进程，确认进程号和对应dn的端口号（进程号32089）执行ps H -eo pid,tid,pcpu | sort -n -k 3 | grep 32089，可以查到进程内各个线程占用CPU的情况最后几条结果如下：32089    48369    81.932089    41335    82.332089    10596    85.6连续执行多次，发现占用CPU高的线程没有变过连接到此dn（注意端口号搞对）select query_id from pg_thread_wait_status where lwtid = 10596;查到query_id 为95174458select * from pg_stat_activity where query_id = 95174458;即可查到对应语句和客户业务侧确认，该语句是临时新增业务，不是跑批业务，杀掉该语句进行规避，业务侧进行语句优化或者业务流程调整

起集群发生备DN启动失败，DN日志内容包含 Address already in use字段，且提示出明确的端口号。定位步骤：1. 查找日志中提示的冲突端口号，例：备DN端口号25152（同时确认IP是否合法且未被占用）。2. 执行命令：netstat -anop|grep 25152 查找占用该端口号的进程PID。3. 执行ps ux | grep 10213，利用PID找到该进程。4. 分析占用进程内容。例：进程为主DN，且查找主DN的postgresql.conf文件，发现主DN和备DN都使用了25152端口。解决方案：确认该进程无需继续使用，则kill掉占用端口号的进程。否则修改备DN的postgresql.conf文件，更换冲突的端口号为未被占用的端口号。

升级manager步骤44%报错，如下：查看oms节点的/var/log/Bigdata/patch/oms_installPatch.log日志，有如下报错：查看对应的/opt/huawei/Bigdata/patch/install/Manager_6.5.1.1/oms/om下的installPatch.sh脚本，查找update resource_properties table failed报错，找到对应的语句如下：继续查找UPDATE_DB_CMD变量，如下：连接oms数据库gsql -p 20015 -W ChangeMe@123456 -U omm，手动执行该sql，可以执行成功：确定是环境变量的问题。查看update-service以及ha.bin进程的环境变量cat /proc/pid/environ|grep mpp，发现ha.bin进程里还是有高斯的环境变量，但是之前已经重启过该进程并且确认了无高斯的环境变量。查看/home/omm下的.bashrc .bash_profile .profile文件，发现.bash_profile文件里有写入高斯的环境变量，如下：将高斯的环境变量删除后，界面重试正常

目录【问题描述】【分析过程】【问题根因】【闭环方案】【恢复方案】【问题描述】1、集群FI界面显示以下告警：文件句柄使用率超过阈值、TCP临时端口使用率超过阈值等； 2、业务无法正常执行，连接DataNode5以外节点cn_5001执行作业报dn_6001_6002达到最大连接数；3、连接DataNode5上cn_5005执行作业报临时资源不可用。【分析过程】1、TCP临时端口使用率超过阈值GaussDB A支持随机端口复用，临时端口使用超过65535不会影响业务，因此此告警不会导致问题。 2、文件句柄使用率超过阈值1）查看DataNode5机器的os系统日志，搜kernel关键字，如下：localhost:~ # grep kernel /var/log/messages Jul 12 16:05:01 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:14 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:14 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 13 09:51:46 DataNode5 kernel: VFS: file-max limit 640000 reached omm@localhost:~ #2）查操作系统配置的最大文件句柄数localhost:~ # sysctl -p|grep file-max fs.file-max = 6400003）统计进程使用句柄数情况localhost:~ # lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more由于文件句柄较多，统计较慢4）统计gaussdb各进程使用的文件句柄# 查找gaussdb进程 ps ux # 查看某个进程使用的文件句柄数 ls /proc/pid/fd | wc -l# 结果排查，发现cn（此cn为cn_5005）进程所占的文件句柄数最多，如下图，达到57万，略有异常，继续分析。5） 排查cn_5005日志，重点关注7月12号下午16:05的日志信息，如下，“remaining connection slots are reserved for non-replication system admin connections”和“dn_6037_6038: sorry, too many clients already, active/non-active: 5/2995.”均表明当前系统连接数已经达到设置的最大max_connections，不能在建连。继续确认进程启动时间并与客户确认，上一次重启时间为19年12月，8.0之前的版本，客户持续运行7个月以上，连接数可能会一直增大，这时需要用户手动执行clean connection to all for database dbtest;去清理空闲连接，否则继续建连会出现上述报错提示，且也会由于连接数太多占用内存导致执行时报临时资源不可用。疑问：客户集群共部署4个CN节点，且采用LVS负载均衡，正常情况下，LVS会将作业均衡的分发给每个CN节点，但目前只有datanode5节点报文件句柄数达到最大？？6）继续排查其它机器所占用的文件句柄数，如下图只有12万+，怀疑可能是LVS异常。7）与客户对齐发现，客户在使用LVS过程中，跑大量insert语句，刚开始运行时，观察每个cn上都会运行insert语句，运行到10小时之后（20小时才能跑完），LVS只往某两个cn上下发作业，这会导致上述cn_5005连接数远远大于其他节点。【问题根因】连接数太多导致系统业务报错【闭环方案】客户反馈近期会升级到8.0版本，8.0版本已加入自动清理空闲连接操作，不会再出现此类报错。【恢复方案】法一：清理空闲连接：clean connection to all for database dbtest;法二：集群重启后恢复

1、前台一直卡在99%，后台重分布进程存在，查看活跃sql，一线反馈没有insert into或者rebuild index之类的语句，只有lock table xxx的语句，查看$GAUSSLOG/bin/gs_redis/下的重分布日志，日志在lock table redis_status in acess share mode后就有3张表有报不存在的报错。手动连接cn查询这3张表，会在dn上报表不存在的报错，使用\dn 表名可以查到表定义，确认是这3张表的元数据不一致导致。通过update pgxc_redistb set redis_order = 0 where relname = 'tb_name' and redistributed = 'n';命令跳过这3张表，在后台kill 掉重分布的进程，然后在前台FI界面重新调起重分布。2、将那3张表跳过后重新调起重分布，查看进度还是在99%，通过update pgxc_redistb set redistributed='y'  where relname in ('xx','xx','xx');将该3张表状态设置为重分布完成状态，然后再重试。结果修改后重试了，重分布的日志显示完成重分布了，但是前台界面重分布状态：待重分布，任务历史是部分成功，后台查询集群状态还是 normal yes yes。查看$GAUSSLOG/om目录下的gs_expand日志，有报can not drop group_version1,because other objects depend on it的报错，再继续查看cn日志，有详细打印出报错的依赖对象，还是那3张表的问题。3、需要将这3张表删除，与一线沟通后drop掉这3张表后，前台重新调起重分布后正常。

1.什么是D状态进程？Linux内核中定义了以下几种状态：#define TASK_RUNNING 0#define TASK_INTERRUPTIBLE 1#define TASK_UNINTERRUPTIBLE 2#define TASK_ZOMBIE 4#define TASK_STOPPED 8其中：TASK_RUNNING是就绪态，进程当前只等待CPU资源。TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE都是阻塞态，进程当前正在等待除CPU外的其他系统资源；前者可以被信号唤醒，后者不可以。TASK_ZOMBIE是僵尸态，进程已经结束运行，但是进程控制块尚未注销。TASK_STOPPED是挂起状态，主要用于调试目的。进程接收到SIGSTOP信号后会进入该状态，在接收到SIGCONT后又会恢复运行。展开全部使用top -c 查看进程状态：S(state)O：进程正在处理器运行,这个状态从来木见过.S：休眠状态（sleeping）R：等待运行（runable）R Running or runnable (on run queue) 进程处于运行或就绪状态I：空闲状态（idle）Z：僵尸状态（zombie）　　　T：跟踪状态（Traced）B：进程正在等待更多的内存页D:不可中断的深度睡眠，一般由IO引起，同步IO在做读或写操作时，cpu不能做其它事情，只能等待，这时进程处于这种状态，如果程序采用异步IO，这种状态应该就很少见到了2.现网现象分析因D状态与IO强相关，故查询即时IO发现await确实较大处于sleeping状态的进程一直在增多，机器负载过高，但实际查看cpu及内存使用率并不高。查询D状态的进程为此命令应该为某个监控命令，会循环调用。所以不及时处理，D进程会越来越多。实际查看df命令确实无法成功显示。以FI修复建议以及硬件专家建议重启机器进行规避。

问一下 在jave 程序中怎么保证多线程的运行安全？

1 内存基础知识1.1 操作系统内存内存是操作系统中程序使用的重要资源，一般使用以下命令查看系统内存使用情况free -gfree命令可以查看当前系统内存整体情况。如free列的值>min_free_kbytes，则系统中有可用内存，不会出现OOM。top命令可查看系统当前各个进程的内存使用情况。主要查看RES、SHR和%MEM列，RES为进程(实例)当前使用的物理内存量，SHR为进程(实例)当前使用的共享内存量，RES包含SHR。%MEM为进程（实例）当前占系统总内存的百分比。OOM(out of memory)：操作系统OOM指的是操作系统的一种保护机制，在系统无法分配内存时，会让oom-killer程序选择一个占用内存最高的进程，将其kill掉，以保证系统中其他进程能正常执行。在触发OOM后，OS会在/var/log/messages中打印相关信息，一般搜索oom-killer即可，日志中当时的系统中所有进程的内存使用情况，可以用于判断是不是数据库进程导致OOM.如果为数据库进程导致OOM，需分析数据库max_process_memory是否设置合理，适当调小max_process_memory来避免OOM。1.2 数据库进程内存数据库进程中使用内存层次如下：进程级内存：max_process_memory： 单进程所能占用的最大内存语句级内存：query_max_mem: 单语句在单DN上能占用的最大内存算子级内存：work_mem: 单个算子在单DN上能占用的最大内存。 公用内存：1.                   存储引擎使用的缓存（参数shared_buffers（行存）和cstore_buffers（列存））2.                   通信库使用的缓冲区（参数comm_usable_memory）3.                   其他（动态库申请的内存，一般很少，如果模块使用较多，请自行控制）其他内存：DDL语句，优化器、系统表cache等内存上下文管理的内存。 重要概念：内存上下文内存上下文可以简单理解为一个语句在一个实例中执行时，对所使用的动态内存按类型的一个树状结构。例如。Hashjoin语句在访问系统表时，要使用cache context,在创建哈希表时，要创建Hash context。所有动态申请的内存都由内存上下文管理。包括work_mem占用的内存，DDL语句、优化器、系统表cache等。  内存问题常用定位视图：目前，GaussDB 200对外提供诸多系统视图，可以用来辅助内存问题的分析定位，常用视图及用法说明如下表所示。（☆代表常用程度）pv_total_memory_detail ☆☆☆☆☆查询当前实例上整体内存使用状态和信息，可以看到各类型内存使用情况，来对当前实例上内存使用情况做一个概要的判断。select * from pv_total_memory_detail;Memorytype中各类型含义如下： 名称含义max_process_memory   实例可用最大内存阈值。由guc参数max_process_memory控制。process_used_memory  实例当前已使用的内存值，从OS top命令RES列取得。如process_used_memory已经或马上要超过max_process_memory，说明当前内存使用已经超限，或马上就要超限。max_dynamic_memory   实例可使用的最大动态内存dynamic_used_memory  实例当前已使用的动态内存dynamic_peak_memory  实例从启动后到目前为止的动态内存峰值dynamic_used_shrctx  当前已使用的共享内存上下文内存量，也记录在dynamic_used_memory内dynamic_peak_shrctx  共享内存上下文峰值。如减去sctpcomm_peak_memory后超过1G，说明共享内存没有释放，存在泄漏。max_shared_memory    最大共享内存，主要为shared_bubffers。shared_used_memory   实例当前已使用的共享内存，从OS top命令SHR列取得max_cstore_memory    列存buffer可使用的最大内存，由guc参数cstore_buffers控制。cstore_used_memory  实例当前已使用的列存buffer.max_sctpcomm_memory  通信模块可使用的最大内存。sctpcomm_used_memory 通信模块已使用的最大内存sctpcomm_peak_memory 通信模块峰值内存other_used_memory    其他内存占用，为OS  RES-     dynamic_used_memory- shared_used_memory- cstore_used_memory后的值。一般为系统中不受memory context管理的的第三方组件所占用的内存。如果过大，也有可能是内存泄漏。 pv_session_memory_detail ☆☆☆☆☆查看内存上下文级别的内存占用详细信息select * from pv_session_memory_detail order by totalsize desc   limit 100;视图中各字段含义如下：名称类型描述sessidtext线程标识+线程启动时间。使用substr可以将线程号过滤出来，方便和上述其他视图进行关联。sesstypetext线程名称。contextnametext内存上下文名称。levelsmallint当前内存上下文的层级。parenttext父内存上下文名称。totalsizebigint当前内存上下文的内存总数，单位字节。指的是分配给当前内存上下文的内存总数，为freesize+usedsize之和。freesizebigint当前内存上下文中已释放的内存总数，单位字节。是指当前你内存上下文中预留的内存，只有这个内存上下文可以使用，其他线程及其他内存上下文都不能使用，实际还是当前内存上下文中占用的。usedsizebigint当前内存上下文中已使用的内存总数，单位字节。       2 内存问题分类问题原因大类问题原因小类集群参数配置集群参数配置不合理OS配置OS参数配置不合理，主要为min_free_kbytes业务层面业务并发度增加业务SQL计划变化（含有hash、sort、agg等）是否新增业务CN报错SQL是否下推参数优化集群内存相关参数并发控制参数业务优化增加内存集群扩容内存泄漏软件BUG 3 内存问题定位方法及解决措施3.1 基本步骤1 Memory is temporary unavailable问题Step1. 当出现memory is temporary unavailable报错后，首先确认是哪个实例报错，是CN还是DN。Step2. 使用gsql登陆到报错的实例上，查询pv_total_memory_detail, 重点查看一下信息：1.       当前是否还存在内存不足问题。方法为查看process_used_memory和max_process_memory的关系，如已经大于或比较接近，则说明当前内存使用已经或即将超限。如明显小于，则说明占用内存大的语句已经跑完或者被杀掉。当前系统已经恢复。这时可查看对应的peak_memory值，如peak_memory值过高，说明确实曾经出现过内存使用过大。2.       当前是哪个类型的内存过大。最常见的是dynamic_used_memory过大，说明动态申请的内存过大，这类问题可能和客户正在运行的SQL强相关。Step3.如通过step2发现当前内存占用仍过高，则进一步使用pv_session_memory_detail继续分析，看内存占用过高是哪个内存上下文引起的。视图中有线程号信息及内存上下文信息，通过这些信息可以判定是什么语句的什么操作占用了过多内存，进而可以cancel此语句，并给客户提出语句优化建议。常见语句问题为：1.       SQL不下推。如内存问题在CN上出现，很大程度上是因为某个SQL的不下推导致。通过explain确认语句不下推后，将语句进行修改使其下推。2.       中间结果集倾斜。GaussDB 200在进行表关联时，优先使用hash join, 需要对一张表创建哈希表，当哈希表大小超过work_mem限制时，会进行下盘避免内存占用过多，但如果原始表里或中间结果集中在join列上存在大量重复数据，是无法下盘的，必须全部载入内存中进行计算，会造成内存大量占用。如pv_session_memory_detail中占用内存最大的内存上下文为hash context,则大概率是此问题。这时应对客户的表和SQL进行分析，对重复值进行处理后，再进行关联。Step4.如通过上一步没有发现内存占用过高的单个语句，但系统整体内存占用仍过高，则问题原因为参数配置不合理或用户语句并发设置不合理。1.       参数配置不合理。需评估系统关键内存参数是否设置合理。如用户将Poc环境直接转为生产。Poc环境为了追求极致性能，一般内存参数设置比较激进。而生产系统 需要长期稳定运行，内存参数设置应相对保守。此时应调整相关参数。a)         max_process_memory设置过小，导致内存不能充分利用而提前报错。b)        shared_buffer/cstore_buffer设置过大：shared_buffer设大可以增大缓存空间，提高数据读取效率，但如设置过大，会导致语句运行时无法申请到足够的动态内存，导致报错。c)         work_mem/maintainence_work_mem设置过大：在高并发场景下，work_mem设置过大可能导致所有语句的work_mem加起来超过可用动态内存的最大值，从而导致报错。 2.       语句并发设置不合理。此问题与参数配置不合理问题相关。语句并发高，则内存参数配置应较小；反过来说，如内存参数配置较大，则可支撑的语句并发也就相应的要变低。a)         局点上线后，或局点业务量增大后频繁报内存不足，很可能是因为max_active_statements设置过高，高并发的语句加起来后超出了系统可用内存上线，此时如检查第一点中参数都合理后，应将max_active_statements调小，让语句排序进行，避免一起运行时报错。b)        局点新上业务后报内存不足，很可能是因为新业务较为复杂，有多个表join、sort或group by。此时如分析不存在中间结果集倾斜，则需要将并发调小，或将work_mem调小。以上操作都可能导致业务响应时间变长，需要和客户确认。Step5. 如分析时已没有现场，则有3个方法来确认什么语句导致了问题1.       到报错的节点日志中搜索全部memory is temporary unavailable报错，分析可能是哪个语句导致的。2.       重新让客户运行业务，或等下次业务高峰期时进行分析。3.       打开active sql。打开后会将内存相关信息记到系统表中。 附：查看集群配置情况和关键参数（1）集群每个物理节点内存、每个节点dn个数；select sessid, contextname, level,parent,totalsize,freesize,usedsize,  datname,query_id  from pv_session_memory_detail a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid and b.state='active' order by usedsize desc limit 20 ;（2）监控session total memory size占用最多的TOP20 session 。select sessid, sum_total, sum_free,sum_used, query_id, query_start, state, waiting, enqueue,query from (select sessid, sum(totalsize) as sum_total, sum(freesize) as sum_free, sum(usedsize) as sum_used from pv_session_memory_detail group by sessid  order by sum_total desc limit 20 ) a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid;（3）监控session中占用内存最多的context TOP20 session.select sessid, contextname, level,parent, pg_size_pretty(totalsize),pg_size_pretty(freesize),pg_size_pretty(usedsize),  datname,query_id, query  from pv_session_memory_detail a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid  order by totalsize desc limit 20 ;（4）监控当前实例总totalsize memroy大小select pg_size_pretty(sum(totalsize)) from pv_session_memory_detail;（5）监控当前实例总usedsize memroy大小select pg_size_pretty(sum(usedsize)) from pv_session_memory_detail;（6）监控当前实例内存总体使用情况select * from pg_total_memory_detail;（7）监控共享内存实时使用情况select * from pg_shared_memory_detail; 4. 通过打开active sql开关来分析某一时间段并发量和单个sql执行使用的内存信息（如果enable_resource_track和enable_resource_record为off表示该功能关闭）打开方法：gs_guc reload -Z coordinator -Z datanode -N all -I all -c 'enable_resource_track =on' ;gs_guc reload -Z coordinator -Z datanode -N all -I all -c 'enable_resource_record =on' ;Active sql分析使用方法（1）查询2018-11-9峰值内存使用top10的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' order by nodename,max_peak_memory desc limit 10; （2）查询2018-11-9CPU使用top10的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' order by nodename,total_cpu_time desc limit 10; （3）查询2018-11-9查询时间最长的top10的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' order by nodename,duration desc limit 10;（4）查询2018-11-9SQL执行失败，错误信息为” memory is temporarily unavailable”且最大峰值内存超过1G的SQLselect * from pgxc_wlm_session_info where start_time like '%2018-11-1%' and status='aborted' and abort_info like '%memory is temporarily unavailable%' and max_peak_memory >1000 order by max_peak_memory desc;               （5）查询不下推的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' and query_plan like ‘%_REMOTE_TABLE_QUERY_ %’;（6）查询不下盘的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' and warning like ‘%spill%’;2 操作系统OOM问题Step1. 查看OS日志：/var/log/messages,搜索oom-killer,确认额是否为gaussdb进程触发的OOMStep2. 分析数据库内存参数，确认设置是否合理，特别是max_process_memory;##常见案例，见附件，请留下邮箱，我们会将文件发送到您邮箱

表1中描述了在GaussDB A操作与维护阶段，进行日常操作时应注意的禁用操作。表1 禁用操作类别操作风险严禁JDBCServer主备节点频繁倒换频繁主备倒换将导致业务中断严禁修改节点主机名主机名修改后会导致该主机上相关实例和上层组件无法正常提供服务，且无法修复严禁修改数据目录下文件名，权限，内容不能修改，不能删除内容导致DN实例出现严重错误，并且无法修复严禁删除数据库系统表或系统表数据删除系统表将导致无法正常进行业务操作表2中描述了在GaussDB A操作与维护阶段，进行日常操作时应注意的高危操作。表2 高危操作操作分类操作名称操作风险风险等级规避措施重大操作观察项目Manager修改OMS密码该操作会重启OMS各进程，影响集群的管理维护★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常导入证书该操作会重启OMS进程和整个集群，影响集群的管理维护和业务★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常升级该操作会重启Manager和整个集群，影响集群的管理维护和业务分配集群管理权限的用户，需要严格管控，以防范可能的安全风险★★★修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常补丁该操作会重启Manager和整个集群，影响集群的管理维护和业务分配集群管理权限的用户，需要严格管控，以防范可能的安全风险★★★修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常恢复OMS该操作会重启Manager和整个集群，影响集群的管理维护和业务★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常修改IP该操作会重启Manager和整个集群，影响集群的管理维护和业务★★★修改时确保同一时间无其它管理维护操作，且修改的IP填写正确无误观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常修改日志级别如果修改为DEBUG，会导致Manager运行速度明显降低★★修改前确认操作的必要性，并及时修改回默认设定无更换控制节点该操作会导致部署在该节点上的服务中断，且当该节点同时为管理节点时，更换节点会导致重启OMS各进程，影响集群的管理维护★★★更换前确认操作的必要性，更换时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常 更换管理节点该操作会导致部署在该节点上的服务中断，会导致重启OMS各进程，影响集群的管理维护★★★★更换前确认操作的必要性，更换时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常重启下层服务时，如果勾选同时重启上层服务该操作会导致上层服务业务中断，影响集群的管理维护和业务★★★★操作前确认操作的必要性，操作时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常修改OLDAP端口修改该参数时，会重启LdapServer和Kerberos服务和其关联的所有服务，会影响业务运行  ★★★★★操作前确认操作的必要性，操作时确保同一时间无其它管理维护操作无重装主机该操作会对指定主机上的软件进行重新安装，并可能因清理数据目录造成数据丢失★★★操作前请确认重新安装的必要性，并谨慎选择清理数据选项观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常重装实例该操作会对指定主机上的实例进行重新安装，并可能因清理数据目录造成数据丢失★★★操作前请确认重新安装的必要性，并谨慎选择清理数据选项观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常重启服务重启过程中会中断服务，如果勾选同时重启上层服务会导致依赖该服务的上层服务中断★★★操作前确认重启的必要性观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常系统下电、上电非标准化下电、上电操作，会导致系统再次上电后，集群启动异常，如Ldap数据不同步、controller启动失败等★★★请参考系统上下电进行标准的系统下电、上电操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常KrbServer 修改KrbServer的参数“KADMIN_PORT”修改该参数后，若没有及时重启KrbServer服务和其关联的所有服务，会导致集群内部KrbClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启KrbServer服务和其关联的所有服务无修改KrbServer的参数“kdc_ports”修改该参数后，若没有及时重启KrbServer服务和其关联的所有服务，会导致集群内部KrbClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启KrbServer服务和其关联的所有服务无修改KrbServer的参数“KPASSWD_PORT”修改该参数后，若没有及时重启KrbServer服务和其关联的所有服务，会导致集群内部KrbClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启KrbServer服务和其关联的所有服务无修改KrbServer的参数“default_realm”修改该参数后，若没有及时重启KrbServer服务和其关联的所有服务，会导致集群内部KrbClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启KrbServer服务和其关联的所有服务无配置跨集群互信该操作会重启KrbServer服务和其关联的所有服务，影响集群的管理维护和业务★★★★★更换前确认操作的必要性，更换时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常LdapServer修改LdapServer的参数“LDAP_SERVER_PORT”修改该参数后，若没有及时重启LdapServer服务和其关联的所有服务，会导致集群内部LdapClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启LdapServer服务和其关联的所有服务无修改LdapServer的参数“LDAP_EXTERNAL_IP”修改该参数后，若没有及时重启LdapServer服务和其关联的所有服务，会导致集群内部LdapClient的配置参数异常，影响业务运行★★★★★修改该参数后，请重启LdapServer服务和其关联的所有服务无恢复LdapServer数据该操作会重启Manager和整个集群，影响集群的管理维护和业务★★★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作 观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常 更换LdapServer所在节点该操作会导致部署在该节点上的服务中断，且当该节点为管理节点时，更换节点会导致重启OMS各进程，影响集群的管理维护★★★更换前确认操作的必要性，更换时确保同一时间无其它管理维护操作观察是否有未恢复的告警产生，观察集群的管理维护是否正常，业务是否正常 修改LdapServer密码修改密码需要重启LdapServer和Kerberos服务，影响集群的管理维护和业务 ★★★★修改前确认操作的必要性，修改时确保同一时间无其它管理维护操作 无节点重启导致LdapServer数据损坏如果未停止LdapServer服务，直接重启LdapServer所在节点，可能导致LdapServer数据损坏★★★★★使用LdapServer备份数据进行恢复无数据库不能直接在配置文件中手动修改端口号。导致数据库启动不了或者连接不上。▲▲▲▲▲尽量使用工具修改，不要手动操作。无。不能随意修改“pg_hba.conf”配置文件中的内容。导致客户端连接不上。▲▲▲▲▲严格根据产品手册操作。无。不能手动修改“pg_xlog”的内容。导致数据库无法启动，数据不一致。▲▲▲▲▲尽量使用工具修改，不要手动操作。无。

集群启停问题定位指南1      集群启停基本原理1.1      起停依赖关系描述及图示FIM：集群管理界面，用户可以从FIM界面上下发启动和停止集群操作； cron：系统服务，每一分钟定时查看om_monitor服务是否拉起，如果没有拉起，则拉起；om_monitor：常驻系统，用于拉起cm_agent；cm_agent：起停 cn、dn、gtm、cm_server，以及在停止时，当cn、dn、gtm、cm_server停止后，cm_agent自退出。      1.2      日志路径组件名日志路径FIM/var/log/Bigdata/mpp/scriptlog/prestart.log/var/log/Bigdata/mpp/scriptlog/start.log以上日志每个数据节点上均存在gs_om/var/log/Bigdata/mpp/omm/om/gs_om-   YYYY-MM-DD_hhmmss.log以上日志每个数据节点上均存在om_monitor/var/log/Bigdata/mpp/omm/cm/cm_agent/om_monitor-YYYY-MM-DD_hhmmss.log以上日志每个数据节点上均存在cm_agent/var/log/Bigdata/mpp/omm/cm/cm_agent/cm_agent-YYYY-MM-DD_hhmmss.log/var/log/Bigdata/mpp/omm/cm/cm_agent/system_call-YYYY-MM-DD_hhmmss.log以上日志每个数据节点上均存在cm_server/var/log/Bigdata/mpp/omm/cm/cm_agent/cm_server-YYYY-MM-DD_hhmmss.log以上日志仅在主备cm_server节点上均存在1.3      集群实例角色状态信息表实例角色状态DN   build 状态和GTM 同步状态CMSPrimary(主)Standby(备)Pending(待仲裁状态，等待仲裁为主或者备)DownCNNormal(正常)Deleteing(正在删除)Deleted(已经删除)DownDNPrimary(主)Standby(备)Dummy_standby(从备)Pending(待仲裁状态，等待仲裁为主或者备)DownNormal(正常)Starting(正在启动)Need   repair(待处理状态)Waiting   Promoting(等待升主)Promoting(备机升主中)Demoting(主机降备中)Building(备机正在build)Build   failed(备机build失败)Manual   stop(手动停止)Disk   damaged(磁盘故障)Port   used(端口占用)Unknown(状态未知)Connecting(DN主备连接)Disconnect(DN主备未连接)Walsegmen   removed(DN日志分叉) GTMPrimary(主)Standby(备)Pending(待仲裁状态，等待仲裁为主或者备)DownConnection   OK(主备连接OK)Connection   bad(主备连接有问题)Starting(正在启动)Manual   stop(手动停止)Disk   damaged(磁盘故障)Port   used(端口占用)Unknown(状态未知)Sync(同步模式)Async(非同步模式)Most   available(最大可用模式)2      启动集群常见问题分类3      集群启停问题定位方法及解决措施使用命令cm_ctl query -Cv查看集群状态，根据状态进入不同分支场景进行排查处理。3.1      整节点未启动Step1. 使用命令cm_ctl query -Cv查看集群状态信息确认整节点未启动的主机名；Step2. omm用户登录对应节点，查看om_monitor进程是否存在，如果om_monitor进程不存在，则可能原因是omm用户定时任务异常、omm用户密码超期、cgroup挂载异常，可通过分析om_monitor日志、omm用户定时任务、omm用户密码超期时间等方式进行进一步分析；Step3. 如果节点上om_monitor进程存在，cm_agent进程不存在，则可能原因是FIM界面启动命令未成功下发到后台、python版本过高或其它原因导致om_monitor未能启动cm_agent，可通过检查启停标志文件、节点上python版本、om_monitor日志等方式进一步分析。部分实例未启动，查看具体的实例问题，逐步分析。一般启动问题为DN、CN、GTM等实例启动失败，或者无法选主。这种情况，需要结合日志分析。通常有磁盘故障、端口占用、环境变量冲突等情况。3.2      节点内部分实例未启动Step1. 使用命令cm_ctl query -Cv查看集群状态信息确认未启动的实例及所在节点主机名；Step2. omm用户登录对应节点，查看cn/dn/gtm/cm_server实例进程是否存在，如果进程不存在，则可能原因是端口被占、lvs虚拟ip丢失、cn/dn的postgresql.conf配置文件的listen_address参数存在无效ip、进程listen端口号对应锁文件残留、cn/dn配置文件中存在无效GUC参数、系统信号量参数配置过小、存在多个cm_agent进程、路径无权限、磁盘满、数据目录权限异常等，需要结合日志具体分析；Step3.如果cn/dn/gtm/cm_server进程存在,但状态为down或者unknown，则可能原因是当前节点与主cm_server节点网络不通、cm_server无主、节点上存在子网卡等；Step4.如果cn/dn/gtm/cm_server进程存在,但状态为pengding，则说明可能是在做redo，可通过查看堆栈来确认。3.3      节点实例未停止Step1. 首先使用如下命令找到未正常停止的实例：gs_ssh -c 'ps -ef|grep /opt/huawei/Bigdata/mppdb/core/bin/ | grep -v grep'Step2.1 实例未被停止分为两种情况，一种是实例收到停止信号，但是无法停止，这种现象主要体现在CN、DN正在执行业务，无法停止。当CN、DN无法停止的时候，需要搜集CN、DN堆栈，用于定位问题；Step2.2 第二种是执行停止的命令异常，此时请查看cma日志，手动拆解停止的shell命令，查看那些命令异常，一般为pstree命令异常。当pstree命令等shell命令异常时，分为两种情况：1）系统不存在该命令，请安装该命令，或者查看环境变量是否正确；2）系统pstree结果不符合预期，请更新该命令版本。4      集群启停问题常见案例4.1      整节点未启动，om_monitor进程不存在问题现象：启动集群时整节点未启动，对应节点上om_monitor进程不存在定位过程：omm用户登录到到未启动的节点，使用以下命令确认om_monitor进程不存在：ps –eaf | grep om_monitor4.1.1        Om_monitor定时任务未挂载场景描述：使用如下命令查看启动om_monitor的定时任务是否挂载到cron服务上，如果未挂载上，则是安装失败或定时任务被删除。通过 crontab服务可以看到如下命令，代表om_monitor服务挂载成功。crontal -l解决方法：参照正常节点将om_monitor定时任务服务添加到omm用户的定时任务中。4.1.2        Omm用户密码超期场景描述：使用如下命令检查是否设置了omm用户密码超期时间且密码已过期，如果密码超期会导致omm用户定时任务无权限查看，进而导致无法拉起om_monitor进程。chage -l omm解决方法：使用如下命令将omm用户密码超期时间设置为永不过期chage -M 99999 omm4.2      整节点未启动，cm_agent进程不存在问题现象：整节点未启动，om_monitor进程存在，但cm_agent进程不存在定位过程：omm用户登录到未启动的节点，使用以下命令确认cm_agent进程不存在：ps –eaf | grep cm_agent4.2.1        启停标志文件存在场景描述：检查om_monitor日志中是否有如下格式的日志打印，如果有说明cgroup未挂载成功，导致CMA拉起异常can't get the *cgroup*解决方法：重新挂载cgroup。4.2.2        启停标志文件存在场景描述：检查bin目录下启停标志文件是否存在，如果存在说明FIM界面启动命令未下发到后端ll /opt/huawei/Bigdata/mppdb/core/bin/cluster_manual_start解决方法：1、  删除此文件即可从后台自动拉起该节点实例；2、  FIM界面启动命令未下发到内核原因可排查分析该节点上如下两个日志文件中的报错信息来确认/var/log/Bigdata/mpp/scriptlog/prestart.log/var/log/Bigdata/mpp/scriptlog/start.log4.2.3        Python版本过高场景描述：检查节点上python版本为3.x，与数据库默认的2.7不符，FIM界面启动时start.log日志中有如下报错，则说明是python版本过高导致启动异常解决方法：与现场人员确认是否手动升级过python版本或安装了多个版本的python，并让现场人员将节点上默认python版本恢复为2.7版本。4.2.4          环境变量文件为空场景描述：检查/opt/huawei/Bigdata/mppdb/.mppdbgs_profile环境变量文件为空，则说明环境变量文件为空导致FIM界面启动命令未下发到内核         解决方法：从正常节点拷贝一份过来即可。4.2.5        启停标志文件不存在场景描述：检查bin目录下启停标志文件不存在，说明是其它原因导致om_monitor未能启动cm_agent解决方法：收集节点上om_monitor和cm_agent日志进一步分析。4.3      节点内部分实例未启动，cn/dn/gtm/cm_server进程不存在问题现象：节点内部分实例未启动，未启动的cn/dn/gtm/cm_server实例进程不存在定位过程：omm用户登录到实例未启动的节点，使用以下命令确认相应实例进程不存在：ps –eaf | grep gaussdbps –eaf | grep gs_gtmps –eaf | grep cm_server4.3.1        信号量不足导致cn/dn启动异常场景描述： 检查对应cn/dn实例的pg_log日志，如果有如下报错，则说明是信号量不足导致cn/dn启动异常解决方法：1、  使用root用户执行如下命令可以将节点上os参数配置为预期值；/opt/huawei/Bigdata/mppdb/wisequery/script/gs_checkos -i B1 --detail2、建议使用巡检工具对集群进行全面巡检和整改。4.3.2        postgresql.conf配置文件存在无效GUC参数场景描述：检查对应节点上cm_agent和systemcall日志中如果有如下报错，则说明cn/dn的postgresql.conf配置文件中存在无效参数配置/var/log/Bigdata/mpp/omm/cm/cm_agent/cm_agent-YYYY-MM-DD_hhmmss-current.log/var/log/Bigdata/mpp/omm/cm/cm_agent/system_call-YYYY-MM-DD_hhmmss-current.log解决方法：删除postgresql.conf配置文件中无效参数即可。4.3.3        端口号被占场景描述：检查对应节点上cm_agent和systemcall日志中如果有如下报错，则说明cn/dn/cm_server/gtm的端口号被占/var/log/Bigdata/mpp/omm/cm/cm_agent/cm_agent-YYYY-MM-DD_hhmmss-current.log/var/log/Bigdata/mpp/omm/cm/cm_agent/system_call-YYYY-MM-DD_hhmmss-current.log Port 25308 is used, run 'netstat -anop|grep 25308' or 'lsof -i:25308'(need root) to see who is using this port.解决方法：1、  使用如下命令找到占用端口的进程netstat -anop|grep portlsof -i:port （root执行）2、  kill -9清理掉占用端口的进程，然后重新启动。4.3.4        Lvs虚拟ip未挂载场景描述：cn的listen_addresses参数中配置了lvs虚拟ip，但cn节点上lvs虚拟ip未正常挂载，则也会导致cn启动不了检查cn实例listen_addresses配置命令：cat /srv/BigData/mppdb/data1/coordinator/postgresql.conf|grep listen_addresses查看节点上ip信息命令：/sbin/ifconfig解决方法：使用如下命令重新挂载lvs虚拟ipsh /etc/init.d/gs_vip start4.3.5          进程listen端口号锁文件残留场景描述：机器异常掉电重启等情况下可能会导致进程listen端口号锁文件残留，这样当重新启动时会因锁文件已存在而无法启动。检查锁文件命令：ls -la  /opt/huawei/Bigdata/mppdb/mppdb_tmp检查查出来的锁文件产生时间是否是在启动时间之前，如果是则说明是之前残留的。解决方法：将残留的锁文件删除。4.3.6        Cn/dn的listen_addresses中存在无效ip场景描述：cn/dn的postgresql.conf配置文件的listen_addresses参数存在无效ip时会导致cn/dn无法正常启动，system_call日志中会有如下报错：FATAL:  could not create listen socket for "100.185.180.62"/var/log/Bigdata/mpp/omm/cm/cm_agent/system_call-YYYY-MM-DD_hhmmss-current.log检查cn实例listen_addresses配置命令：cat /srv/BigData/mppdb/data1/coordinator/postgresql.conf|grep listen_addresses解决方法：将listen_addresses参数中的无效ip删除。4.3.7        数据目录无权限场景描述：cn/dn/gtm/cm_server的数据目录权限预期是700，当权限不足时cm_agent日志中会有如下报错：data path disc writable test failed, /srv/BigData/mppdb/data3/slave1解决方法：根据报错提示修复cn/dn/gtm/cm_server数据目录的权限。4.3.8        磁盘满场景描述：节点上数据盘、日志盘等满均会导致cn/dn/gtm/cm_server进程启动异常。磁盘使用率检查命令：df -lh解决方法：清理释放磁盘空间，消除磁盘满。4.4      节点内部分实例未启动，查看状态CN、DN、GTM实例状态为down或者unknown启动集群失败，后台查看集群状态，发现CN、DN、GTM实例显示down或者unknown。4.4.1        当前节点与主cm_server节点网络不通场景描述：当节点与主cm_server节点网络不通时，当前节点cm_agent无法将实例状态上报给cm_server，导致实例状态显示为down或unknown。检查当前节点与主cm_server节点网络命令：在当前节点上ping 主cm_server节点ip，如果不能ping通则说明网络异常。解决方法：联系网络侧人员解决网络问题。4.4.2        Cm_server无主场景描述：当集群中两个cm_server实例均为pending状态，没有选出主时，无法对DN状态进行仲裁，导致DN状态均显示为down或unknown。检查当前集群cm_server状态命令：cm_ctl query -vCd|grep cm_server 解决方法：收集主备cm_server日志并联系研发人员处理。4.4.3        节点上存在多个om_monitor进程场景描述：当节点上存在多个om_monitor进程时，会导致cm_agent进程反复被杀，无法持续向cm_server上报实例状态，进而导致节点上实例状态显示为down或unknown。检查当前节点om_monitor个数命令：ps -ef|grep om_monitor|grep -v grep 解决方法：kill掉当前所有om_monitor进程待起自动重新拉起。 

1. TaurusDB背景随着云计算进入2.0时代，数据急剧膨胀，这对实现数据库的高可靠、高性能、高吞吐的目标产生了巨大的挑战。如图1 所示，TaurusDB是华为自研的最新一代企业级具备横向扩展、海量存储能力的分布式数据库，其采用了计算存储分离，一写多读的分布式架构。将原本计算层的高密度存储相关压力下沉到存储层，极大地释放了计算层的算力。但同时将原来的存储IO转移到了网络IO，这也就是意味着，存储层将面临来自计算层风暴级的压力。如果存储层不能快速响应计算层的读写请求，会极大影响用户的使用体验。图1 TaurusDB整体架构图2 slice功能组件从图2可知，TaurusDB的存储层，不单单只做存储相关的工作，也需要大量的算力，比如consolidation生成特定数据页、compation回收旧版本数据、BufferPool缓存热点数据页等任务。为了能加快这些任务的高效执行，我们首先能想到的就是能够并行执行这些任务，也就是采用多线程技术处理的方式，增加处理器单元的吞吐能力，从而提高存储端的执行效率。2.线程池化设计思想2.1线程为什么需要池化首先，线程是稀缺的资源，如果频繁创建和销毁线程的开销是可观的，所占用的时间可能多于实际任务的执行；且当需要执行任务时，都去创建一个对应的线程去处理，那么服务器的资源(比如地址空间和内核参数)很快就会被耗尽，导致而导致OOM问题。其次，通过事先创建好一定数量的线程并置于公共池之中，这样当有任务需要执行时，只需从公共池取一个线程执行当前的任务即可，待任务结束后，此线程又可以执行其他任务或处于休眠状态，等待下一次被调度，达到线程资源重复使用的目的。2.2线程池如何管理为了能有效的管理多线程，TaurusDB存储端采用了如图3的线程池模型。图3 线程池模型ThreadPool: ThreadPool: 主要负责控制线程池的大小、状态变更、线程的创建、销毁、调度策略的选取；Scheduler：负责具体任务的接收、被调度的顺序，并触发任务的执行；Worker：负责具体任务的执行；Monitor:负责监控线程执行任务时是否出现异常，以及异常告警，比如线程执行一次任务长时间执行未能结束。2.3 线程池的调度策略当前TaurusDB存储端线程池支持三种策略：先进先出调度(FifoScheduler)、定时调度(TimeScheduler)、基于容量调度(CapacityScheduler)。对于FifoScheduler和TimeScheduler，比较容易理解。当有任务需要执行时，只需将此任务存放在一个队列即可，有scheduler按照顺序逐一调度即可。对于CapacityScheduler，是一种基于事先为某一类型的任务预留可执行线程的思想，其预留的线程个数由下发任务的用户指定。具体调度过程见图4。图4 CapacityScheduler调度比如：初始化线程大小为10，TaskType1预留线程数4，TaskType2：预留线程数5，TaskTypeN：预留线程数4当线程池处于如图4状态时，任务类型是1和3的尚未达到预留值，任务类型N已达到阈值。此时如果Threadpool中处于idle的线程数为1，则该线程将会被调度到任务类型为2的队列中。 2.4 任务异常监控告警我们知道，一旦任务被调度的线程执行过程中，可能会出现异常情况，比如线程死锁，导致该任务不能按照预期推进，轻者引发系统出现CPU、IO等系统资源使用率飚高的情况，严重者会导致系统down情形。比如TaurusDB的存储端，执行log的checkpoint的线程出现长时间卡顿，会导致存储端旧的log不能正常回收，导致磁盘空间逐步膨胀，进而影响存储端其他各个模块平滑的推进。如果能够识别出处于异常状态的线程，并能够进行告警，基于事先自定义规则进行修复，将能够持续保证存储端业务的连续性。线程池Monitor组件就是用于识别处于异常状态的线程，其基本思想就是，定期巡检线程池中的各线程处于状态，如果发现线程状态长时间未更新，则判定该线程处于异常状态，上报告警，并基于相应的处理规则处理。3. 下一步演进方向从2.3中可以看出，CapacityScheduler策略是基于实际在执行的线程数，作为idle线程线程被调度的依据，尚未衡量实时任务的重要程度。考虑这样一种场景，如果有两种类型的任务A、B，在某一时间，用于执行A、B任务的线程数恰好线程或差值极小，但B类型任务的优先级大于A任务，这时可能出现idle线程被调度执行A类型任务，B类型任务不能分配到充足的线程数(预留值是静态分配)，用于加快推进任务的处理。考虑的方案：1.  限制类型任务类型队列的长度，这样可以均衡各类型任务的调度，不至于某一类或几类任务数过多；2.  在系统资源有限的前提下，支持动态伸缩线程池大小的功能，这样可以在工作负载过重时，扩充线程池大小，用于调度到急需执行的任务；3. 进一步细化CapacityScheduler策略，采用任务的重要程度和实际执行的线程数的规则，作为idle线程被调度的依据。

当鼠标放上去以后，出现断线了，这个还是不太友好看看怎么优化一下。

1.   简介TaurusDB是一种基于MySQL的计算与存储分离架构的云原生数据库，一个集群中包含多个存储几点，每个存储节点包含多块磁盘，每块磁盘对应一个或者多个slicestore的内存逻辑结构来管理. 在taurus的slicestore中将数据划为多个slice进行管理，每个slice的大小是10G，Taurus架构图如下：TauruDB的存储层支持append-only写和随机读，最小数据存储逻辑单元为plog，每个slice中包含多个plog，默认每个plog的大小为64M。slice中的plog主要用来存放page。Plog中存放中不同版本的page，有些老page已经过期，需要删除；有些page是新page，需要被保留下来。Compator主要用来清理plog中过期的page，把一个plog上所有没有过期的page搬移到一个新plog，老的plog删除掉。Compactor的任务需要频繁访问内存中索引结构和读写plog中的page页，这两部分都属于整个系统中关键资源，锁竞争的压力比较大，会直接影响性能，所以compactor的优化方案主要围绕减少内存访问和磁盘IO，需要考虑以下几个点：A、 选取的清理的plog集最优问题，每次回收需要搬运有效page，搬运的有效page数越少，磁盘IO就越小。如何每次调度都选取到垃圾量最大的一批plog；B、 垃圾量是否分布均匀，如何让垃圾集中到一起，回收垃圾集中的plog，提高回收效率；C、 回收周期是固定的，怎么样保证在每个周期内，都能取到最优plog集；2.   关键点1-全局调度全局调度的方案增大plog垃圾量的排序范围，从slice的范围增大到slicestore的范围。因为考虑到后面需要针对单个磁盘进行“加速回收”，所以不扩大到一个存储节点的全局范围。全局调度方案按照slicestore来选取回收plog，先遍历所有的slicestore，然后在slicestore内部进行垃圾量排序，选取最多的若干个plog进行回收；优点：有效避免一个slicestore中由于垃圾分布不均匀引起的plog的无效搬运，减少对plog的读写产生的IO；缺点：排序范围增大后，排序算法会增加CPU的消耗；3.   关键点2-排序算法优化原始方案中在slice内部对plog按照垃圾量排序采用C++标准库排序（std::sort），该算法内部基于快速排序、插入排序和堆排序实现。原始方案中每个slice中最多存有160个plog，小数据量的排序或许效率影响不大，但是一个slicestore中存储成百上千的slice，排序算法的效率问题就值得关注。Taurus设计了一种topN算法，能够提升该场景下的效率。假设需要在n个元素中选取m个最大的元素，两种算法的时间复杂度和空间复杂度：C++标准库排序时间复杂度为O(nlogn)，空间复杂度为O(nlogn)；topN算法排序时间复杂度为O(nlogm),空间复杂度为O(1);Compactor应用场景中，n和m相差几个数量级，topN算法在时间和空间上都更具优势。         优点：减少时间复杂度和空间复杂度；4.   关键点3-调度数优化公共线程池分配给compactor的线程数是固定的，每个周期调度器生成一次任务。原始方案中compactor的每次生成的任务数由slice个数决定，会导致任务队列中的任务数过多或者过少。过多的话会失去时效性，也就是说plog的垃圾量会随着时间改变，如果在队列个等待执行的时间太长，可能就不是当前最高垃圾量的plog，同时一次挑选的plog个数太多，会增加算法的时间和空间复杂度；过少的话，compactor线程没有跑满，会导致垃圾回收速度降低。调度数优化也是基于全局调度优化，调度策略只需要保证在一个调度周期内，任务队列中任务数刚好满足compactor线程执行。假设有8个slicestore，分配了24个执行线程，每个线程每个调度周期完成一个plog的回收，则每个调度周期每个slicestore只需要生成3个任务。调度数优化即记录公共线程池中正在执行和准备执行的任务数，跟据记录决定本轮调度生成多少个回收任务，从而保证执行线程刚好够用，且不多不少。优点：保证垃圾回收速度，最优回收的plog集，有效的减少page的搬运量。5.   关键点4-冷热分区优化在数据库系统中，数据的更新并不是相同频率，一些数据页更新或者写入会更加频繁（例如系统页），这部分页面被称作热页，另外一些更新不频繁的称作冷页。如果把冷页和热页混合放到一起，就会导致更高的写放大。举个简单的例子，假设有100个热页和10个冷页，冷页基本不更新但是每次垃圾回收，都需要重复把冷页搬运一次。如果把冷页单独写入一个plog，那么在垃圾回收阶段，就可以减少重复搬运这部分冷页，达到减少IO放大的效果。         优点：提高垃圾回收的效率和速度。         缺点：需要额外的内存记录热度信息。6.   关键点5-磁盘逃生优化为了后台线程比如备份、快照、垃圾回收、页面回放等线程有足够的磁盘空间运行，在磁盘容量使用到达一定阈值，会置Full标志位，同时停止前台IO。在极端情况下，磁盘使用到阈值前台IO会出现断崖式下跌为零：为了避免在磁盘容量达到一定阈值之后前台IO完全停止，在磁盘使用率未达到阈值时，就应该有相应的处理机制。比如说在磁盘使用率未达阈值时，增加如下处理：A、 降低前台IO，减少磁盘的压力；B、 加速垃圾回收，也就是TaurusDB中的compactor机制；A点不涉及compactor的功能，所以本文先不涉及，下面主要介绍加速机制。6.1 修改写IO优先级Compactor作为后台线程，考虑到整个系统的效率，正常运行时plog写IO优先级默认为low。在加速回收阶段，plog的IO需要修改为high。6.2 提高执行速度前文可知，公共线程池为compactor分配固定数目执行线程，而且运行过程中只支持扩容不支持恢复。如果压缩其他后台任务的执行线程，对整个系统的影响太大，量也不易控制。所以不考虑。考虑到过程中不能扩容，那就初始化就扩容，通过控制调度任务数控制任务执行速度。例如，假设compactor的运行线程在正常场景下为4个，加速状态下需要增加到8个。可以在公共线程池中先分配8个线程，在正常场景下，控制任务队列为4个，另外4个线程处于wait状态，只会占用文件句柄，并不影响CPU。而在加速状态下，控制任务队列中的任务数为8，就可以实现上述的加速逻辑。6.3 总结提升写IO的优先级能够加速page的搬运，提升垃圾回收速度。通过控制调度任务数控制任务执行速度却很难控制很精准，上下会有一定的小波动。7.   总结以上1-4个方案能有效的减少page的搬运数，达到减少IO的目的。方案5能够处理磁盘容量紧急情况。目前本地测试，在500G的小数据集情况下，IO放大能减少到原来的1/6。系统资源占用减少到原来的1/3。

copy是cqlsh中的逻辑导入导出命令。包括两个命令COPY TO / COPY FROM.使用这组命令可以在Cassandra与其他RDBMS或Cassandra之间迁移数据。目前已经支持csv, json文件格式以及标准输出和输入。 1. 如何执行copy?    1. 执行copy时，首先要启动cqlsh. 启动cqlsh的方法见 如何使用cqlsh访问Cassandra。启动cqlsh后，接着执行copy命令。如下./cqlsh 127.0.0.1 9042 -u {user_name} -p {password}COPY cycling.cyclist_name TO '/home/cas/copydata';2. 如果数据量很大，可以放在后台执行。使用cqlsh的-e 参数。-e 参数用来后台执行给定的语句，然后退出。命令如下./cqlsh 127.0.0.1 9042 -u {user_name} -p {password} -e "COPY cycling.cyclist_name TO '/home/cas/copydata'";2. COPY TO   ./cqlsh 127.0.0.1 9042 -e "COPY cycling.cyclist_name to '/home/cas/copydata'"COPY TO 常见的参数有: NUMPROCESSES, RATEFILE, PAGESIZE, BEGINTOKEN, ENDTOKEN, MAXATTEMPTS, MAXOUTPUTSIZE; 新增的参数有: RESULTFILE, DATAFORMATS, WHERECONDITION.重点介绍常见和新增的参数，关于其他COPY TO的参数可以参考Cassandra官网文档: copy-to1. `file name` 导出时，可以指定文件名称为目录, 也可以指定文件名称为文件。默认导出到文件。如果指定导出文件为存在的目录时，将会按照range范围导出到目录下的不同的文件中，如果某一个range范围导出没有数据，则不会生成文件。如果指定的文件名是文件，那将会导出到指定的文件中。如果文件不存在，则新创建该文件。./cqlsh 127.0.0.1 9042 -e "COPY cycling.cyclist_name to '/home/cas/copydata'"./cqlsh 127.0.0.1 9042 -e "COPY cycling.cyclist_name to '/home/cas/copydata/cycling.cyclist_name'"2. `NUMPROCESSES` 导出的线程数。在导出时，会将range范围进行细分。导出的线程数越多，细分range的范围数也就越多。但当线程数太多的时候，容易对服务端造成压力，造成导出失败。所以要选择一个合适的线程数进行导出，默认的线程个数是（CPU核数 - 1）3.  `RATEFILE` 速率文件。指定文件路径后，会打印导出过程的瞬时速率，可以用来评价导出的性能。4.  `PAGESIZE` 在一次page查询中。获取的row数。 默认为 1000。 建议不要设的调小。设置太小会影响导出性能。5.  `BEGINTOKEN， ENDTOKEN` 执行要导出的range范围。默认是全部数据导出。6.  `MAXATTEMPTS` 每一个查询重试的次数。如果某次查询达到最大重试次数，那么导出将会直接失败。 7.  `MAXOUTPUTSIZE` 每一个导出文件中的最大的行数。如果导出数据大于这个值。将会轮转生成另一个文件。默认是不限制的。./cqlsh 127.0.0.1 9042 -e "COPY cycling.cyclist_name to '/home/cas/copydata/cycling.cyclist_name' with MAXOUTPUTSIZE=1"8.  `RESULTFILE` 导出结果文件路径，如果不设置。默认生成在当前执行目录下。如果执行目录中存在之前的结果文件，将会重命名之前的结果文件。导出结果的内容主要包括：导出成功与否，总共导出的行数和速率，导出的range范围数，以及成功失败的range范围数，并展示每一个range范围的结果和导出的行数。9. `DATAFORMATS` 导出的数据格式。取值为csv， json。默认为csv格式。指定为json时，导出为json格式的数据。10. `WHERECONDITION` 导出的查询条件。支持查询条件的导出。对于非主键列，如果通过索引来查询，提高导出性能。         1. wherecondition 格式如下 `[key(operators)value,key(operators)value...]`        2. operators 支持 `[">=", "<=", ">", "<", "="]`，例如: `'keyspace_name=system,table_name>=local'`        3. 如果value中包含有特殊字符，比如保留字符 【" ,><=’】, 那么需要给字符加上双引号，例如：`'keyspace_name=system,table_name>="loc>=al"'`一个完整的COPY TO例子：nohup ./cqlsh 127.0.0.1 9042 --request-timeout=3600 --debug -e "COPY nihao.sz_user to '/home/cas/copydata' with WHERECONDITION='update_timestamp=1' NUMPROCESSES=12 AND RATEFILE='rate.txt' AND RESULTFILE='export_result' AND dataformats='json';"  >export.log 2>&1 &3. COPY FROM   COPY <table name> [(<column>, ...)] FROM <file name> WITH <copy option> [AND <copy option> ...]COPY FROM 常见的参数有: NUMPROCESSES, MAXROWS, INGESTRATE, ERRFILE, MAXBATCHSIZE, MINBATCHSIZE, CHUNKSIZE， MAXPARSEERRORS, MAXINSERTERRORS, SKIPROWS, SKIPCOLS;新增的参数有: DATAFORMATS.重点介绍常见和新增的参数，关于其他COPY FROM参数可以参考Cassandra官网文档： copy-from1. `file name` 导入数据时，指定导入的文件路径，可以是一个目录，或者是一个文件，或者是逗号分隔的文件名列表。如果是目录，则导入该目录下的所有文件。2. `NUMPROCESSES` 导入的线程数3. `MAXROWS` 导入的最大行数。默认不限制。4. `INGESTRATE` 每一秒导入的最大行数。默认为 1000005. `ERRFILE` 导入失败的列将放在这个文件中。6. `MAXBATCHSIZE` 每一次batch导入的最大行数。默认为207. `MINBATCHSIZE` 每一次batch导入的最小行数。默认为28. `CHUNKSIZE` 导入主线程给子线程每次传递的行数，默认为 10009. `MAXPARSEERRORS` 可以忽略的语法解析错误的最大行数。默认不限制10. `MAXINSERTERRORS` 可以忽略的插入失败的最大行数。默认为100011. `SKIPROWS` 导入时初始跳过的行数。默认为0，不跳过12. `SKIPCOLS` 导入时忽略的列名，以逗号分隔。默认不忽略。13. `DATAFORMATS` 导入的数据格式。取值为csv，json。默认为csv格式。数据为json格式时，必须指定为json。一个完整的COPY FROM例子：nohup ./cqlsh 127.0.0.1 9042 --request-timeout=3600 --debug -e "COPY nihao.sz_user FROM '/home/cas/copydata' with NUMPROCESSES=12 AND RATEFILE='rate.txt' AND dataformats='json';"  >import.log 2>&1 &