现状 加参数 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=logs/test.dump 可以实现在jvm发生内存错误后 会生成dump文件 方便开发人员分析异常原因. 当运行在k8s中,如果进程发生错误 导出dump文件后 ,k8s会重启dokcer容器,上一次崩溃生成的dump文件就没有了.如果应用并没有完全崩溃 此时极其不稳定 最好也能通知到技术人员来处理.这样不方便我们排查原因 所有写了一个小工具.大概原理如下 1. -XX:+Heap

Elasticsearch节点重启时背后发生的故事有哪些,应该注意哪些配置内容,本篇文章做一个简单的探讨. 节点离开 在elasticsearch集群中,假设NodeA因为种种原因退出集群,在NodeA上的Shard分片情况(ShardA是主分片,ShardB是某一分片副本) 在存活节点上找到ShardA的副本,将该副本升格为主分片 由于ShardB这一分片副本丢失,所以会重新创建相应的分片副本 在存活的节点中对于分片进行再平衡 这样做的目的是保证每个分片都有足够的副本,可以避免数据丢失.需要注

本文对如何诊断RAC环境中节点重启问题进行了介绍.适用于10gR2和11gR1. 首先我们对能够导致节点重启的CRS进程进行介绍.1.ocssd : 它的主要功能是节点监控(Node Monitoring)和组管理(Group Management),它是CRS的核心进程之一.节点监控是指监控集群中节点的健康,监控的方法是通过网络心跳(network heartbeat)和磁盘心跳(disk heartbeat)实现的,如果集群中的节点连续丢失磁盘心跳或网络心跳,该节点就会被从集群中驱逐,也就是

本文对如何诊断11gR2 GI环境下的节点重启问题进行了一些介绍. 首先,像10g版本一样,我们首先介绍在GI中能够导致节点重启的进程.1.Ocssd.bin:这个进程的功能和10g版本的功能基本差不多,主要是节点监控(Node Monitoring)和组管理(Group Management).详细的信息请参考之前文章“如何诊断节点重启问题”了解详细的内容.2.Cssdagent.bin/Cssdmonitor.bin:这2个进程是11gR2新增加的.他们的工作主要是同ocssd.bin进行本

简介 Node是Pod真正运行的主机,可以是物理机也可以是虚拟机. Node本质上不是Kubernetes来创建的, Kubernetes只是管理Node上的资源. 为了管理Pod,每个Node节点上至少需要运行container runtime(Docker).kubelet和kube-proxy服务. node基本操作:kubectl get nodes,查询所有node 从k8s移除node节点 获取节点列表:kubectl get node 确认需要移除的节点上面没有部署我们所需要的资源

突然发现今晚网站打不开了,提示连不上数据库. ftp也连不上了. 远程连上Azure 发现机器意外重启, 丢失sql server master表和 filezilla 要重新安装. 又耗费我几个小时... 看来db放local不保险...

原创作品,出自 "深蓝的blog" 博客,欢迎转载,转载时请务必注明以下出处,否则追究版权法律责任. 深蓝的blog:http://blog.csdn.net/huangyanlong/article/details/41480075 rac第二个节点重启后无法启动实例:磁盘组dismount问题 实验案例: 实验环境:CentOS 6.4.Oracle 11.2.0.1 现象重演:1. 重启第二节点服务器2. 手工启动第二节点实例,报错[root@node2 ~]# su - ora

DNS配置重启丢失 每次重启后都修改DNS配置文件 /etc/resolv.conf从网上得知 /etc/resolv.conf中的DNS配置是从/etc/resolvconf/resolv.conf.d/head中加载而来于是,用nano或者其他编辑软件打开这个配置文件(建议用nano吧,上手容易)    sudo nano /etc/resolvconf/resolv.conf.d/head打开里面显示如下  # Dynamic resolv.conf(5) file for glibc r

转自霸爷的博客: 转载自系统技术非业余研究 本文链接地址: Erlang节点重启导致的incarnation问题 遇到个问题, =ERROR REPORT==== 10-Mar-2016::09:44:07 ===Discarding message {'$gen_cast',close_be_covered} from <0.771.0> to <0.774.0> in an old incarnation (2) of this node (3) 网上查阅了霸爷的博客,对该问题

Hadoop 分布式环境slaves节点重启: 忽然无法启动DataNode和NodeManager处理: 在master节点: vim /etc/hosts: 修改slave 节点的IP (这个时候的IP应当登录slave节点ifconfig 查看) 造成这个原因是: slave节点如果是通过有线连接的路由器,每次重启后IP会被重新分配,如果salve节点是通过无线连接路由器的话不存在这个问题

一.rabbitmq数据是根据当前hostname作为node节点作为数据名保存 二.添加rabbimq用户sudo rabbitmqctl add_user tlwlmy tlwlmysudo rabbitmqctl list_users 三.修改系统hostname# 将test改成datasudo vim /etc/hostname # 添加data指向本地hostecho '127.0.0.1 data' | sudo tee -a /etc/hosts # hostname生效sudo

我把三台虚拟机重启,发现2个节点一直处于NotReady状态,便去查找问题,到最后是因为子节点的kubelet的状态异常了,restart一下就好了,下面转一下解决的思路 昨天晚上,针对K8S环境做了一次压测,50路并发实施,早上起来看监控,发现昨晚8点之后,系统好像都宕掉了,一看master节点和一个node节点状态变成了not ready,主要定位手段如下: 1. 查看master kubelet状态 systemctl status kubelet 状态正常 2. 查看master kub

节点健康检测 意义 在K8S集群运行的过程中,节点常常会因为运行时组件的问题.内核死锁.资源不足等各种各样的原因不可用.Kubelet默认对节点的PIDPressure.MemoryPressure.DiskPressure等资源状态进行了监控,但是当Kubelet上报这些状态的时候,节点很可能已经长时间处于不可用状态了,并且Kubelet可能已经开始了驱逐Pod的操作.所以原生K8S对节点健康的检测机制在一些场景下是不完善的,我们需要能够在节点出现问题之前提前发现,并且需要更加细致化的指标来描

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 kind: Deployment metadata: name: villa-api labels: app: villa spec: selector: matchLabels: app: villa tier: frontend strategy: type: Recreate template: metadata: labels: app: villa tier

ElasticSearch集群的高可用和自平衡方案会在节点挂掉(重启)后自动在别的结点上复制该结点的分片,这将导致了大量的IO和网络开销.如果离开的节点重新加入集群,elasticsearch为了对数据分片(shard)进行再平衡,会为重新加入的节点再次分配数据分片(Shard), 当一台es因为压力过大而挂掉以后,其他的es服务会备份本应那台es保存的数据,造成更大压力,于是整个集群会发生雪崩.生产环境下建议关闭自动平衡. 数据分片与自平衡 一:关闭自动分片,即使新建index也无法分配数据分

服务器重启后,集群报错: [root@SHH-HQ-NHS11S nhsuser]# redis-cli -c -h ip -p 7000ip:7000> set cc dd(error) CLUSTERDOWN Hash slot not served 检查集群节点情况 > cluster nodes c0767666bee76e5e0dc67f24031a3e1b574235cc :7000@17000 myself,master - 0 0 0 connected 发现集群的节点只剩一个

<RollingFile name="cnkiLogRollingFileError" fileName="${logbigdata.dir}/Log8080/error.log" filePattern="${logbigdata.dir}/Log8080/$${date:yyyy-MM}/error-%d{yyyy-MM-dd}-%i.log" > <Filters> <!--warn/error/fatal级别

问题 五一归来,大量服务器被重启了,其中一台服务器失联了.通过远程桌面登录之后发现服务器的 IP 地址是 "正常" 的,可以 Ping 通自己的 IP,但 Ping 不同网关. 解决 仔细一看,原来的 IP 在重启之后被设置到 ens160 Interface 上了,但该 Interface 却被挂载到 OvS Bridge 之上了: Bridge br-ex Controller "tcp:127.0.0.1:6633" is_connected: true fa

1.在k8smaster 服务器检查节点状态 kubectl describe nodes  aaaa #没有报错,异常信息   2.在节点上检查kubelet服务状态 netstat -tlanp|grep 6443 #正常连接到lk8s master 服务器   3.检查节点kubelet日志 journalctl -u kubelet >> kubelet.log    发现线索: 15 Dec 08 17:31:24 prd-swakopuranium-dmcu01 kubelet[1

错误现象 runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized 解决方式 仅就今天遇到的情况给出解决方法,基于v1.21.1版本,已安装weave,发现仍有以上错误. 我发现 /opt/cni/bin 目录下缺少很多可执行文件,处理方式是重新安装kubernete

首先是按照二进制方式安装的k8s. [root@ht22 calico]# cat /etc/redhat-release CentOS Linux release 7.9.2009 (Core) [root@ht22 calico]# uname -r 3.10.0-1160.45.1.el7.x