CDH集群所在的服务器,为云服务主机,其中namenode所在的cdh01节点上的磁盘分布如下:
[root@cdh01 sys_disk_mirror]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 40G 28G 9.9G 74% /
devtmpfs 32G 0 32G 0% /dev
tmpfs 32G 0 32G 0% /dev/shm
tmpfs 32G 105M 32G 1% /run
tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/vdb1 500G 169G 331G 34% /data
tmpfs 6.3G 0 6.3G 0% /run/user/0
cm_processes 32G 364M 32G 2% /run/cloudera-scm-agent/process
tmpfs 6.3G 0 6.3G 0% /run/user/998
可以看出,这个文件系统由2块磁盘构成:
①、文件系统/dev/vdb1 对应 /data分区 ;
②、文件系统/dev/vda1 对应 /分区(子分区除/data意外的其他分区);
再查看/根分区下的文件大小组成,如下:
由于前期安装CDH及其周边大数据组件时考虑不周,将所有的日志文件或MySQL存储文件都安装在了/根分区下,随着时间的累积,日志的增大,及MySQL数据库文件的增加,/分区空间大小慢慢变得捉襟见肘,ClouderaManager动辄爆出磁盘空间不足,各大数据组件服务报警之类的异常。
由于CDH集群上主要跑着Hive离线数据计算、 和SparkStreaming实时计算、加上Spark准实时数据分析处理程序,停止大数据组件去做相应的磁盘目录变更操作会造成整体数据的更新迟滞。
故考虑通过动态数据目录切换的方式,来实现/根空间的大小腾挪。
[root@cdh01 /]# du -h / --max-depth=1 * | sort -rn
646M /root
469M /run
200M /CloudResetPwdUpdateAgent
198G /
171M /boot
170G /data
80K /home
35M /etc
16K /lost+found
15G /var
12K /user
6.1G /opt
4.0K /srv
4.0K /mnt
4.0K /media
3.8G /usr
2.3M /CloudrResetPwdAgent
2.0G /tmp
0 /sys
0 /proc
0 /dev
通过对查看磁盘空间,可以看出/空间下,/var 目录 和/opt目录下占据着大量的空间,分别为:
6.1G /opt
15G /var
进一步整理/var空间,发现占用磁盘大小的目录从大到小依次为:
[root@cdh01 var]# du -s * | sort -rn
13380296 lib
1808972 log
127664 cache
1228 spool
20 tmp
20 db
12 www
12 kerberos
8 empty
4 yp
4 preserve
4 opt
4 nis
4 local
4 gopher
4 games
4 crash
4 adm
0 run
0 mail
0 lock
[root@cdh01 lib]# ls
alternatives cloudera-scm-headlamp dhclient hadoop-httpfs hbase kafka machines mysql-keyring os-prober rpcbind sentry sqoop tuned
authconfig cloudera-scm-server flume-ng hadoop-kms hive kudu misc NetworkManager plymouth rpm solr sqoop2 yarn-ce
cloud dav games hadoop-mapreduce impala llama mysql ntp polkit-1 rpm-state spark stateless yum
cloudera-scm-agent dbus hadoop-hdfs hadoop-yarn initramfs logrotate mysql-files oozie postfix rsyslog spark2 systemd zookeeper
可以看出,lib下主要是大数据及系统服务各类软件的库包,因为会经查变化,不太适合做目录的腾挪操作。
那么回头查看/opt目录的组成情况:
[root@cdh01 opt]# du -s * | sort -rn
6299784 cloudera
42728 software
16496 node_exporter
4 cloudera-manager
发现 cloudera 目录占据着6.1G大小的空间:
打开cloudera目录,可看到:
主要是CDH5.16.2在安装过程中,产生的各类repo库、缓存、csd安装文件 及 安装后的包文件(parcels):
[root@cdh01 cloudera]# ll
total 4
drwxr-xr-x 2 cloudera-scm cloudera-scm 71 Mar 3 19:27 csd
drwxr-xr-x 2 cloudera-scm cloudera-scm 306 Mar 3 19:27 parcel-cache
drwxr-xr-x 2 cloudera-scm cloudera-scm 4096 Mar 3 19:27 parcel-repo
drwxr-xr-x 6 cloudera-scm cloudera-scm 178 Mar 3 19:28 parcels
由于大都是一些静态文件,故可以进行整体腾挪,方向为/空间至 /data独立磁盘上:
操作步骤:
①、rsync方式将目标文件夹cloudera 同步至 /data独立磁盘上的 /data/sys_disk_mirror目录下:
备注:格外关注rsync命令的各个参数,特别是-l参数,会将原先文件及其子文件夹中的软链接维持住。
[root@cdh01 opt]# /usr/local/rsync/bin/rsync -zvrPuiogl /opt/cloudera /data/sys_disk_mirror
②、将原文件重命名,并做备份
[root@cdh01 opt]# mv cloudera cloudera_bak_v2021u0303
③、在原先位置/opt下,做软链接
[root@cdh01 opt]# ln -s /data/sys_disk_mirror/cloudera cloudera
④、恢复原先cloudera首层的文件及组权限
备注:内部文件权限已由rsync命令的og参数传递到新目录中
[root@cdh01 opt]# chown -R cloudera-scm:cloudera-scm cloudera
2021-09-22更新:
------------- mysql lib文件夹迁移 --------------
由于/目录下的 “/var/lib/mysql” 空间站到将近15个G(系统盘总计40G), 故考虑将该文件转移至另一块磁盘所在的目录/data/mysql下.
操作步骤如下:
一.前置操作
①、停掉maxwell服务
A). systemctl disable some_service | [修复后再执行]systemctl enable some_service
B). 此mysql的上游应用maxwell在持续向里写数据, 故将6台机器上的maxwell实例全部停掉.
②.停掉CDH组件
C). CDH集群中的CM/hive/hue/kafka/oozie/sentry等组件都在持续向里写数据,故这些组件全部停掉.
注意:
maxwell的退出, 必须要保证maxwell对接的binlog实例先消费完数据, 并成功写入kafka后, 方可执行.故程序必须是"优雅"方式的退出.
这时候可以考虑使用向kill命令传递信号量(这里为程序Main进程ID)的方式:
命令为: kill -TERM 17363
Main进程ID的获取如下:
[root@cdh6 system]# cd /etc/systemd/system/
[root@cdh6 system]# systemctl status maxwell_instance1_etl.service
● maxwell_instance1_etl.service - maxwell instance1_kafka
Loaded: loaded (/etc/systemd/system/maxwell_instance1_etl.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2021-09-18 18:41:29 CST; 9s ago
Main PID: 17363 (java)
CGroup: /system.slice/maxwell_instance1_etl.service
└─17363 java -Xmx27g -Xms15g -Dfile.encoding=UTF-8 -Dlog4j.shutdownCallbackRegistry=com.djdch.log4j.StaticShutdownCallbackRegistry -cp :/data/maxw...
Sep 18 18:41:30 cdh6.hadoop.com maxwell[17363]: ssl.truststore.location = null
Sep 18 18:41:30 cdh6.hadoop.com maxwell[17363]: ssl.truststore.password = null
Sep 18 18:41:30 cdh6.hadoop.com maxwell[17363]: ssl.truststore.type = JKS
Sep 18 18:41:30 cdh6.hadoop.com maxwell[17363]: transaction.timeout.ms = 60000
Sep 18 18:41:30 cdh6.hadoop.com maxwell[17363]: transactional.id = null
Sep 18 18:41:30 cdh6.hadoop.com maxwell[17363]: value.serializer = class org.apache.kafka.common.serialization.StringSerializer
Sep 18 18:41:30 cdh6.hadoop.com maxwell[17363]: 18:41:30,261 INFO AppInfoParser - Kafka version : 1.0.0
Sep 18 18:41:30 cdh6.hadoop.com maxwell[17363]: 18:41:30,261 INFO AppInfoParser - Kafka commitId : aaa7af6d4a11b29d
Sep 18 18:41:30 cdh6.hadoop.com maxwell[17363]: 18:41:30,308 INFO Maxwell - Maxwell v1.22.3 is booting (MaxwellKafkaProducer), starting at Position[...rtbeat=0]
Sep 18 18:41:30 cdh6.hadoop.com maxwell[17363]: 18:41:30,910 INFO MysqlSavedSchema - Restoring schema id 1080048 (last modified at Position[BinlogPo...tbeat=0])
Hint: Some lines were ellipsized, use -l to show in full.
二.mysql文件夹迁移操作
目标:
/var/lib/mysql文件夹迁移到/data/mysql
步骤:
①. 删除原/data/mysql文件夹
安全的方式(子文件夹中有内容删不掉):
rmdir mysql/data
rmdir mysql
②. 关闭mysql进程
systemctl status mysqld
systemctl stop mysqld
systemctl status mysqld
③. 安全拷贝mysql到目标磁盘目录
cd /var/lib/
ll
ls -al
cp -a mysql /data/.
ll
mv mysql mysql.bk
ln -s /data/mysql .
ll
④. 启动mysql进程
systemctl start mysqld
systemctl status mysqld
⑤. 检查mysql是否可用
mysql -h -P -u -p连接访问
⑥. 检查新目录文件夹大小
ll /data/mysql/
du -sh /data/mysql/
⑦. 删除备份文件夹
cd /var/lib
ll
rmdir mysql.bk
rm -rf mysql.bk
⑧. 重新检查磁盘占用(主要是/系统盘空间是否释放)
df -h