diskgenius扩容c盘失败,点中断后，黑屏？

首先强调，没有特殊情况，不要调整硬盘分区，即便调整，也要在专业人员指导下进行，否则硬盘上的数据全部被损毁。

为啥要调整C盘？肯定是空间不够了。为啥空间不够了？垃圾太多了。什么垃圾太多了？微信垃圾太多了，只要删除微信垃圾，硬盘分区空间立刻回来了。

怎么删除微信垃圾？只要删除我的文档目录下的WeChat Files子目录即可。

如果非要调整硬盘空间，就必须选择好调整工具。李大海同志的DiskGenius是首选硬盘分区工具，但是在调整分区上，它不如傲梅分区工具来的简单、可靠、安全。

所以，想要调整硬盘分区，一定要用傲梅分区工具，而不是DiskGenius。

楼主老爷调整分区过程中，强制中断，那么硬盘上的文件可能全部损毁，导致分区表破坏，分区丢失，更别提文件了。

如果有重要文件，那就用DiskGenius恢复文件吧，如果没有，那就用DiskGenius删除所有的分区，重新分区、然后重新安装操作系统吧。

在公司搭建了elk集群，集群配置如下：

由于m21p22服务器配置比较老旧，而且上面还有其他人部署的其他应用。硬盘写入性能比较差，因此考虑吧elasticsearch部署在另外两台配置高的服务器，而将kibana、redis等与硬盘关系不大的软件部署在m21p22服务器。考虑到部署的复杂性以及服务器的实际情况，选择了redis接收beats的日志数据，再通过logstash实现负载均衡。这是之前elk集群的配置情况。

随着业务的深入，上述集群已经越来越难以满足业务的需要，日志量大会在redis中出现堆积，另外服务器查询量大之后，节点的cpu和load会触发告警。因此，与运维部门商议，又申请了2台服务器，作为elasticsearch的扩展节点，以降低原有服务器的负载。

如下是增加服务器之后的配置信息：

在新增加服务器到位之后，第一件事情就是决定将elasticsearch扩容。每台服务器部署2个节点，将原有集群扩大一倍，由4个节点扩大到8个节点。

原有节点：

扩展节点：

按上述配置对新增节点进行扩展，只需要配置好参数：

discovery.zen.ping.unicast.hosts: ["192.168.21.23", "192.168.21.24","192.168.21.88","192.168.21.89"]

新增节点就可以加入集群进行水平扩容。当上述操作都完成之后，新节点已加入集群，开始同步数据。

考虑到系统并未设置索引分片，全部索引一律采用的是系统默认的5个分片，而每个索引的数据可能大小不一，结果检查，决定将数据量较大的索引，分片数增加一倍。

操作如下：

注意，在采取put操作时，先采用get操作，得到_template信息，之后对需要修改的部分进行增加或者修改操作，之后再进行put。这样保证其他不需要修改的数据不会被修改。

在做完上述这一切之后，已是晚上8点，因此打卡下班。

早上还没到单位，就被同事信息轰炸，elk集群已经不能用了！！

我赶到单位之后，连上服务器一看，新加入的节点全部处于假死状态。已经有大部分数据同步到新节点，而且服务器已无法连接。通知运维人员将elasticsearch进程干掉。

如下是恢复的过程中某个节点假死查到的状态：

对上述节点进行重启，集群状态恢复中。。

redis内存在迅速增加，已经达到10个G

查看logstash日志：

出现如下提示：

原来是宕机节点太多，导致部分节点的主分片未分配。这样日志在写入过程中会超时。这就导致logstash的写入速度下降。从而导致redis中数据增加。

至于节点假死的原因，查看了elasticsearch的日志：

发现一个关键的问题：/opt/elasticsearch/node6/data/nodes/0/indices/NP2tORUfSq6jl0lb5CzOVw/2/translog/translog.ckp: Too many open files in system

也就是说同时打开的文件数达到了系统的限制，这也就是无法登陆系统的原因。

不难理解上述问题的出现：一个服务器中配置了两个节点，这两个节点都运行在elastic用户下，该用户所在系统的limit.conf中对该用户同时打开的文件数有限制。而在集群同步数据的过程中，系统在大量的写文件，同时实时数据又在大量写入。这样就导致文件达到最大的阈值。因此导致elasticsearch假死。

查询elasticsearch节点状态：

当天需要写入数据的索引，也存在部分分片未分配状态：

通过kibana也可发现该问题：

考虑到redis缓存一直增加，当务之急是让数据可以写入。保证redis的数据被消费。否则会出现redis服务器内存溢出。

先不考虑elasticsearch是否能自动恢复，以及自动恢复所花费的时间。

查询API后，要用到命令：reroute

通过kibana分配一个主分片

命令格式参考 https://kibana.logstash.es/content/elasticsearch/principle/shard-allocate.html

需要注意的是，对于主分片执行reroute，一定需要所分配的节点上存在该索引的文件，否则会提示找不到索引：

在分配主分片的时候，一定要确认所分配的节点是否存在该索引的文件。

上述问题 虽然恢复，数据可以写入，但是还有几个地方需要优化：

1.redis作为负载均衡存在问题，在服务器节点充足之后，应该用kafka来替代redis，将数据放置在磁盘。避免redis内存溢出。

2.elasticsearch扩容时，如果有多个节点，尽量避免同时操作。如果一次性增加的节点比较多，就需要考虑文件是否达到最大limit配置的阈值。

根据微博官方系统的回应微博突然宕机的原因是自动扩容系统故障导致的，从而导致了移动端访问异常，PC端还是可以正常访问的。自动扩容系统简单的说就是计算机的服务器在运行的过程中数据请求突然增加，为了让计算机更加稳定的运行，通过相关的程序自动的调整服务器的数量和配置。

自动扩容系统的产生。服务器的自动扩容是服务器领域比较常见的技术和重要的技术。服务器在使用的过程中会遇到服务器数量不足，存储空间不足，带宽不足，计算能力不足的情况，这种情况下就需要进行扩容。服务器的扩容比PC机复杂很多，除了硬件配置以外，还需要通过软件系统配置，但是软件系统和自动扩容系统之间还是存在比较大的差异。服务器系统中如果安装比较多的软件系统，会让服务器的性能下降，服务器的管理员对其管理的难度增加。所以将所有的配置和软件功能综合到一个系统中，并充分考虑服务的稳定性和扩展性后，自动扩容系统也就诞生了。

自动扩容系统的用处。随着互联网行业的快速发展，服务器的访问量开始大幅度的提升。为了让服务器能够稳定的运行。传统的做法通过管理员进行实时轮班监控，遇到问题立刻进行修复和处理，如果遇到需要扩容的情况，直接进行人工调配。但是这样的做法无形中增加了企业用工成本，而且服务器存在延迟，很容易造成系统被数据请求拖垮，这就是行业中经常说的宕机。自从有了自动扩容系统后，不但反应时间加快。管理人员只需要对系统进行实时监控，监控的方法可以进行远程控制，大大降低了人员成本，安全性也得到了保证。

---