现象: 机房反馈9点左右,机房交换机故障,导致网络出现问题 业务人员反馈某个接口超时 初查:通过业务日志查看分析发现,在连接mongo的某个collections时候,报错错误如下: 在写入数据的时候报错: Mongo::Error::OperationFailure - no progress was made executing batch write op rounds ( ops completed rounds total) (): 因此初步确定问题出在mongo分片集群上 进入mon…

事件起因:近期有研发反应,某数据库从08切换到12环境后,不定期出现写操作提交延迟的问题: 事件分析:在排除了系统资源争用等问题后,初步分析可能由于网络抖动导致同步模式alwayson节点经常出现会话超时等待提交的问题导致.…

记录一次搭建unix网络编程环境过程中遇到的问题和总结 计算机环境虚拟机 linuxmint-18-xfce-64bit 1.打开unix网络编程.iso 把目录下的文件复制到某一目录,修改权限,可命令可鼠标操作. 2. s@ss-Linux ~/unix/unpv13e $ sudo su [sudo] s 的密码: ss-Linux unpv13e # ./configure checking build system type... x86_64-unknown-linux-gnu che…

解决了, 这个问题是我在开启虚拟机ubuntu系统的过程中, 在主机win7上切换了网络连接导致的, 就是刚开始我用的无线宽带上网, 此时开启了ubuntu ,然后使用过程中,我在win7上切换回静态连接有线上网, 此时ubuntu断网, 这个问题是, 在主机切换网络之后, ubuntu并没有识别到当前网络变化 一直在沿用之前的网络,但是主机已经不再提供之前的网络了, 所以ubuntu顺利断网, 要想恢复网络, 就需要在ubuntu中 ip/ stop , renew release 一下,就是…

今天在公司使用spring cloud config搭建配置中心的时候,出现了读取不到git库的问题:Cannot clone or checkout repository.在网上百度,前面几个答案都是在spring.cloud.config.server.git.uri的值后面加上.git,这个明显是不对的,而且后面我也验证了,这个在2.0.0的spring cloud上是不存在的,如果出现了这个问题,肯定是用了早期版本的spring cloud. 后面突然想到,我们公司走外网是要通过代理服务…

date: 2018-04-19 21:00 tag: java,mysql,exception,mat,调试,jvm 工具: gceasy.io, MAT 线上系统出现一个诡异的bug,通过heap dump分析 分析: 通过日志确认系统在一天前就已经停止运行 代码较简单应该不存在DB写入操作死锁 mysql操作不是特别频繁 定位: 使用jmap -dump导出线上的应用的heap dump jstack 导出堆栈信息 分析jstack发现多个Thread在DB写入时在等待同一把锁 通过MAT…

mongodb因非法关闭导致无法启动的解决方案 1.删除数据库目录的.lock文件 2.输入命令 mongod --repair 3.重启…

情况详细描述; k8s集群,一台master,两台worker 在master节点上部署一个单节点的nacos,导致master节点状态不在线(不论是否修改nacos的默认端口号都会导致master节点不在线). 但是在worker节点上就可以. 报错信息如下: Message from syslogd@localhost at Jun 2 11:08:51 ... haproxy[1127]: proxy kube-master has no server available! Message…

1.相对于传统主从模式的优势 传统的主从模式,需要手工指定集群中的Master.如果Master发生故障,一般都是人工介入,指定新的Master.这个过程对于应用一般不是透明的,往往伴随着应用重新修改配置文件,重启应用服务器等. 而MongoDB副本集,集群中的任何节点都可能成为Master节点.一旦Master节点故障,则会在其余节点中选举出一个新的Master节点.并引导剩余节点连接到新的Master节点.这个过程对于应用是透明的. 2. Bully选举算法 Bully算法是一种协调者(主节…

Oracle 监听器日志文件过大导致监听异常 db版本:11.2.0.1 os版本:windows2008 现象: 应用异常,无法连接数据库.登陆数据库服务器,查看监听已经断掉.尝试重启监听,重启失败.查看监听日志listener.log的大小已经超过4G. 解决方法: 删除listener.log(删除前可以先做备份),然后重启监听.监听重启后会自动创建一个新的日志文件. 补充: 在监听进程运行时,无法对listener.log做删除或者重命名操作. 如果不想重启监听,删除监听日志.可以按如下…