TCP三次握手(Three-Way Handshake) 建立一个TCP连接时,需要客户端和服务端总共发送3个包以确认连接的建立. TCP三次握手:第一次握手:Client将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给Server,Client进入SYN_SENT状态,等待Server确认. 第二次握手:Server收到数据包后由标志位SYN=1知道Client请求建立连接,Server将标志位SYN和ACK都置为1,ack=J+1,随机产生一个值seq=K,并将该数据包发送

摘要:已经上线的项目,出现服务挂掉的情况. 介绍:该服务是专门做打印的,业务需求是生成PDF文件进行页面预览,主要是使用ItextPDF+freemaker技术生成一系列PDF文件,其中生成流程有:解析模板生成临时PDF文件--->在临时PDF文件上注入文本和签名域--->旋转页面--->合并生成的多个PDF文件--->删除全部临时文件. 由于该业务生成的文件只是用来预览,不做保存,所以需要生成后就要删除.而每次生成的文件都是放在一个临时文件夹下,临时文件夹一开始我是根据建议书ID

1. 问题:怎么给线上表加字段? 工作中最常遇到的问题,怎么给线上频繁使用的大表添加字段? 比如:给下面的用户表(user)添加年龄(age)字段. CREATE TABLE `user` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '主键', `name` varchar(100) DEFAULT NULL COMMENT '姓名', PRIMARY KEY (`id`) ) ENGINE=InnoDB COMMENT='用户表'; 有同学会说,这还不

昨晚通宵生产压测,终于算是将生产服务宕机的原因定位到了,心累.这篇博客,算作一个复盘和记录吧... 先来看看Redis的缓存淘汰算法思维导图: 说明:当实际占用的内存超过Redis配置的maxmemory时,Redis就会根据用户选择淘汰策略清除被选中的key. 业务场景:用户通过微信入口来访问一个页面: 测试场景:通过多线程模拟定量的并发来访问页面服务: 涉及架构:springsession+Redis集群,容器部署: 问题描述:固定并发数压测10分钟,压测开始后半小时,Redis连接数激增,

背景 在java服务项目上线之后经常会出现宕机的情况 常见原因 内存溢出 1.查到服务进程号 [root@wms ~]# ps -ef|grep java root 6399 6069 0 08:57 pts/2 00:00:00 grep --color=auto java root 25374 1 0 Oct17 ? 00:21:19 /usr/local/jdk/jre/bin/java -Djava.util.logging.config.file=/home/tomcat-wmsweb

问题:在初次练习Mysql数据库事务时,事务正常提交,但是在遇到异常应当回滚时,回滚失败. 代码如下: //2.更新操作. public void update(Connection conn, String sql, Object ...objects){ PreparedStatement preparedstatement = null; try { preparedstatement = conn.prepareStatement(sql); for(int i = 0; i < obj

今天手里其中一个集群几个机器突然宕机,启动hdfs一直超时. clouder-scm-agent主要报了这个错RROR: Unexpected error 'getpwuid(): uid not found: 1001' 看了挺久发现这个机器可能权限可能有问题,修改了cloudera-scm和其他正常机器一样,还是启动不起来,中间也测试修改了host等动作都不行 于是改变思路,把这个机器解除授权从集群中删除又添加进来(还好是测试机器,就采用这个动作,按理hdfs也不受影响才对) 重新添加后,不

简介 Keepalived的作用是检测web服务器的状态,如果有一台web服务器死机,或工作出现故障,Keepalived将检测到,并将有故障的web服务器从系统中剔除,当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中,这些工作全部自动完成,不需要人工干涉,需要人工做的只是修复故障的web服务器. 2工作原理 Layer3,4&7工作在IP/TCP协议栈的IP层,TCP层,及应用层,原理分别如下: Layer3:Keepalived使用Layer3的方式工作式时,K

一.执行此预案的动机 云主机数据盘分区丢失 二.执行此预案的条件 1.确定用户在报障时间点之前有过数据盘分区存在,而在报障时间点该分区消失 2.在执行我们的恢复操作之前,确保将分区所在数据盘进行备份 三.执行此预案的过程 1.用户云主机内安装testdisk工具: a.yum install testdisk b.https://www.cgsecurity.org/wiki/TestDisk_Download 2.执行testdisk 若步骤1采用a方式: testdisk 所需恢复数据盘(例

[问题现象] 服务器在运行过程中,因人为意外导致电源被拔,服务器宕机,mysql重启不成功,报错如下 根据提示,输入systemctl status mysql.service和journalctl -xe查看日志,经过一番百度谷歌折腾也是无果.(很多时候,不能因为突发事件就“病急乱投医”) 最后在mysql 的日志处看到了报错日志 如果centos是通过yum安装的mysql,那么日志一般在/var/log/mysql.log 查看到日志 2018-11-29T08:39:18.977374Z

问题 今天在使用pymysql连数据库的时候,出现了一个bug,查询数据库某个数据,但是在我在数据库中执行sql语句改变数据后,pymsql的查询依然没有发生改变. 代码如下: # 5.6.10 conn = pymysql.connect(host=HOST, port=PORT, user=USER, passwd=PSWD, db=DB) def fetch(): cursor = conn.cursor() sql = "SELECT * FROM hello" try: re

四月份我们公司负责的电票系统上线了,这个系统上线比客户方其他系统上线还特殊,是二期改造项目,旧系统数据还要整合抽取到新系统中继续使用,而且该系统不是增量型方式开发上线的,而且全部开发完后全国上线的,这样开发压力大,测试人员压力也很大,由于环境问题以及在接近上线前客户方还在做需求变更,导致上线后出现了不少缺陷问题,两周后大部分问题还好都得以解决.而在上线前由于多种原因,我们性能测试人员根据项目调研提供的典型交易进行测试发现了不少问题,但是由于开发人员还在忙于需求变更等开发工作,对我们发现的性能问题

首先先粘贴出来我的错误信息,如下: 2019-07-16T00:53:18.285919Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.15) starting as process 18555 2019-07-16T00:53:18.506674Z 0 [ERROR] [MY-012681] [InnoDB] mmap(137428992 bytes) failed; errno 12 2019-07-16T00:5

Region Server宕机总述 HBase一个很大的特色是扩展性极其友好,可以通过简单地加机器实现集群规模的线性扩展,而且机器的配置并不需要太好,通过大量廉价机器代替价格昂贵的高性能机器.但也正因为廉价机器,由于网络硬盘等各方面的原因,机器宕机的概率就会相对比较大.RegionServer作为HBase集群中实际的执行节点,不可避免地也会出现宕机. 宕机并不十分可怕,因为不会丢数据.HBase集群中一台RegionServer宕机(实指RegionServer进程挂掉,下文同)并不会导致已经

简介 ORA-10458: standby database requires recovery ORA-01196: 文件 1 由于介质恢复会话失败而不一致 ORA-01110: 数据文件 1: 'XXXXXXXXXXXXXXXXXX\XXXXX1.DBF' 一个项目做了Oracle主从数据库同步,通过Dataguard实现,从库服务器宕机,再开机的时候,从库无法启动,报"ORA-01196: 文件 1 由于介质恢复会话失败而不一致"这个错误,具体日志信息如下: ORA-10458:

首先必须执行con.setAutoCommit(false)方法,将JDBC事务设置为手动提交,否则手动提交con.commit()无效,手动回滚con.rollback()引发SQLException:AutoCommit 模式设置为“true”时,无法调用回滚操作. 我们执行con.setAutoCommit(false)方法,将JDBC事务设置为手动提交,然后分9种情况讨论JDBC事务和数据库事务. 描述:存储过程里面有一条INSERT语句在数据库事务管理下,而另一条INSERT语句在JD

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

早上突然收到dnspod的宕机通知(好久没收到了,有点手足无措). 服务器在上午10:40时达到85%.uptime显示cpu利用率达到35.不宕才怪. 按照之前的经验,应该是触发一个特别耗CPU的处理,把php-cgi重启就能立马恢复,之后再查看日志. 重启后立刻ok. 查看日志,调出那一时刻的日志一条一条的过,重点放在反应时间上.正常的处理时间应该在1秒内,发现很多在几十秒以上的日志,慢慢回溯,发现了最开始异常的记录,是多个提交comment的日志. 发现一连串的来自同一IP的高频率的浏览文

ASMB的BUG(ORA-04030 kfmditer)导致数据库宕机 现象: 客户的一个重要生产系统RAC的一个实例宕机,查看alert日志: Fri Jun 21 17:05:52 2013 Errors in file /opt/app/diag/rdbms/jyj/jyj1/trace/jyj1_asmb_11391.trc (incident=31397): ORA-04030: out of process memory when trying to allocate 592 byt

最近某hadoop集群多次出现机器宕机,现象为瞬间机器的sys cpu增长至100%,机器无法登录.只能硬件重启,ganglia cpu信息如下: 首先怀疑有用户启动了比较奇葩的job,导致不合理的系统调用出现的问题.随后加了ps及pidstat信息收集job信息(公共集群蛋疼的地方),然后出现问题的时候,各类脚本已经无法工作, 一直没有抓到现场. 终于在某一次看到一台机器sys 瞬间增长,且机器还能登录.立马查看现场,发现竟然元凶是datanode:datanode一个进程占用cpu 1600

由于阿里云经典网络迁移到专用网络,一不小心没有先预备方案调整网段, 导致实例无法以内网IP形式访问数据库,被迫进行数据库停机后网络网段调整,导致宕机了几个小时...被客户各种投诉爆了.. 基于这次数据库恢复血泪史, 特整理解决办法, 让日后同学避免再犯. 数据库master库重启后, 确保能正常提供服务.由于生产上BI系统使用的是slave从库做数据查询, 从库的数据库已经落后了master好几天, 查看从库状态: mysql> show slave status\G; 显示 Slave_IO_