今天MySQL存储节点突然收到cpu持续100%的报警，持续时间长达数个小时。在控制台中通过show processlist查看当前进程，发现很多一模一样的SQL一直在运行，执行时间都超过数个小时。
超时时间俗称 Timeout 它是引起应用程序无响应或者网络服务雪崩灾难的罪魁祸首。
最近发现之前部署在阿里云的一个web项目，每过一段时间就会报错，但是刷新下页面就会显示正常；在过了比较长的一段时间后，又会报同样的错误，如下：
进入 MySQL 命令行后，长时间连接 MySQL 服务但未进行操作，MySQL服务自动断开，再次执行操作时出现以下提示
可以看到slow_query_log的值是OFF，也就是mysql默认是不启用慢查询日志的。
其实对这种和数据库交互的应用，现在的程序中，大多都用了数据库连接池，无论用的开源，还是自研的，无非都是想通过连接池，更方便、更高效地和数据库交互，因此一定程度上，连接池的正确使用会关系到应用和数据库交互的质量。一 前言
应用执行SQL请求完成的过程中，数据库连接占很重要一部分。尤其是涉及到流量瞬间暴涨，需要创建大量连接，或者网络异常导致重连时，从业务端来看，sql执行缓慢的问题，此时sql执行并非真的慢。本文是基于我们自己的生产环境的Durid最佳实践，仅供各位参考，当然不同公司的链路/业务压力可能不一样。具体到个别参数需要区别对待。
断路器（Circuit Breaker）就像保险丝，在电路系统中，一般在所有的家电系统连接外部供电的线路中间都会加一个保险丝，当外部电压过高，达到保险丝的熔点时，保险丝就会被熔断，从而可以切断家电系统与外部电路的联通，进而保障家电系统不会因为电压过高而损坏。
最近，IMG 的姜老师发布了一篇关于使用 gh-ost 会丢数据的文章（gh-ost 翻车！使用后导致数据丢失！），大致结论就是：在 MySQL AFTER_SYNC的 场景下，使用 gh-ost 进行表结构变更（包括最新 GA 的1.1.2版本在内），可能会导致数据丢失，还引起大家在微信群内展开了一些讨论。得知这个消息，还是觉得有些意外的，毕竟对于大部分 DBA 来说，gh-ost 属于比较常用的 DDL 工具，会用其替代 pt-osc 或 MySQL 自带的 online ddl 。出于好奇，去 gh-ost 的 Gtihub 主页上看了下，还真有相关的 issue ，并且已经有人提交了 fix 的 PR （目前该 fix 尚未得到官方回应）
一般情况下，当用户登录一个站点后，如果长时间没有任何动作，当用户再次单击时，会被强制登出并跳转到登录页面，提醒用户重新登录。
Hive配置了Spark作为默认执行引擎，在通过Hue执行Hive查询后，退出Hue后Spark的Session并为随着Hue的退出而关闭，操作如下：
在生产环境处理故障的过程出现了java服务连接mysql，由于连接数太多被拒绝连接的故障，那么下面来看看怎么优化一下吧。
今天来聊一聊前段时间看到的一个面试题，也是在实际项目中需要考虑的一个问题，Feign的超时时间如何设置？
本文讲述了在使用Nginx+Lua+MySQL实现高并发请求时，遇到的“消失的记录”问题。通过分析问题原因，发现原来是Nginx+Lua环境下，使用阻塞的HTTP请求库导致连接池被污染，进而引发事务问题。最终通过采用非阻塞的HTTP请求库，解决了问题，但修改量较大，需要一定时间来完成。
相信不少朋友都在自己公司使用Spring Cloud框架来构建微服务架构，毕竟现在这是非常火的一门技术。
Mysql占用CPU过高的时候，该从哪些方面下手进行优化？ 占用CPU过高，可以做如下考虑： 1）一般来讲，排除高并发的因素，还是要找到导致你CPU过高的哪几条在执行的SQL，show processlist语句，查找负荷最重的SQL语句，优化该SQL，比如适当建立某字段的索引； 2）打开慢查询日志，将那些执行时间过长且占用资源过多的SQL拿来进行explain分析，导致CPU过高，多数是GroupBy、OrderBy排序问题所导致，然后慢慢进行优化改进。比如优化insert语句、优化group by语句、
最近利用 MHA 做好 Mysql 读写分离后，时不时有用户反馈后台发布文章时，报程序“通用异常"，经问题排查，里面涉及应用JDBC连接池参数及Mysql参数调整问题。
一开始以为是服务本身导致的问题，但是最近一个礼拜都没有提交记录，所以应该不是因为异常提交导致的，只能先重启服务，看看能不能恢复过来。但是重启服务之后还是报类似的错误，而且不只一个服务报错，所以可以确定应该是mq本身的问题。
有部分使用ApiPost的同学反应：发送接口调试时，响应超时时间设置的太短导致接口访问失败，怎么设置呢？
socket.setdefaulttimeout() 方法用于设置全局socket超时连接时间。 settimeout()方法用于设置全局socket超时连接时间。
“锁”是我们实际工作和面试中无法避开的话题之一，正确使用锁可以保证高并发环境下程序的正确执行，也就是说只有使用锁才能保证多人同时访问时程序不会出现问题。
今年是我的第6个618，因为入职的时间比较"合适"，使得我经历了每年两次完整的大促备战。那年还在北辰，618的当晚，我记忆的很清晰，接近凌晨1点左右的时候，我们聚集在楼道里面，大家举杯相庆，来祝贺刚刚平稳度过的大促。从此这样的场景在每年的这个时候都会经历一次，激动一次。每一次大促备战都是一场全兵演练，我们在这个战斗过程中，团队合作、技术实战、用户意识上都有一个立体的提升。站在每年的这一刻往前看，一路走过来的却是好些个不平凡的白天和夜晚。正如我们国家的乒乓球队在每次国际比赛中都有一个完美的结局，但过程从来不缺乏紧张、风险和刺激。
现代网站架构/业务架构越来越重视横向拓展的能力，随之而来的是 Server 或者容器的数量快速增长，但是传统 RDBMS 的扩展性无法跟上这种步伐，导致大量的数据库连接不断的在数据库端创建、断开，不仅性能方面受到影响，在个别极端情况下也会导致数据库本身出现卡死等影响业务的现象。
connect timeout和socket timeout都属于TCP层面的超时。
MySQL Router是MySQL官方提供的一个轻量级MySQL中间件，用于取代以前老版本的SQL proxy。
在写入由 GetRequestStream 方法返回的流时，或在读取由 GetResponseStream 方法返回的流时，会用到 ReadWriteTimeout 属性，ReadWriteTimeout 属性控制 Read 方法（用来读取由 GetResponseStream 方法返回的流）和 Write 方法（用来写入由 GetRequestStream 方法返回的流），HttpURLConnection里面有个setReadTimeout方法，我们把这个函数的超时时间设置久一点就ok
zuul的一些默认设置如果我们不调整下，那么对整体的服务的性能还是有很大影响的，比如如果网关调用的服务处理时间比较长，那么就会出现timeout异常。
背景 2017年8月25日，我怀着“再也不要在下班时间收到报警”的美好期待，加入美团金融智能支付负责核心交易，结果入职后收到的报警一天紧似一天。核心交易是整个智能支付的核心链路，承担着智能支付百分之百的流量，不敢有丝毫的懈怠。 从17年下半年开始，我们的日单量增长迅速，而且压力和流量在午、晚高峰时段非常集中。在这种情况下，报警和小事故日益频繁，交易的稳定性面临着严峻的考验。下面是早期的可用性趋势图，仔细看的话，可以看到可用性有下降的趋势，旁边的总可用性显示只有4个9（99.998765%），美团点评排在
eg : 事务 A 更新了一行，而这时候事务 B 也要更新同一行，则必须等事务 A 的操作完成后才能进行更新
针对上面第一种情况，很容易从字面意义就得出是读取超时。然而查询资料 JDBC 存在多种 timeout,仔细研究了一下，梳理一下。
事情是这样子的，由于公司要推行降本增效，尽量使得服务器能满负载的去工作，我负责的项目由于对数据库的使用比较轻度，所以就降低配置去使用。而一个新的需求，需要稍微复杂一点的业务逻辑，所以需要对数据库增加一个字段，且增加一个索引，也就是做一点DDL语句的操作，但是由于表的数据量也不小(最大的一张表差不多800多万行，最少也有几百万条数据)，所以在此之前，对大表加字段，加索引做了一个比较深入的学习。
Fastapi 项目使用 sqlalchemy 连接的mysql 数据库，每次第二天首次访问数据库相关操作，都会报错：sqlalchemy.exc.OperationalError: (pymysql.err.OperationalError) (2003, “Can’t connect to MySQL server on ‘x.x.x.x’ ([Errno 111] Connection refused)”)
在进行网络编程时，我们经常会遇到java.net.SocketTimeoutException: Read timed out异常，这个异常通常在网络通信过程中出现，给开发者带来了一定的困惑。本文将深入解析SocketTimeoutException异常的原因，并提供一些避免该异常的策略。
如何确保一个方法，或者一块代码在高并发情况下，同一时间只能被一个线程执行，单体应用可以使用并发处理相关的 API 进行控制，但单体应用架构演变为分布式微服务架构后，跨进程的实例部署，显然就没办法通过应用层锁的机制来控制并发了。
在上一篇博客中，已经介绍了MySQL的全局锁和表级锁，今天我们就讲一下MySQL的行锁
因为腾讯云函数自带CDN，这样我们可以通过腾讯云函数来转发我们的Webshell请求，从而达到隐藏真实IP的目的
设置: transaction-isolation 的值设置成 READ-COMMITTED
是否启用mysql查询缓存，可以通过2个参数：query_cache_type和query_cache_size，
目前业务在使用Kylin的时候反馈查询很慢，直接超时了（超时时间设置的为5min），在日志中获取了相应的SQL以及Cube之后发现：
在我还没来到这个世界上的时候，MySQL过的很辛苦，互联网发展的越来越快，它容纳的数据也越来越多，用户请求也随之暴涨，而每一个用户请求都变成了对它的一个又一个读写操作，MySQL是苦不堪言。尤其是到“双11”、“618“这种全民购物狂欢的日子，都是MySQL受苦受难的日子。
MaxKey 单点登录认证系统，谐音马克思的钥匙寓意是最大钥匙，支持 OAuth 2.x/OpenID Connect、SAML 2.0、JWT、CAS、SCIM 等标准协议，提供简单、标准、安全和开放的用户身份管理(IDM)、身份认证(AM)、单点登录(SSO)、RBAC 权限管理和资源管理等。
上面这张监控图，对于服务端的研发同学来说再熟悉不过了。在日常的系统维护中，『服务超时』应该属于监控报警最多的一类问题。
背景 静儿在2017年8月25日怀着“再也不要下班时间收到报警”的美好期待加入美团金融智能支付负责核心交易，结果入职后收到的报警一天紧似一天。核心交易是整个智能支付的核心链路，承担着智能支付百分之
MySQL提供了不同等级的锁，按限制能力的划分，分为全局锁、表锁、行锁。本文会描述不同锁的应用场景与实现原理。
当系统的用户量上来，每秒QPS上千后，可能就会导致系统的各种卡顿，超时等情况，这时优化操作不可避免
一个刚上线不久的web项目(internet环境)，里面有大文件上传功能，前一阵一直运行得蛮好的，昨天觉得运行比较稳定后，把debug=true改成false,关掉了调试模式，结果今天反馈上传文件时，经常出现超时,刚开始以为是网络问题，因为上传代码一直没有改过，但后来在局域网测试也是这样，这才意识到是debug=false引起的，原来debug=true的时候，系统默认是忽略web.config中超时设置的,所以之前并没有暴露出web.config超时时间设置太短这个问题，重新把web.config的超时时
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
