前言 我们的分库分表中间件在线上运行了两年多,到目前为止还算稳定.在笔者将精力放在处理各种灾难性事件(例如中间件物理机宕机/数据库宕机/网络隔离等突发事件)时.竟然发现还有一些奇怪的corner case.现在就将排查思路写成文章分享出来. Bug现场 应用拓扑 应用通过中间件连后端多个数据库,sql会根据路由规则路由到指定的节点,如下图所示: 错误现象 应用在做某些数据库操作时,会发现有比较大的概率失败.他们的代码逻辑是这样: int count = updateSql(sql1); ...…

解Bug之路-记一次中间件导致的慢SQL排查过程 前言 最近发现线上出现一个奇葩的问题,这问题让笔者定位了好长时间,期间排查问题的过程还是挺有意思的,正好博客也好久不更新了,就以此为素材写出了本篇文章. Bug现场 我们的分库分表中间件在经过一年的沉淀之后,已经到了比较稳定的阶段.而且经过线上压测的检验,单台每秒能够执行1.7W条sql.但线上情况还是有出乎我们意料的情况.有一个业务线反映,每天有几条sql有长达十几秒的超时.而且sql是主键更新或主键查询,更奇怪的是出现超时的是不同的sql,似…

解Bug之路-记一次存储故障的排查过程 高可用真是一丝细节都不得马虎.平时跑的好好的系统,在相应硬件出现故障时就会引发出潜在的Bug.偏偏这些故障在应用层的表现稀奇古怪,很难让人联想到是硬件出了问题,特别是偶发性出现的问题更难排查.今天,笔者就给大家带来一个存储偶发性故障的排查过程. Bug现场 我们的积分应用由于量非常大,所以需要进行分库分表,所以接入了我们的中间件.一直稳定运行,但应用最近确经常偶发连接建立不上的报错.报错如下: GetConnectionTimeOutException 而…

解Bug之路-主从切换"未成功"? 前言 数据库主从切换是个非常有意思的话题.能够稳定的处理主从切换是保证业务连续性的必要条件.今天笔者就来讲讲主从切换过程中一个小小的问题. 故障场景 最近线上进行主从切换,大部分应用都切过去了,但是某些应用的连接确还在老的主(新的从)上面. 这让对应应用的开发百思不得其解,于是求助了笔者一探究竟. 怎么发现的 应用开发收到Cat监控告警,发现这个应用(A)中的请求在好几台机器中一直稳定失败.联想到昨晚刚做过数据库主从切换演练,于是上机器netstat…

解Bug之路-记一次对端机器宕机后的tcp行为 前言 机器一般过质保之后,就会因为各种各样的问题而宕机.而这一次的宕机,让笔者观察到了平常观察不到的tcp在对端宕机情况下的行为.经过详细跟踪分析原因之后,发现可以通过调整内核tcp参数来减少宕机造成的影响. Bug现场 笔者所在的公司用某个中间件的古老版本做消息转发,此中间件在线上运行有些年头了,大约刚开始部署的时候机器还是全新的,现在都已经过保了.机器的宕机导致了一些诡异的现象.如下图所示: 在中间件所在机器宕机之后,出现了调用中间件超时的现象…

解Bug之路-NAT引发的性能瓶颈 笔者最近解决了一个非常曲折的问题,从抓包开始一路排查到不同内核版本间的细微差异,最后才完美解释了所有的现象.在这里将整个过程写成博文记录下来,希望能够对读者有所帮助.(篇幅可能会有点长,耐心看完,绝对物有所值~) 环境介绍 先来介绍一下出问题的环境吧,调用拓扑如下图所示: 调用拓扑图 合作方的多台机器用NAT将多个源ip映射成同一个出口ip 20.1.1.1,而我们内网将多个Nginx映射成同一个目的ip 30.1.1.1.这样,在防火墙和LVS之间,所有的请…

解Bug之路-TCP粘包Bug - 无毁的湖光-Al的个人空间 - 开源中国 https://my.oschina.net/alchemystar/blog/880659 解Bug之路-TCP粘包Bug 前言 关于TCP流 TCP是流的概念,解释如下 TCP窗口的大小取决于当前的网络状况.对端的缓冲大小等等因素, TCP将这些都从底层屏蔽.开发者无法从应用层获取这些信息. 这就意味着,当你在接收TCP数据流的时候无法知道当前接收了 有多少数据流,数据可能在任意一个比特位(seq)上. 详情见笔者…

解Bug之路-记一次JVM堆外内存泄露Bug的查找 前言 JVM的堆外内存泄露的定位一直是个比较棘手的问题.此次的Bug查找从堆内内存的泄露反推出堆外内存,同时对物理内存的使用做了定量的分析,从而实锤了Bug的源头.笔者将此Bug分析的过程写成博客,以飨读者. 由于物理内存定量分析部分用到了linux kernel虚拟内存管理的知识,读者如果有兴趣了解请看ulk3(<深入理解linux内核第三版>) 内存泄露Bug现场 一个线上稳定运行了三年的系统,从物理机迁移到docker环境后,运行了一段…

解Bug之路-Nginx 502 Bad Gateway 前言 事实证明,读过Linux内核源码确实有很大的好处,尤其在处理问题的时刻.当你看到报错的那一瞬间,就能把现象/原因/以及解决方案一股脑的在脑中闪现.甚至一些边边角角的现象都能很快的反应过来是为何.笔者读过一些Linux TCP协议栈的源码,就在解决下面这个问题的时候有一种非常流畅的感觉. Bug现场 首先,这个问题其实并不难解决,但是这个问题引发的现象倒是挺有意思.先描述一下现象吧, 笔者要对自研的dubbo协议隧道网关进行压测(这个…

解Bug之路-串包Bug 笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug.现在就挑一个案例出来,写出分析思路,以飨读者,希望读者在以后的工作中能够少踩点坑. 串包Bug现场 前置故障Redis超时 由于某个系统大量的hget.hset操作将Redis拖垮,通过监控发现Redis的CPU和IO有大量的尖刺,CPU示意图下图所示: CPU达到了100%,导致很多Redis请求处理不及时,其它业务系统都频繁爆出readTimeOut.此时,紧急将这个…

解Bug之路-记一次线上请求偶尔变慢的排查 前言 最近解决了个比较棘手的问题,由于排查过程挺有意思,于是就以此为素材写出了本篇文章. Bug现场 这是一个偶发的性能问题.在每天几百万比交易请求中,平均耗时大约为300ms,但总有那么100多笔会超过1s,让我们业务耗时监控的99.99线变得很尴尬.如下图所示: 为了精益求精,更为了消除这个尴尬的指标,笔者开始探寻起这100多慢请求笔的原因. 先找一笔看看 由于笔者写的框架预留了traceId,所以找到这笔请求的整个调用的链路还是非常简单的. 而且…

解Bug之路-ZooKeeper集群拒绝服务 前言 ZooKeeper作为dubbo的注册中心,可谓是重中之重,线上ZK的任何风吹草动都会牵动心弦.最近笔者就碰到线上ZK Leader宕机后,选主无法成功导致ZK集群拒绝服务的现象,于是把这个case写出来分享给大家(基于ZooKeeper 3.4.5). Bug现场 一天早上,突然接到电话,说是ZooKeeper物理机宕机了,而剩余几台机器状态都是 sh zkServer.sh status it is probably not running…

前言 和外部联调一直是令人困扰的问题,尤其是一些基础环境配置导致的问题.笔者在一次偶然情况下解决了一个调用外网服务概率性失败的问题.在此将排查过程发出来,希望读者遇到此问题的时候,能够知道如何入手. 起因 笔者的新系统上线,需要PE执行操作.但是负责操作的PE确和另一个开发在互相纠缠,让笔者等了半个小时之久.本着加速系统上线的想法,就想着能不能帮他们快速处理掉问题,好让笔者早点发完回去coding.一打听,这个问题竟然扯了3个月之久,问题现象如下: 每个client都会以将近1/2的概率失败,而…

前言 dubbo是一个成熟且被广泛运用的框架.饶是如此,在某些极端条件下基于dubbo的应用还会出现无法重连zookeeper的问题.由于此问题容易导致比较大的故障,所以笔者费了一番功夫去定位,现将排查过程写成博文分享出来. Bug现场 这是一起在测试环境出现的故障.起因是网工做交换机切换演练,可能由于姿势不对,使得断网的时间从预估的秒级达到了分钟级.等网络恢复后,测试环境就炸开了锅,基本上所有应用再也无法提供服务,在dubbo控制台上也看不到任何提供者,他们和zk的连接都断开而且似乎完全没有重…

前言 笔者最近解决了一个困扰了业务系统很久的问题.这个问题只在发布时出现,每次只影响一两次调用,相较于其它的问题来说,这个问题有点不够受重视.由于种种原因,使得这个问题到了业务必须解决的程度,于是就到了笔者的手上. 问题现场 我们采用的是dubbo服务,这是个稳定成熟的RPC框架.但是我们在某些应用中会发现,只要这个应用一发布(或者重启),就会出现请求超时的问题,如下图所示: 而且都是第一笔请求会报错,之后就再也没有问题了. 排查日志 好了,现象我们知道了,于是开始排查那个时间点的日志.Serv…

在实际项目开发过程中,sql脚本需要多次执行.而一般的DML和DDL语句一般只能执行一次,再次执行执行时就会报错(操作对应已存在/不存在),所以必须将sql脚本生成可重复执行的.本文共分为4部分:1.什么是DDL和DML:2.DDL可重复执行脚本:3.DML可重复执行脚本. 1.什么是DDL和DML DDL: Data Defination Language,即数据定义语言.主要是是对表进行操作(DROP, CREATE,ALTER...) DML: Data Management Langua…

问题 在工作中偶尔会遇到这样的问题:SQL script重复执行时会报错. 理想的状态下,SQL script跑一遍就够了,是不会重复执行的,但是实际情况往往很复杂. 比如Dev同学在开发时在A环境把他写的那个脚本单独执行了一遍,而在下一个测试周期的时候,测试同学又在A环境把所有DB脚本都执行了一遍,然后就报错了. 如下示例,这里错误的原因在于重复创建表. 例1 create table tableA (col1 char(10), col2 number); SQL Error: ORA-00…

接上文:SQL Server 执行计划操作符详解(2)--串联(Concatenation ) 前言: 前面两篇文章介绍了关于串联(Concatenation)和断言(Assert)操作符,本文介绍第三个常见的操作符计算标量(Compute Scalar).这个操作符的名字比较直观--进行一个标量计算并返回计算值.官方说明:Compute Scalar 运算符通过对表达式求值来生成计算标量值.该值可以返回给用户.在查询中的其他位置引用或二者皆可.例如,在筛选谓词或联接谓词中就会出现二者皆可的情况…

本文接上文:SQL Server 执行计划操作符详解(1)--断言(Assert) 前言: 根据计划,本文开始讲述另外一个操作符串联(Concatenation),读者可以根据这个词(中英文均可)先幻想一下是干嘛的.其实还是挺直观,就是把东西连起来,那么下面我们来看看到底连什么?怎么连?什么时候连? 简介: 串联操作符既是物理操作符,也是逻辑操作符,在中文版SQL Server的图形化执行计划中称为"串联",在其他格式及英文版本中称为"Concatenation".…

目录 一.准备工作 二.SQL逻辑查询语句执行顺序 三.SQL书写习惯 一.准备工作 先来一段伪代码,首先你能看懂么? SELECT DISTINCT <select_list> FROM <left_table> <join_type> JOIN <right_table> ON <join_condition> WHERE <where_condition> GROUP BY <group_by_list> HAVIN…

一.SQL语句执行原理: 第一步:客户端把语句发给服务器端执行 当我们在客户端执行select语句时, 客户端会把这条SQL语句发送给服务器端,让服务器端的进程来处理这语句.也就是说,Oracle客户端是不会做任何的操作,它的主要任务就是把客户端产生的一些SQL语句发送给服务器端.虽然在客户端也有一个数据库进程,但是,这个进程的作用跟服务器上的进程作用不同.服务器上的数据库进程才会对SQL语句进行相关的处理.不过,有个问题需要说明,就是客户端的进程跟服务器的进程是一 一对应的.也就是说,在客户端…

本文目录 一.Apache Spark 二.Spark SQL发展历程 三.Spark SQL底层执行原理 四.Catalyst 的两大优化 一.Apache Spark Apache Spark是用于大规模数据处理的统一分析引擎,基于内存计算,提高了在大数据环境下数据处理的实时性,同时保证了高容错性和高可伸缩性,允许用户将Spark部署在大量硬件之上,形成集群. Spark源码从1.x的40w行发展到现在的超过100w行,有1400多位大牛贡献了代码.整个Spark框架源码是一个巨大的工程.…

SQL Server 查询处理中的各个阶段(SQL执行顺序) SQL 不同于与其他编程语言的最明显特征是处理代码的顺序.在大数编程语言中,代码按编码顺序被处理,但是在SQL语言中,第一个被处理的子句是FROM子句,尽管SELECT语句第一个出现,但是几乎总是最后被处理. 每个步骤都会产生一个虚拟表,该虚拟表被用作下一个步骤的输入.这些虚拟表对调用者(客户端应用程序或者外部查询)不可用.只是最后一步生成的表才会返回 给调用者.如果没有在查询中指定某一子句,将跳过相应的步骤.下面是对应用于SQL s…

Oracle 11g在DBMS_SHARED_POOL包中引入了一个名为PURGE的新存储过程,用于从对象库缓存中刷新特定对象,例如游标,包,序列,触发器等.也就是说可以删除.清理特定SQL的执行计划,这样在特殊情况下,就避免你要将整个SHARED POOL清空的危险情况.例如某个SQL语句由于优化器产生了错误的执行计划,我们希望优化器重新解析,生成新的执行计划,必须先将SQL的执行计划从共享池中刷出或将其置为无效,那么优化器才能将后续SQL进行硬解析.生成新的执行计划.这在以前只能使用清空共享…

MyBatis 是支持定制化 SQL.存储过程以及高级映射的优秀的持久层框架.MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集.MyBatis 可以对配置和原生Map使用简单的 XML 或注解,将接口和 Java 的 POJOs(Plain Old Java Objects,普通的 Java对象)映射成数据库中的记录.如何新建MyBatis源码工程请点击MyBatis源码分析-IDEA新建MyBatis源码工程. MyBatis框架主要完成的是以下2件事情: 根据JD…

标准sql的解析顺序为 1)FROM子句,组装来自不同数据源的数据 2)WHERE子句 基于制定的条件对记录进行筛选 3)GROUP BY 子句将数据划分为多个分组 4)使用聚合函数进行计算 5) 使用HAVING子句将数据划分为多个分组 6)计算所有的表达式 7) 使用ORDER BY对结果集进行排序 二.执行顺序 1. FROM:对FROM子句中前两个表执行笛卡尔积生成虚拟表vt1 2. ON: 对vt1表应用ON筛选器只有满足 join_condition 为真的行才被插入vt2 3. O…

标签:SQL SERVER/MSSQL SERVER/数据库/DBA/内存池/缓冲区 概述 了解执行计划对数据库性能分析很重要,其中涉及到了语句性能分析与存储,这也是写这篇文章的目的,在了解执行计划之前先要了解一些基础知识,所以文章前面会讲一些概念,学起来会比较枯燥,但是这些基础知识非常重要. 目录 概述 基础概念 怎样缓存执行计划 SQL Server自动删除执行计划 重新编译执行计划 测试 执行计划相关系统视图 手动清空缓存执行计划 测试索引更改对执行计划的影响 测试增加字段对执行计划的影响…

前提  本文仅讨论SQL Server查询时, 对于非复合统计信息,也即每个字段的统计信息只包含当前列的数据分布的情况下, 在用多个字段进行组合查询的时候,如何根据统计信息去预估行数的. 利用不同字段的统计信息做数据行数预估的算法原理,以及SQL Server 2012和SQL Server 2014该算法的差异情况, 这里暂时不涉及复合统计信息,暂不涉及统计信息的更新策略及优化相关话题,以及其他SQL Server版本计算方式. 统计信息是什么 简单说就是对某些字段的数据分布的一种描述,让SQ…

在查看执行计划或调优过程中,执行计划里面有些现象总会让人有些疑惑不解: 1:为什么同一条SQL语句有时候会走索引查找,有时候SQL脚本又不走索引查找,反而走全表扫描? 2:同一条SQL语句,查询条件的取值不同,它的执行计划会一致吗? 3: 同一条SQL语句,其执行计划会变化,为什么 4: 在查询条件的某个或几个字段上创建了索引,执行计划就一定会走该索引吗? 5:同时存在几个索引,SQL语句会走那个索引? ..............................................…

sql语法的分析是从右到左 一.sql语句的执行步骤: 1)词法分析,词法分析阶段是编译过程的第一个阶段.这个阶段的任务是从左到右一个字符一个字符地读入源程序,即对构成源程序的字符流进行扫描然后根据构词规则识别单词(也称单词符号或符号).词法分析程序实现这个任务.词法分析程序可以使用lex等工具自动生成. 2)语法分析,分析语句的语法是否符合规范,衡量语句中各表达式的意义. 3)语义分析,检查语句中涉及的所有数据库对象是否存在,且用户有相应的权限. 4)视图转换,将涉及视图的查询语句转换为相应的…