云数据库运维实战手册

3 3 27 33 87 133 213常见问题MongoDB云数据库常见问题诊断Q:连接实例提示网络超时?#/u01/mongodb_current/bin/mongo--:3717--authenticationDatabaseatconnect(src/mongo/shell/mongo.js:181:14)4at(connect):1:6atsrc/mongo/shell/mongo.js:181exception:connectfailedtelnetQ:连接实例示鉴权失败？$mongo--host:3717--authenticationDatabaseadmin-urootat(auth):7:2atsrc/mongo/shell/2.连接的用户跟数据库不匹配，比如root用户是admin数$mongo--host:3717atshellHelper.show(src/mongo/shell/utils.js:630:33)atshellHelper(src/mongo/shell/utils.js:524:36)at(shellhelp2):1:1atsrc/mongo/shell/mongo.js:47$mongo--host:3717--authenticationDatabaseadmin-usmg-100101/:3717,dds-uf69:3717--authenticationDatabase故障等都有可能导致主备切换，在生产环境应该使用副本集的方式来正确连接MongoDB来实现高可用。$mongo--host:3717failed连接数问题8."intern{{},Q:生产环境连接数快满了，如何限制每个ECS到实例的连接数量？3.正在跑一些计算量很大的mapreduce仍然无法决问云数据库MongoDBFAQ应的MongoDB里面会有ACIDfunctiongetCollectionDiskSpaceFragRatio(varres=db.getSiblingDB(dbname).runCommand({});Object.keys(res.indexDetails).forEach(function(key){varsize=res['indexDetails'][key]['block-manager']['filebytesavailableforreuse'];});varsize=res['wiredTiger']['block-maprint("collectionand}}c);getCollectionDiskMongoDB主备切换时机是什么时候？MongoDB主备切换流程是怎样的？2.如果超出ElectionTimeoMongoDB写入一个文档有些步？Modifieddbpages'innodb_status.3249"Logsequencenumber270334432414027 SETSET[GLOBAL]character_set_client=utf8;SET[GLOBAL]character_set_connection=utf8;SET[GLOBAL]character_set_databaseSET[GLOBAL]character_set_resultsSET[GLOBAL]character_set_server效mysql>UPDATEtSETc=CONCAT(becomeassociatedwithaclientconnectionbutforwhichauthenticationoftheclientuserhasnotyetbeendone。意现象分析原因RDSPostgreSQLFAQ你的字段以前定义的时候是不是用了大小写并且在PostgreSQL中如何设置与vacuumf与vacuumfreeze相关的参数主2.vacuum_freeze_table_age3.autovacuum_freeze_max_age可以被简单理解为每个元组两次被freeze之间的XID差值的一个最小值。增大该参数可以避免一些无用的freeze操作，减小该参数可以使得在表必须被强制普通的vacuum使用visibilitymap来快速定位哪些数据页需要被扫描，只会扫描那些脏页，其他的数据页即使其中元组对应的xmin非常旧也不会被扫vacuum_freeze_table_age表示表的年龄大于该值时，会进行aggressive当表的年龄超过vacuum_freeze_table_age则会aggressivevacuum当元组的年龄超过vacuum_freeze_min_age后可以进行freeze为了保证整个数据库的最老最新事务差不能超过vacuum之间的新老事务差不能超过20亿，即两次aggressivevacuum之间表的年龄增长（vacuum_freezvacuum_freeze_min_ag于等于autovacuum_freeze_max_age，则元组对应的表也就是说，在经过autovacuum_freeze_max_age-vacuum值得一提的是，vacuum_freeze_table_age设置的值如果比作用。所以默认的规则，vacuum_freeze_table_age要设置的比autovacuum_freeze_max_age小。但是也不能太小，太小的话会造成频繁的min(vacuum_freeze_table_age,0.95autovacuum_freeze_max_age)。所以官方文档推荐vacuum_freeze_table_age=0.95autovacuum_autovacuum_freeze_max_age和vacuum_freeze_min_age的差但是如果设置autovacuum_freeze_max_age和vacuum_freeze_table_age过占用更多的空间。例如，我们把autovacuum_freeze_max_age设置为最大值/questions/20039856/import-excel-data-into-postgrePostGresql上去,需要做哪些准备呢?目前有没有比较好用地址为/aliyun/rds_dbsync/blob/master/README.md3.使用mysql2postgres改之。我遇到的问题就只有一个，mysql列定义中的zerofill需要手工去6.-v-nt--complete-insert=TRUE--compact--no-create-info--skip-quote-names[dbname老一些版本的pgsql如果不支持批量插入的standard_conforming_str云数据库RedisFAQMongoDB性能问题MongoDB磁盘IO高问题阿里云数据库MongoDB的IOPS使用率/document_detail/57141.html通过点击"监控信息"可以查看到当前的IOPS使用量，因为绝大部分情况下阿量=data_iops=log_iops。通过db.serverStatus().systemInfo命令可以查看IO相关的其他指标监控，不厂商负责，用户只需要核心关注业务的正确使用MongoD您可以通过mongostat或者阿里云数据库自治服务DAS实时查看当前的cachedirty，目前阿里云数据库MongoDB暂不支持cachedirty历史情况查看。如果/v4.2/reference/program/mongostat//manual/core/journaling//manual/reference/write-concern/一般很难事先预估热数据与CacheSize的实例费用的一个折衷。通用经验下，我们建议在MongoDB实例在日常态运行必然很大。另一方面，过多累赘的Index创建也会产生更多的数据规模，导致WiredTigerCache只能缓存更小的热数据，业务数据写操作过程中也同样多一于这部分内容，可以参考：/manual/indexes/5业务架构和运维优化5.1控制并发写入/取线数MongoDB是多线程应用，但是我们并不推荐"极致压榨"MongoDB实例本身的通过数据的水平拆分来线性扩容MongoDB的写5.2尽可能免峰值写入部分业务，比如日志系统的定期写入或者游戏系统中用户信息的批量持久化，容易造成一个一个IOPS峰值。针对这种情况，在当前的实例配置不足以支撑5.3免业务高峰期间做运维作一些对性能影响较大的运维操作本质上也是认为造成了IOPS峰值，在无法避免的情况下，应该尽可能避免在业务高峰期执行。常见的容易引起IO高峰的MongoDB空间使用问题概述1看空间使用在MongoDB控制台的“基本信息”页中会显示实例的总1.3监控分析实例的角色。可以通过点击"监控信息"，选择对应的角色查看M其中一个MongoDB物理节点的空间使用由两大块组成，分别为data_size和log_size,其中这里的data_size是数据磁盘使用空间(不包括local库)，主要包ins_size=data_size+log_sizedb.stats()，db.$collection_name.stats()以外，我们推荐使用阿里云MongoDB/document_detail/162422.htmll/manual/reference/method/l/manual/reference/method/db.collection.stats/l/manual/reference/method/db.collel/manual/reference/method/db.collectl/manual/reference/method/db.collection.totalS2分片群间使用率的概念。所以控制台不再提供"基本信息"中的空间使用率。2.1监控分析configserver节点不会成为空间瓶颈，建议选择忽略，直接查看各个sha2.2详分析分片集群的空间使用的详细查看方法与副本集模式略有不同，需要逐个登录各个shard通过命令查看，在每个分片上的空间使用情况详情就与副本集情况完本文后续章节会重点带您了解和深入分析“不同分片下空间使用不均衡”，“同一2.确认引起空间增长的主要源头，比如是日志3.确认当前的增长是否符合预期，针对不符合预期的大量写入场景做应用分4.确认当前的数据是否存在大量碎片，能否通过回收碎片的方式回收空间。5.确认是否需要做磁盘空间扩容，或者部署定时历史数据删除或TTLIndex。6.历史数据大量删除完成，通过compact或者重做副本集的方式回收碎片空db.runCommand({compact:"collectionName"})。l/manual/reference/commal/document_detail/96530.html如前文所述，在大量remove的场景下我们会需要使用compac间。然而在极端场景下，compact操作虽然提示成功了，但实际上磁盘空间并并不是只要存在碎片就一定能回收成功。compact的基本原理并不是立马开辟新的空间存放数据来替换原来的文件，而是将数据不断地往前面的空间空洞挪在大量删除数据后，compact无法回收索引文件，只对数据文件生效。这个可以通过使用命令db.$table_name.stats().indexSizes或者直接查看索引物理文src/mongo/util/processinfo_linux.cpp74'Location13538:coufull-timediagnostic以将内核版本升级到4.0以上，或者可以通过重启mongod进程临时解体的bug链接参考：/browse/WT-408340现主备延迟的情况下，实际oplog可以使用的大小不再受限于配置文件定义的固定集合大小，理论上可以达到用户申请磁盘容量的20%。这就造成了另外,处于备份和恢复效率的考虑,阿里云MongoDB使用物理备份的方式在Hidden备份mongodb实例,期间会涉及到大量的chepoint导致占用了更多的数据和日志空间。针对以上场景，当空间占用量不是特别大的话通常建议直接忽略即可。也可以uselocaldb.runcommand((compact:"oplog.rs",force:true})4不同分片之间的空间使用不均衡4.1shardingkey类型选彝不合疆在一个分片集群中，片键类型的选择至关重要，一般会使用hash分片或者会比ranged好很多，因为根据不同的key值，MongoDB通过内部的哈希41的一个现象：新插入的数据在一个热点的chun的数据写入chunkC所在分片，当chunkC写满以后会在本分片中split出新的chunk，后续通过集群负载均衡器Balan费大量的时间和IO,在一个高并发写入的场景下，数据的负载均衡速度可能跟42l/manual/core/sharding-shard-key/l/manual/core/hashed-sharding/l/manual/core/ranged-sharding/4.2shardingkey字段选择不合理通过sh.status()可以看到各个分片上的chunk数量基本一致，但实际上绝大部分数据都只存在部分chunk上，导致这些热点chunk2019-08-27T13:31:22.076+0800W2019-08-27T13:31:22.076+0800WSHARDING[conn12682019-08-27T13:31:22.076+0800WSHARDING[conn12682019-08-27T13:31:22.076+0800WSHmongos负载均衡主要考虑的是各个际数据严重倾斜。因为一个chunk内shardKey几乎完全相同但又触发到64M的chunk分裂阈值，这时就会分裂出一个空的chunk。久而久之，虽然chunk的数量变多了并且完成了chunk的迁移，但实际上迁移走的chunk都是空的在迁移chunk时基于代价的考虑，认为空chunk迁移代价更低，空的chunk迁移)43l/manual/core/sharding-data-partitioning/l/manual/tutorial/split-chunks-in-sharded-cluster/MongoDB分片集群允许部分db做sharding，部分然会带来这样的一个问题：不做shading的db的数据必然只能存在一个分片mongos集群导入到一个新的mongos集群，而逻辑导入过程中444.4大规的movechunk作可能引起分片的磁蜜占用不均movechunk的本质是向目标端shard写入数据后remove源端数据。默认情况行一段时间后才做了Sharding。从原理上说movechunk引起的空间碎片和大规模delete一样，因此针对出现大量movechunk或者remove文档的情况，可以针对该分片进行compact操作来回收碎片空间，正常情况下compact后数据会进行重组进而回收文件的碎l/manual/tutorial/migrate-chunks-in-sharded-cll/manual/tutorial/manage-sharded-cluster-bala或副本集模式下的节点数据量超过3T就必须业务拆分或者升级至分片集群，45阿里云MongoDB在副本集部署模式下即将支持云盘以实现计算存储分离。在云盘存储下，单个节点的数据存储上限将达到数十T，以及云原生架构基本上不会再有备库延迟问题，所以阿里云MongoDB内核层面不再对oplog做定制化改造，与官方的"固定集合"形态保持一致，备库延迟引起的oplog放当故障发生时可绕过耗时的OSS物理备份下载，46MongoDB内存高问题概述要引起用户足够的关注，因为它往往是业务侧的变动引起，突发的内存飙升容到内存，其作为一个DBMS，还需要负责客户端元数据、存储引擎等很多工作，这些工作都涉"Wiredtiger存储引擎"与"客户端连接及请求的处理"。本文将由浅入深帮您查看、分析和优化云数据库MongoDB的内存使用。471.1监控分析保持一致；"bytes_read_into_cache"表示每秒从磁盘将数据加载到内存的大48//virtual表示该mongo的内存使用使用详情，可以通过的db.serverStatus().wiredTiger.cdb.serverStatus().tcmalloc进行查看，/manual/reference/command/serverStatus/是其中最大的一部分，引擎内存最大使用内存由配置参数cachesize决定。为了兼容性能和安全性，阿里云数据库MongoDB为cachesize设置的大小默认为申请内存的60%左右，由于存在向上取cacheSizeGB4911dds.mongo.standard25dds.mongo.2xmonopolize避免内存使用满了阻塞用户请求，这个过程称为"eviction"。默认值eviction_targeteviction_triggereviction_dirty_target5eviction_dirty_triggereviction_dirty_trigger,dirty>=20%，并一直持续，说明内存淘汰压力很大，用户的请求线程会阻塞参您可以通过mongostat或者阿里云数据库自治服务DAS实时查看当前的/v4.2/reference/program/mongostat/tcmalloc优先会还到自己的cache里；然后逐步再归还给操作系统。所以关于tcmalloc未归还OS的内存大小，可tcmalloccache大小=pageheap_free_bytes+tota/archives/34751数量很多，这一块占用的内存也不容忽视。尤其在MongoDB4.0以前全量逻辑备份期间可能打开非常多的文件句柄并且未能及时归还OS导致内存快速上涨，或者低版本的MongoDB在大量删除c/browse/WT-4336正常的业务数据写入情况下，Secondary会维持一个最大约256M的buffer用Secondary并行回放createinl/manual/core/index-creation/#index-build-impact-on-database-perfol/manual/core/index-creation/#index-build-procdb.serverStatus().metrics.query.planCacheTotalSizeEstim首先需要强调一点，内存优化并非是为了尽可能减少内存使用，而是统性能完全没问题的前提下，内存使用尽可能稳定和够用，从而在机器资源和排错实战RDSMySQL活跃线程数高问题table_open_cache_instances（需要重启）参数。前正在执行的DDL都可以解决。2.4行锁冲突行锁冲突导致的活跃线程数的表现是Innodb_row_lock_waits和也可以通过执行showengineinnodbstatus查看RDSMySQL慢SQL问题概述最好的情况是自顶向下了解业务，以及每个业务涉及的SQL，这样就能厘清业前言判断查询的性能就是看查询执行的时间，这个时间针对不同的业务要求上也有就越多。同样一个业务场景不同的架构设计、数据库表索引设计，由不同的人高的性能。最好的情况是自顶向下了解业务，以就能厘清业务和数据库负载的关系；也能找到短板，并对短板做有针对性的优细请参考文档/product/xtrace。全链路监控和全链路压下面针对数据库的各种导致SQL慢的排查思路，原因和解决方法进行阐述：如果监控比较细微或对响应时间比较敏感的话，/document_detail/95667.html。如果资源使用利用率各考/document_detail/96061.html。方链接/doc/refman/5.6/en/explain-output.html#explain-池耗尽，影响整个业务。查看近期有没有修改过参数的控制台路径是选择“云数/documen参数buffer_pool_instances/join_buffer_size/AHI等的变化也会导致性能变慢。关于这方面的文章比较多，这里不一一赘述。查看近期有没有修改过参数的控/documen2存失效缓存的设计在架构上很好地承担了大量的查询，但并不能保证缓存命中率常高。这样的情况RDSMySQL可以用SQL限流、打开线程池、语句并行队/docu参考/document_detail/164859.html。这种情况可以从磁盘空间，或SQL洞察/慢查询里找到对应语句。如从binlog拖数这种情况可以通过监控指标的变化或SQL洞察/慢查询里找到对应语句。2.4未关闭的事务如果某个任务突然变慢，应该考虑是否有锁阻塞的问题。可以通过“如何定位长如果负载随时间有规律性变化，则瓶颈随负3SQL异常影响SQL语句执行的因素大概分为以下几类库引擎特性、查询条件的区分度、结果集大小、表的数据量、CPU时间。3.1业务场发生改变应用有没有进行过发布，需要看下应用的部署日志或发布系的方法参考文档/document_detail/96123.html。同时段的SQL可以跟昨天同时间对比，或上周同时间对比。借助SQ/document_detail/99478.html。3.2扫描行数多这种情况可以通过监控指标的变化或SQL洞察/慢查询里找到对应语句。3.4囊引不合建议分批执行或放在业务低峰期执行，当然了尽量带上WHERE条件。如下图7监控指标择“云数据库RDS”->选择“实例列表”->点击实例链接，进入实例页面->选择“监控与报警”->选择“资源监控”/“引擎监控InnoDB缓存读命InnoDB缓冲池的读命中率、使用率以及缓MySQL执行语句BufferL每秒从InnoDB表读取、更新、删除、插入的行数因为上面已经有路径或帮助文档，这里不再赘述。在实际业务场景会比上面提到的情况复杂的多，有可能是多种情况的巡检维护RDSMySQL巡检到底巡检什么作者tplinux作系统巡检如果没有zabbix建议使用sar这个小工[root@mongodb01data]#sar-u103Linux2.6.32-642.el6.x86_64(mongodb01)09/22/2017_x86_64_(8CPU)10:26:44AMCPU%user%nice%system%iowait%steal%idle10:26:54AMall0.550.000.415.610.0393.40[root@mongodb01data]#sar-r103Linux2.6.32-642.el6.x86_64(mongodb01)09/22/2017_x86_64_(8CPU)10:28:36AMkbmemfreekbmemused%memusedkbbufferskbcachedkbcommit%commit10:28:46AM2230843265825299.32143468165490801877406837.81[root@mongodb01data]#sar-b103Linux2.6.32-642.el6.x86_64(mongodb01)09/22/2017_x86_64_(8CPU)10:30:25AMtpsrtpswtpsbread/sbwrtn/s10:30:35AM67.1761.635.5416169.9986.20```1.4系统交换活动信息监控[root@mongodb01data]#sar-w103Linux2.6.32-642.el6.x86_64(mongodb01)09/22/2017x86_6410:31:56AMproc/scswch/s10:32:06AM0.002234.44`[root@mongodb01data]#ll/var/log/messages[root@mongodb01data]#ll/var/log/dmesgMySQLerrorlogMySQL慢查询日志等信息"innodb_buffer_pool_size""sync_binlog"'binlog_format''innodb_flush_log_at_trx_commit':'read_only':'log_slave_updates''innodb_io_capacity''query_cache_type''query_cache_size''max_connections''max_connect_errors''server_id'showfullprocesslistshowglobalstatusshowengineinnodbstatus\Gtaill-fshow.logwait等待Innodb_buffer_pool_wait_free80Innodb_log_waits锁等待Innodb_row_lock_current_waits当前等待的待锁定的行数Innodb_row_lock_waits一行锁定必须等待的总时长Table_locks_waited表锁等待次数mysql锁监控表级锁Table_locks_waitedTable_locks_immediate行级锁Innodb_row_lock_current_waits当前等待锁的行锁数量Innodb_row_lock_time请求行锁总耗时Innodb_row_lock_time_avg请求行锁平均耗时Innodb_row_lock_time_max请求行锁最久耗时Innodb_row_lock_waits行锁发生次数等待事件Innodb_buffer_pool_wait_free/Innodb_log_waits临时表/临时文件Created_tmp_disk_tables/Created_tmp_files打开表/文件数Open_files/Open_table_definitions/Open_tables并发连接数Threads_running/Threads_created/Threads_cached81Aborted_clients客户端没有正确关闭连接导致客户端终止而中断的连接数Aborted_connects试图连接到mysql服务器而失败的连接数BinlogBinlog_cache_disk_use使用临时二进制日志缓冲但超过binlog_cache_size值并使用临时文件Binlog_cache_use使用临时二进制日志缓冲的事务数量Binlog_stmt_cache_disk_use当非事务语句使用二进制日志缓存Binlog_stmt_cache_use使用二进制日志缓冲非事务语句数量链接数Connections试图连接到（不管成不成功）mysql服务器的链接数临时表Created_tmp_disk_tables服务器执行语句时在硬盘上自动创建的临时表的数量。是指在排序时，内存不够用(tmp_table_size小于需要排序的结果集)，所以需要创建基于磁盘的临时表进行排序Created_tmp_files服务器执行语句时自动创建的内存中的临时表的数量索引Handler_commit内部交语句Handler_rollback内部rollback语句数量Handler_read_first索引第一条记录被读的次数如果高它表明服务器正执行大量全索引扫描82Handler_read_key根据索引读一行的请求数如果较高说明查询和表的索引正确Handler_read_last查询读索引最后一个索引键请求数Handler_read_next按照索引顺序读下一行的请求数Handler_read_prev按照索引顺序读前一行的请求数Handler_read_rnd根据固定位置读一行的请求数如果值较高说明可能使用了大量需要mysql扫整个表的查询或没有正确使用索引Handler_read_rnd_next在数据文件中读下一行的请求数如果你正进行大量的表扫该值会较高innodbInnodb_buffer_pool_wait_free一般情况通过后台想innodbbufferpool写Innodb_log_waits日志缓冲区太小我们在继续前必须先等待对它的清空Innodb_row_lock_current_waits当前等待锁的行锁数量Innodb_row_lock_time请求行锁总耗时Innodb_row_lock_time_avg请求行锁平均耗时Innodb_row_lock_time_max请求行锁最久耗时Innodb_row_lock_waits行锁发生次数Open_table_definitions被缓存的.frm文件数量Opened_tables已经打开的表的数量如果较大table_open_cache值可能太小Open_tables当前打开的表的数量Queries已经发送给服务器的查询个数83Select_full_join没有使用索引的联接的数量如果该值不为0你应该仔细检查表的所有Select_scan对第一个表进行完全扫的联接的数量Slow_queries查询时间超过long_query_time秒的查询个数Sort_merge_passes排序算法已经执行的合并的数量如果值较大增加sort_buffer_size大小线程Threads_cached线程缓存内的线程数量Threads_connected当前打开的连接数量Threads_created创建用来处理连接的线程数Threads_running激活的（非睡眠状态）线程数INFORMATION_SCHEMA.INNODB_LOCKS;INFORMATION_SCHEMA.INNODB_LOCK_WAITS;参考一下《老司机带你体验SYS库多种新玩法'SELECTtable_schema,table_name,engine,Auto_incrementFROMinformation_schema.tableswhereINFORMATION_SCHEMA.TABLE_SCHEMAnotin("information_schema","performance_schema","mysql")'84参考一下《老司机带你体验SYS库多种新玩法2.5存储引是否为innodbINFORMATION_SCHEMA.TABLESengine=inn2.6MySQL主从检测2.6.1主从状态2.6.2主从是否延迟Master_Log_File==Relay_Master_Log_File&&Read_Master_Log_Pos==Exec_Master_Log_Pos三高可用巡检3.2中间件的巡检总结本的巡检是避免不了的，如果有其他的巡检姿势也欢迎一起讨论。顺便前几天（因为客户的环境不能直连linux但可以直连MySQL）/enmotplinux/On-Site-Inspection85RDSMySQL运维之小版本升级概述任何软件满足客户的需求都不是一蹴而就的，都是通过版本迭代完善功能和优在以往我们遇到过很多版本升级遇到的问题，所以这篇文章就来聊聊如何少踩升级方法/document_detail/96060.html。86小版本的升级可以用自动升级和手动升级两种：自动升级会在运维时间自动帮/document_detail/96059.html。哪些小版本需要升级？升级需要多长时间？需要原地修改配置就可以，比较快。跨机升级的完整时间取决于实例大小和备升级对应用的影响？87性能问题RDSMySQL实例IO高问题概述存储形态InnoDBAIO实现了一套独立的IO系统来处理数据页的读取和写入，如果SQL882.1高吞吐的写入89innodb_max_dirty_pages_pctinnodb_max_dirty_pages_pct_lwminnodb_io_capacity_max90取的数据量非常大，可能会造成很大的读IO吞吐。缓可以从自治眼务->性趋势看bufferpool命中率：91事务只有在提交时才会写binlog文件，如果存在大事务，比如一条deletesql优化议93RDSMySQL实例空间问题概述实例的空间使用率是RDSMySQL用户日常需要重点关注的监控项之一。如果库备份无法正常完成、存储空间扩容任务的执行耗时可能更长等。一般来说，有当前的空间使用总量，没有具体的各类数据分别占用空间大小的信息，也没1.1.2监控与疆警94的各类数据占用的磁盘空间大小的信息，并且会显示各部分空间大小的历史变其中磁盘空间总体使用量即对应当前实例实际已经使用了的所有存储空间总量，数据空间使用量临时文件空间使用量系统文件空间使用量详细的空间使用情况，包括数据与日志的空间使用对比、空间使用的历史变化95这个列表中的统计，则是针对数据库中的表所使用的数据文件保留大小数据空间索引空间未使用空间需要注意的是上面列表中的空间大小是从统计信息中采集的，和真实的空间大1.2命令行如何查看表空间962.1.2有大字段录位置又没有新的记录插入，就可能造成空间没有被很好的利用。可以通过972.PolarDB采用分布式存储也支持非常大的存储空间，且按需自动扩容。3.RDS创建时选xengine引擎，xengRDSPostgreSQLRDSPostgreSQL实例IO高问题概述982IO高的常见原因2.1SQL扫描行高冲区进行返回，如果数据未在共享缓冲区命中就会需要从磁盘中进行读取，读的IOPS比较高，说明大量的从磁盘读取数据到数据库共享缓冲区中，可能存2.1.2查看引监控2.1.3查看性能洞察99可以找到对应的问题SQL，可以对问题SQL进行索引2.2导入数据2.3.2看引擎监控作行数此时发现操作行数没有明显增加，此时可以怀疑是vacuum或者CheckPointheap_blks_scannedmax_dead_tuples通过pg_stat_user_tables也可以查看历史vacuidx_tup_fetch|last_vacuum||vacuum_countautovacuum_countautoanalyze_countautovacuum_vacuum_cost_delay指的是vacuum动作代价达到autovacuum_vacuum_cost_limit时vacuum进程休息的时间单位是ms。autovacuum_vacuum_cost_limit指的是vacuuCheckPoint指的是将数据库共享缓checkpoint_write_time|9109283buffers_backend_fsync|0DSMySQL内存使用问题概述存使用率过高会有OOM风险，如果bufferpool命中率低，大量的数据页无法到bufferpool配置参数的限制，但是还有很多内存是和调整的，比如内存临时表消耗的内存、prefetchcache、tablec索引、行锁对象等，详细的内存占用和相关参数限制参考MySQL官方文档。updateperformance_schema.setup_instrumentssetenabmemory_summary_by_account_by_event_namememory_summary_by_host_by_event_namememory_summary_by_thread_by_event_namememory_summary_by_user_by_event_namememory_summary_global_by_event_name有这种现象。建议业务实现中尽量避免multiplestatements1.数据页没有足够的预热，导致查询的延迟较高。通常发生在实例发2.脏页累计太多。当当前未刷脏的最老ls会触发用户线程同步刷脏，引发实例严重的性能下降。优化方式是业务均3.大规格内存实例innodb_buffer_pool_instanc内存临时表大小受到tmp_table_s制后将转化为磁盘临时表，如果瞬间有大量的连接创建大量的临时表，有可能建太多表和设置非常大的table_open_cache参数。还有自适应哈希索引占用的内存默认是buffferpoolsize的1/64。如成内存上涨，如果碰见内存使用率异常增加或实例OOM，您可以参考运维实战RDSMySQL高并发场景实战度上升趋势。在这么大访问流量下，所有的核心链路的增删改查都是在数据库近于零》实例和应用机器等，判断能否支撑得住双11的峰值。需要针对上述的预估做一全链路压测是基于场景化的仿真测试,其数据最接近业务的系统值，针对全链路3性能评测3.4.工具3.5.注意事项2)ECS的网络带宽4架构调优4.1.数据库架构调优4.2.降低只读实例和主实例的延迟4）只读节点规格过小5）其他（无主键）4.3.提升缓存命中率应用简单可靠应用更新无额外性能消耗5实例调优5.1.弹性扩容5.2.参数调优6.1.版本升级库存注释语句队列语句返回线程池对于高并发场景，AliSQL使用线程7监控报警务。AliSQL设计了基于语句规则的并发控制，StatementConcurrencyControl,简称CCL。2)本地热Binlog（数据库服务器上运维实战RDSPostgreSQL慢SQL问题概述慢SQL会消耗较多的数据库资源，很容易造成数据库的负载增加，慢SQL的这个命令显示PostgreSQL计划器为提供的语句所生成的执行计划。该执行计划会显示将怎样扫描语句中引用的表—普通的顺序扫描、索引扫描等等—以及在引用多个表时使用何种连接算法来把来自每个输入表的行连接在一起。显示中最重要的部分是估计出的语句执行代价，它是计划器对于该语句要运行多久的猜测（以任意的代价单位度量，但是习惯上表示取磁盘页面的次数）。事实上会显示两个数字：在第一行能被返回前的启动代价，以及返回所有行的总代价。对于大部分查询来说总代价是最重要为执行器将在得到一行后停止）。此外，如果你用一个LIMIT子的数量，计划器会在终端代价之间做出适当的插值来估计到底哪个计划是真正HashCond:(t2.unique2lverbose:显示关于计划的额外信息。特别是：计划树中每个结点的输出列列表、模式限定的表和函数名、总是把表达式中的变量标上它们的范围表别名，以及总是打印统计信息被显示的每个触发器的名称。这个参数默认lbuffers:包括缓冲区使用的信息。特别是：共享块命中、读取、标记为脏和写入的次数、本地块命中、读取、标记为脏和写入的次数、以及临时块读取和写入的次数。一次命中表示避免了一次读取，因为需要的块已经在缓存中找到了。共享块包含着来自于常规表和索引的数据，本地块包含着来自于临时表和索引的数据，而临时块包含着在排序、哈希、物化计划结点和类似情况中使用的短期工作数据。脏块的数量表示被这个查询改变的之前未被修改块的数量，而写入块的数量表示这个后台在查询处理期间从缓存中替换出去的脏块的数量。为一个较高层结点显示的块数包括它的所有ltiming:在输出中包括实际启动时间以及在每个结点中花掉的时间。反复读取系统时钟的负荷在某些系统上会显著地拖慢查询，因这个选项关闭结点层的计时，整个语句的运行时间也总是会被度量。只有lsummary:在查询计划之后包含摘要信息（例如，总计的时间信息）。当使括从缓存中获取计划所需的时间以及重新计划所需的时间输出包含和文本输出格式相同的信息，但是更容易被程序解析。这个参数例如cost、rows、width等。阅读执行计划是查询计划从下往上阅读，每个节点执行返回的结果会传递给父也包含扫描函数结果集、子查询结果等。目前支持的扫描节点如下:引postgres=>explain(ANALYZE是ms。rows代表实际输出行。loops代表节点循环次数。扫描时对每行记录进行过滤操作，过滤条件为classno_index索引对表进行索引扫描的postgres=>explain(ANALYZE,VERBOSE,BUFIndexOnlyScanusingno_indexonpublic.class表明使用public.no_index索引对表进行覆盖索引扫描。HeapFetches表明需要扫描数据块的文件。当新建表之后，如果没有进行过vacuum和autovacuum操作，这时还没有VM文件，而索引并没有保存记录的版本信息，索引Index是需要扫描数据块（HeapFetches代表需要扫描的数据块个数）来获取版本postgres=>explain(AN描位图，位图中每位代表了一个扫描到的数据块，通过位图可以定位到一些通过计划可以看出是全表扫描的t1表，过滤条件是可以看出时间从2.6ms降低至0.157msRDSPostgreSQLCPU高问题概述SQLServer实例的CPU使用率持续较高时，很容易导致数据库访问卡慢的情资监控CPU基本念符合条件的活动的时钟周期，比如停滞等待IO而导致较高的使用率，CPUCPU高的常见因扫行高通过创建合适索引可以极大程度的降低SQL的响应时间以及降低CPU资源的活跃会话高明数据库资源已远超目前能提供服务的负载。一般合理的活跃会话数量是当前RDSPostgreSQL实例IO高问题2.1SQL扫描行高2.1.2查看引擎监控2.1.3查看性能洞察可以找到对应的问题SQL，可以对问题SQL进行索引3导入数据3.1查看资源监控的数据盘IOPS4Vacuum操作此时发现操作行数没有明显增加，此时可以怀疑是vacuum或者CheckPointheap_blks_scanned通过pg_stat_user_tables也可以查看历史vacuseq_tup_readlast_vacuum||||vacuum_count1autovacuum_count|0autovacuum_vacuum_cost_delay指的是vacuum动作代价达到autovacuum_vacuum_cost_limit时vacuum进程休息的时间单位是ms。autovacuum_vacuum_cost_limit指的是vacuuCheckPoint指的是将数据库共享缓checkpoint_write_timeRDSPostgreSQL监控实战基于Pigsty解决实际监控问题1为什么需要监控系统离开监控系统管理数据库就像蒙眼开车，我们通过利用监控系统实现对数据库1.1实验1：利用监控系统观测查询负载1）使用正常连接数负载，观察系统状态whiletrue;dopgbench-nv-P1-c4--select-only--rate=1000-T10postgres://test:test@pg-test:5434/test;dowhiletrue;dopgbench-nv-P1-cpostgres://test:test@pg-test:5434/test;done如上图所示，我们可以看到整个集群的GPS数据，主库上的TPS差不多是50接下来我们稍微改动一下，施加同样的负载，但使用十倍的连接数量，原来我们使用了2条读写连接，4条只读连接，现在翻十倍变为20条和40条，观察whiletrue;dopgbench-nv-P1-c40--selectpostgres://test:test@pg-test:5434/test;dopostgres://test:test@pg-test:5433/test;do其中的ActiveClientsbyInstance是按照实例划分的连接数。如上图所示，通过最近5分钟的情况可以看到，之前使用的是6条连接，2主2从2从，现在postgres://test:test@pg-test:5433/test;do命令二：whiletrue;dpostgres://test:test@pg-test:5434/test;done如上图所示，我们回到主页可以看到，监控面板目前的负载水平已经超过表。当我们将负载定量重新调低后，整个系统的负载以上实验反映了监控系统的基本功能，它能够如实地反映用户给集群施加的负1.2实验二：重启主库，观察集群领导权交接我们通常所说的高可用，指的是当一个系统的主库宕机时，应该有一个从库自动被提升出来接管系统。如果没有监控系统的话，这个操作对我们而言是一个比如我们登录到第一台主库所在的机器上，然后执行ssh-tnode-1sudoreboot，可以看到负载都开始报错。但在短短数秒内，无论是读流量还是写流如上图所示，我们可以看到监控系统中原本的主库pg-test1已经被踢掉了，pg-test2被提升成新的主库了，开始承接写流量。当pg-test1重启完成之后，通过以上两个实验可以看出，监控系统对于反应系统状态来说，是一个非常实2用监控系统解决一些实际问题2.1用监控系统解决问题2.1.1.黄金监控指标数据库负值和饱和度是最重要的指标。按照GoogleSRE的监控最佳实践，这些指标可以分为4大类，饱和度、延迟、流量和错误，都具有很重要的2.1.2.PGLoad衡量数据库的负载程度PG的负载是不是也可以采用类似于CPU利用率和机器负载的方式来定义？当然可以，而且这是一个极棒的主意。让我们先来考虑单进程情况下的PG负载，假设我们需要这样一个指标，当该PG进程完全空闲时负载因子为0，当该进程处于满载状态时负载为1(100%）。类比CPU利用率的定义，我们可以使用“单个PG进程处于活跃状态的时长占比”来表示单个PG后端进程的利用率。如上图所示，在一秒的统计周期内，PG处于活跃（执行查询或者执行事务）状态的时长为0.6秒，那么这一秒内的PG负载就是60％。如果这个统计周期中都处于忙碌状态，而且还有0.4秒的任务在排队，如那么就可以认为对于并行场景，计算方法与多核CPU的利用率类似，首先把所有PG进程在统计周期（1S）内处于活跃状态的时长累加，然后除以“可用的PG进程／连接数”，或者说“可用并行数”，即可得到PG本身的利用率指标，如上图所示。两个PG后端进程分别有20Oms+400ms与80Oms的活跃时长，那么整体的负载水平为：(0.2S+0.4S+0.8S)/1S/2=70%总结一下，某一段时间PG的负载可以定义为：pg_load=pg_active_seconds/time_eroid/parallellpg_active_seconds是该时间段内所有PG进程处于活跃状态的时长之和。ltime_peroid是负载计算的统计周期，通常为1分钟，5分钟，15分钟，以及因为前两项之商实际上就是一段时间内的每秒活跃时长总数，因此这个公式进一步可以简化为活跃时长对时间的导数除以可用并行数，即：程活跃总时长pg_active_seconds这个指标，以及如何评估计算数据库可用并行2.1.3.黄金指标：数据库饱和度饱和度用于反映数据库整体资源利用率理论上应当取所有饱和度指标的最大值-record:pg:ins:saturation0expr:pg:in-record:pg:ins:saturation1expr:pg:in-record:pg:ins:saturation5expr:pg:ins:load5>nod2.2查询定位优化2.2.1.什么是慢查询？ALTERTABLEpgbench_accountsDROPCONSTRAINT2.2.2.定位慢查询定位集群RT异常，定位到具体的实例和查询。首先，使用PGCluster面板定位慢查询所在的具体实例，这里以pg-test2为例，然位具体的慢查询：编号为-6041100154778468427下降到7，花费在该查询上的时间占比显著增加，可以确定就是这个查询变慢2.2.3.发现异常查询以aid作为过滤条件查询pgbench_accounts表查询变慢，大概率是这张2.2.4.性优化我们尝试在pgbench_accounts表上为aid列添加索引，看看能否解决这个问可以看到，查询的响应时间与QPS已经恢复正常，整个集群的负载水平也恢复正常，报警也平息下来。精准衡量优化效果，直观展示工作成绩，真正做到2.3定位系统故人工时时盯着指标，是一个非常辛苦的活，更好的选择是由机器来盯着这些指标，您设定好规则，机器发现这些指标超出异常范围的送报警，Pigsty里面提供了一系列的报警规则，同时报警事件也可以在监控系统的面板里面看到，通过这种条状甘特图的方式，我们可以看到哪一个时间段触发了报警事件，从而有的放矢的去排查。报警系统提供了很多计算好的衍生2.4系统水位评估2.4.1.水位评估：饱和度的历史分位点除了直观的衡量实时的数据库负载水平，还可以用来计算数据库的水位，水位就是一个长期的资源使用量指标，通常来说，如果我们的某一个数据库集群长时间处于高负载状态，我们就是说它水位比较高，我们可能就要给它扩容。如扩容和缩容的依据就是所谓的水位，水位就是过去某一个时间段饱和度的百分位点。比如说现在采用的就是过去一天里面水位的99分位点，对于那种有周期性的负载来说，一天是一个比较好的这种衡量指标，如果您的业务周期性是点或者99.99分位点，来评估集群的水位。比如这里某一套集群，它的水位系统的资源利用率很有用。评估资源利用率，就可以评估成本，及时的进行优参考文档：http://pigsty.cc3.2公开文档与演示本教程着眼于在本地单机创建Pigsty演示环境，如果您已经有可以用于部署的机器实例，可以参考部教。如果用户的本地计算机上已经安装有Vagrant、Virtualbox与Ansibl正常情况下执行结果详见参考-标准流。3.3快速上手gitclone/Vonng/pigsty性能问题RedisCPU高问题概述用率显得尤为重要。当实例的CPU打满时会导致数据库响应缓慢，严重影响看数据节点是否出现CPU瓶颈，然后查阅"Proxy节点2CPU使用率高的一般排查步骤2.1确认是否存在流量突增/热点Keyl/document_detail/100453.htmll/document_detail/188013.html但需要注意的，这里提供的结果仅仅作为基力上限要以实际的业务压测为准，当业务代码没有任何变动的情况下CPU突增，建议您结合监控图先观察当前Redis实例的各项QPS指标是否同样存在l/document_detail/160585.htmll/document_detail/181195.html路一般有以下几种，本质上就是通过多线程或者架构升级的方式解决：在读写分离添加只读实例，或者使用多分片我们做一下简单对比，比如阿里云Redis社区标准版能够承载的QPS为K(社Redis社区版集群Redis社区版读写分离Redis企业版-性能增强型主备Redis企业版-性能增强型集群Redis企业版-性能增强型读写分离写(key均匀情况)K*分片数KK*3*分片数读(keyK*分片K*只读K*3*分片数K*3*只读节均匀情况)数节点数点写(热K(最坏情况)K读(热K(最坏情况)K*只读节点数K*3*只读节点2.2认是否存在慢询慢查询队列以供查看。查询执行时间指的是不包括像客户端响应(talking)、发送回复等IO操作，而单单是执行一个查询命令所耗费的时间，您可以通过控制台提供的参数slowlog-log-slower-than和slowlog-max-lel/document_detail/164435.html通常Redis指令消耗的CPU与指令的时间复杂以上的复杂度在业务代码设计时需要谨慎对待它对应的流量评估。具体每个控制台CloudDBA提供有"缓存分析"找出实例中的存在性能隐患的大Key，详情可参考：/document_detail/102093.html2.3确认是否存在流量不均在使用读写分离/集群架构模式下，当集群出现响应延迟时，首群下所有对外提供服务的物理节点均出现HighCPU，限流，还是部分节点出除了上述提到的bigkey和热点key容易引起的集群还有几种情况可能导致读写分离架构下的各个主节点，只读节点之间的流量不lscan系列命令由于存在上下文关系，需要将该类命令全部转发至第一个只leval和evalsha命令，可以通过readonl制其分发向只读节点（读写分离版）从而降低mas3通用最佳实践可参考：/document_detail/146758.html。/document_detail/107695.html。l节点宕机导致的全量同步，期间存在部分对外服务节可能比slave高很多，因为master向slave传输数据时可能做了合并，类l高频建连操作可能消耗更多的CPU，因为连接的建立和释放均会消耗一定l在连接数较多的情况下频繁调用info指令查看各项监控信息可能导致CPU使用率更高，因为部分info子命令的监控信息统计需要遍历每一个client连接，所以当连接数超过5k的情况下建议https://redis.io/commands/bgrewriteaof。Redis内存高问题概述作为内存型数据库，阿里云数据库Redis的内存使用率是一个非常重要的监控指标，当实例内存不足时会导致数据库响应缓慢，甚至导致写入错误等不利影以将其配置为在达到最大内存限制时采用key逐出的方式以保证Redis的正常运行，但应当注意Redis的淘汰是同步进行的，触发淘汰后会命令处理时延（因为需要逐出可用内存后才部署架构为主备模式下，只提供当前主节点的内存使用。通过监控图查看内存例，且可能通过多个Proxy节点做路由转发和负载均衡，通过监控图查看内存通过阿里云控制台提供的监控图可以大概确认当前实例的内存使用情况，在大部分场景下，绝大部分的内存均为实际的数据存储需求，当观察到内存超过一定阈值后扩容即可。然而在一些特定场景下，我们可能认为Redis的内存使用Redis官方提供有infomemory4)"MEMORYP