Vertica节点宕机处理一例
Vertica节点宕机处理一例：
1. 查询数据库版本和各节点状态
```
dbadmin=> select version();
version
------------------------------------
Vertica Analytic Database v6.1.3-7
(1 row)
dbadmin=> select node_name, node_id, node_state, node_address from nodes;
node_name | node_id | node_state | node_address
--------------------+-------------------+------------+---------------
v_xxxxxxx_node0001 | 45035996273704980 | UP | 192.168.xx.xx
v_xxxxxxx_node0002 | 45035996273719008 | DOWN | 192.168.xx.xx
v_xxxxxxx_node0003 | 45035996273719012 | UP | 192.168.xx.xx
v_xxxxxxx_node0004 | 45035996273719016 | UP | 192.168.xx.xx
v_xxxxxxx_node0005 | 45035996273719020 | UP | 192.168.xx.xx
(5 rows)
<h1 id="2"> 2. 常规方式启动宕机节点失败</h1>
[常规方式启动宕机节点](http://www.cnblogs.com/jyzhao/p/3855601.html)失败，瞬间返回主界面，查询到报错如下：
*** Restarting hosts for database xxxxxxx ***
restart host 192.168.xx.xx with catalog v_xxxxxxx_node0002_catalog and data v_xxxxxxx_node0002_data
issuing multi-node restart
Spread does not seem to be running on 192.168.xx.xx. The database will not be started on this host.
The following host(s) are not available: 192.168.xx.xx.
You should get them running first. Operation can not be completed.
result of multi-node restart: K-safe parameters not met.
Restart Hosts result: K-safe parameters not met.
<h1 id="3"> 3. 进一步查看宕机节点的详细日志</h1>
发现/opt/vertica/log/adminTools-dbadmin.log中有这么一段错误日志：
Apr 16 10:55:23 Error code 1 []
Apr 16 10:56:19 dbadmin@192.168.xx.xx: /opt/vertica/bin/vertica --status -D /Vertica/xxxxxxx/v_xxxxxxx_node0001_catalog
Apr 16 10:56:19 Error code 1 ['vertica process is not running']
Apr 16 10:56:19 dbadmin@192.168.xx.xx: ps -aef | grep /opt/vertica/bin/vertica | grep "-D /Vertica/xxxxxxx/v_xxxxxxx_node0001_catalog" | grep -v "ps -aef"
<h1 id="4"> 4. 定位问题并解决 </h1>
基本确定是宕机节点的spread进程当前没有正常运行。
那么如何启动spread进程呢？
spread在Linux中是以服务的形式存在的。
/etc/init.d/spreadd status
/etc/init.d/spreadd start
/etc/init.d/spreadd stop
## 4.1 spread进程状态 ##
[root@Vertica02 log]# /etc/init.d/spreadd status
spread 已死，但 pid 文件仍存
Try using 'spreadd stop' to clear state
而正常节点的spread服务应该是正常运行的：
[root@Vertica01 ~]# /etc/init.d/spreadd status
spread (pid 19256) 正在运行...
## 4.2 尝试启动spread进程 ##
[root@Vertica02 log]# /etc/init.d/spreadd start
Starting spread daemon: [失败]
按提示尝试stop
[root@Vertica02 log]# /etc/init.d/spreadd stop
Stopping spread daemon: [失败]
[root@Vertica02 log]# /etc/init.d/spreadd help
用法：/etc/init.d/spreadd {start|stop|status|restart|condrestart}
[root@Vertica02 log]# /etc/init.d/spreadd restart
Stopping spread daemon: [失败]
Starting spread daemon: spread (pid 53230) 正在运行...
[确定]
[root@Vertica02 log]#
[root@Vertica02 log]# /etc/init.d/spreadd status
spread (pid 53230) 正在运行...
## 4.3 验证spread进程已经正常运行 ##
[root@Vertica02 log]# ps -ef|grep spread|grep -v grep
spread 53230 1 0 09:43 ? 00:00:00 /opt/vertica/spread/sbin/spread -n N192168062089 -c /opt/vertica/config/vspread.conf
spread进程起来后，然后就可以再次尝试[常规方式启动恢复宕机节点](http://www.cnblogs.com/jyzhao/p/3855601.html)了。
确定宕机节点已经在RECOVERING.
dbadmin=> select node_name, node_id, node_state, node_address from nodes;
node_name | node_id | node_state | node_address
--------------------+-------------------+------------+---------------
v_xxxxxxx_node0001 | 45035996273704980 | UP | 192.168.xx.xx
v_xxxxxxx_node0002 | 45035996273719008 | RECOVERING | 192.168.xx.xx
v_xxxxxxx_node0003 | 45035996273719012 | UP | 192.168.xx.xx
v_xxxxxxx_node0004 | 45035996273719016 | UP | 192.168.xx.xx
v_xxxxxxx_node0005 | 45035996273719020 | UP | 192.168.xx.xx
(5 rows)
当宕机节点的状态由RECOVERING->UP,即可确定恢复操作已完成。
## 4.4 尝试改用第二种恢复方案进行恢复 ##
很遗憾发现常规恢复的第一种方案无法成功（恢复整晚10小时+未成功）。
而估计的恢复时间，dstat监控宕机节点的网络接受流量速率以及数据目录的大小增加速率。
初步估计平均100M/s的速度copy恢复，1.3T数据量全部恢复大致也就需要4个小时。
故尝试变更为第二种方案进行恢复，即清空宕机节点所有文件完全恢复。之前的总结只说了思路，这里简单记录下这个恢复过程。
### 1.停掉RECOVERING的节点。 ###
常规停止不行就kill掉，均在admintools工具中可以操作。
dbadmin=> select node_name, node_id, node_state, node_address from nodes;
node_name | node_id | node_state | node_address
--------------------+-------------------+------------+---------------
v_xxxxxxx_node0001 | 45035996273704980 | UP | 192.168.xx.xx
v_xxxxxxx_node0002 | 45035996273719008 | DOWN | 192.168.xx.xx
v_xxxxxxx_node0003 | 45035996273719012 | UP | 192.168.xx.xx
v_xxxxxxx_node0004 | 45035996273719016 | UP | 192.168.xx.xx
v_xxxxxxx_node0005 | 45035996273719020 | UP | 192.168.xx.xx
(5 rows)
### 2.宕机节点原Vertica目录mv重命名xxxxxxx_old，然后后台删除这个目录（这步是为了尽快进入恢复阶段）。 ###
`nohup rm -rf /Vertica/xxxxxxx_old &`
### 3.重新建立目录（注意权限），拷贝vertica.conf到catalog目录中。 ###
`mkdir -p /Vertica/xxxxxxx/v_xxxxxxx_node0002_catalog && mkdir -p /Vertica/xxxxxxx/v_xxxxxxx_node0002_data`
### 4.节点1admintools工具启动宕机节点，进入恢复状态。 ###
*** Restarting hosts for database xxxxxxx ***
restart host 192.168.xx.xx with catalog v_xxxxxxx_node0002_catalog and data v_xxxxxxx_node0002_data
issuing multi-node restart
Node Status: v_xxxxxxx_node0002: (DOWN)
Node Status: v_xxxxxxx_node0002: (DOWN)
Node Status: v_xxxxxxx_node0002: (INITIALIZING)
Node Status: v_xxxxxxx_node0002: (RECOVERING)
Node Status: v_xxxxxxx_node0002: (RECOVERING)
Node Status: v_xxxxxxx_node0002: (RECOVERING)
Node Status: v_xxxxxxx_node0002: (RECOVERING)
Node Status: v_xxxxxxx_node0002: (RECOVERING)
Node Status: v_xxxxxxx_node0002: (RECOVERING)
Node Status: v_xxxxxxx_node0002: (RECOVERING)
Nodes UP: v_xxxxxxx_node0001, v_xxxxxxx_node0003, v_xxxxxxx_node0005, v_xxxxxxx_node0004
Nodes DOWN: v_xxxxxxx_node0002 (may be still initializing).
result of multi-node restart: 7
Restart Hosts result: 7
Vertica Analytic Database 6.1.3-7 Administration Tools
### 5.关注恢复状态。 ###
dbadmin=> select node_name, node_id, node_state, node_address from nodes;
node_name | node_id | node_state | node_address
--------------------+-------------------+------------+---------------
v_xxxxxxx_node0001 | 45035996273704980 | UP | 192.168.xx.xx
v_xxxxxxx_node0002 | 45035996273719008 | RECOVERING | 192.168.xx.xx
v_xxxxxxx_node0003 | 45035996273719012 | UP | 192.168.xx.xx
v_xxxxxxx_node0004 | 45035996273719016 | UP | 192.168.xx.xx
v_xxxxxxx_node0005 | 45035996273719020 | UP | 192.168.xx.xx
(5 rows)
同样，当宕机节点的状态由RECOVERING->UP,即可确定恢复操作已完成。
又遇到小插曲，总共单节点1.3T的数据恢复到1.2T的时候，不动了。
$ df -h /Vertica/
文件系统 容量 已用 可用 已用%% 挂载点
/dev/mapper/vg_vertica02-LogVol00
3.6T 1.2T 2.3T 34% /Vertica
此时dstat的监控信息看到，网络拷贝的流量同时几乎没有了。
恢复过程中发现有入库程序在跑,停掉入库程序重新恢复。
另外考虑到数据量，恢复前先删除了部分大表的历史分区，以缩短时间，最终恢复成功。
dbadmin=> select node_name, node_id, node_state, node_address from nodes;
node_name | node_id | node_state | node_address
--------------------+-------------------+------------+---------------
v_xxxxxxx_node0001 | 45035996273704980 | UP | 192.168.xx.xx
v_xxxxxxx_node0002 | 45035996273719008 | UP | 192.168.xx.xx
v_xxxxxxx_node0003 | 45035996273719012 | UP | 192.168.xx.xx
v_xxxxxxx_node0004 | 45035996273719016 | UP | 192.168.xx.xx
v_xxxxxxx_node0005 | 45035996273719020 | UP | 192.168.xx.xx
(5 rows)
Vertica节点宕机处理一例的更多相关文章
- Vertica集群单节点宕机恢复方法
Vertica集群单节点宕机恢复方法 第一种方法: 直接通过admintools -> 5 Restart Vertica on Host 第二种方法: 若第一种方法无法恢复,则清空宕机节点的c ...
- clickhouse高可用-节点宕机数据一致性方案-热扩容
1. 集群节点及服务分配 说明: 1.1. 在每个节点上启动两个clickhouse服务(后面会详细介绍如何操作这一步),一个数据分片,一个数据备份,为了确保宕机数据一致性,数据分片和数据备份不能同一 ...
- elasticsearch介绍集群,模拟横向扩展节点、节点宕机、改变分片
出处:[http://www.cnblogs.com/dennisit/p/4133131.html] ,防楼主删博,故保留一份! elasticsearch用于构建高可用和可扩展的系统.扩展 ...
- redis集群节点宕机
redis集群是有很多个redis一起工作,那么就需要这个集群不是那么容易挂掉,所以呢,理论上就应该给集群中的每个节点至少一个备用的redis服务.这个备用的redis称为从节点(slave). 1. ...
- openstack高可用集群20-openstack计算节点宕机迁移方案
openstack计算节点宕机迁移方案 情景一:/var/lib/nova/instances/ 目录不共享的处理方法(类似手动迁移云主机到其他节点)
- Redis生产环境节点宕机问题报错及恢复排错
Redis故障发现 主观下线 当cluster-node-timeout时间内某节点无法与另一个节点顺利完成ping消息通信时,则将该节点标记为主观下线状态. 客观下线 当某个节点判断另一个节点主观下 ...
- 『叶问』#41，三节点的MGR集群，有两个节点宕机后还能正常工作吗
『叶问』#41,三节点的MGR集群,有两个节点宕机后还能正常工作吗 每周学点MGR知识. 1. 三节点的MGR集群,有两个节点宕机后还能正常工作吗 要看具体是哪种情况. 如果两个节点是正常关闭的话,则 ...
- mongodb副本集中其中一个节点宕机无法重启的问题
2-8日我还在家中的时候,被告知mongodb副本集中其中一个从节点因未知原因宕机,然后暂时负责代管的同事无论如何就是启动不起来. 当时mongodb的日志信息是这样的: 实际上这里这么长一串最重要的 ...
- Hadoop NameNode判断 DataNode 节点宕机的时间
.namenode 如何判断datanode节点是否宕机? 先决条件: datanode每隔一段时间像namenode汇报,汇报的信息有两点 ()自身datanode的状态信息: ()自身datano ...
随机推荐
- 开源：ASP.NET Aries 开发框架
前言: 随着岁月的推进,不知不觉已在.NET这领域上战斗了十年了. 青春还没来得急好好感受,却已是步入健忘之秋的老人一枚了. 趁着还有点记忆,得赶紧把硬盘里那私藏的80G除外的东西,和大伙分享分享. ...
- 探索C#之6.0语法糖剖析
阅读目录: 自动属性默认初始化 自动只读属性默认初始化 表达式为主体的函数 表达式为主体的属性(赋值) 静态类导入 Null条件运算符 字符串格式化 索引初始化 异常过滤器when catch和fin ...
- 【大型网站技术实践】初级篇：借助LVS+Keepalived实现负载均衡
一.负载均衡:必不可少的基础手段 1.1 找更多的牛来拉车吧 当前大多数的互联网系统都使用了服务器集群技术,集群即将相同服务部署在多台服务器上构成一个集群整体对外提供服务,这些集群可以是Web应用服务 ...
- 关于如何提高Web服务端并发效率的异步编程技术
最近我研究技术的一个重点是java的多线程开发,在我早期学习java的时候,很多书上把java的多线程开发标榜为简单易用,这个简单易用是以C语言作为参照的,不过我也没有使用过C语言开发过多线程,我只知 ...
- C# 中参数验证方式的演变
一般在写方法的时候,第一步就是进行参数验证,这也体现了编码者的细心和缜密,但是在很多时候这个过程很枯燥和乏味,比如在拿到一个API设计文档的时候,通常会规定类型参数是否允许为空,如果是字符可能有长度限 ...
- IOS FMDB 获取数据库表和表中的数据
ios开发中,经常会用到数据库sqlite的知识,除了增,删,改,查之外,我们说说如何获取数据库中有多少表和表相关的内容. 前言 跟数据库使用相关的一般的增删改查的语句,这里就不做解释了.在网上有很多 ...
- iOS在导航栏上居中显示分段控件(UISegmentedControl)
UISegmentedControl *segmentedControl = [[UISegmentedControl alloc] initWithItems:nil]; segmentedCont ...
- Form 表单提交参数
今天因为要额外提交参数数组性的参数给form传到后台而苦恼了半天,结果发现,只需要在form表单对应的字段html空间中定义name = 后台参数名 的属性就ok了. 后台本来是只有模型参数的,但是后 ...
- Linux模块编程框架
Linux是单内核系统,可通用计算平台的外围设备是频繁变化的,不可能将所有的(包括将来即将出现的)设备的驱动程序都一次性编译进内核,为了解决这个问题,Linux提出了可加载内核模块(Loadable ...
- 多用多学之Java中的Set，List，Map
很长时间以来一直代码中用的比较多的数据列表主要是List,而且都是ArrayList,感觉有这个玩意就够了.ArrayList是用于实现动态数组的包装工具类,这样写代码的时候就可以拉进 ...