192.168.10.56 -> 192.168.10.11
192.168.10.57 -> 192.168.10.12
# 新建hadoop用户和组
sudo groupadd hadoop
sudo useradd -d /home/hadoop/ -g hadoop hadoop
# 修改密码
passwd hadoop
# 新建mysql用户和组，不指定home目录
sudo groupadd mysql
useradd -g mysql mysql -s /sbin/nologin
passwd mysql
mysql
vim /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072
针对普通用户，还需要修改：/etc/security/limits.d/20-nproc.conf
* soft nproc 131072
root soft nproc unlimited
vim /etc/selinux/config
# 临时关闭
setenforce 0
# 永久关闭
将SELINUX=enforcing 更改为 SELINUX=disabled
yum install ntp
root账号添加定时同步
0 */1 * * * /usr/sbin/ntpdate cn.pool.ntp.org >>/root/ntpdate.log 2>&1
准备rpm安装包，使用root账号，然后分别安装在11,12服务器上：
## 先卸载自带的mariadb
rpm -e --nodeps mariadb-libs-5.5.68-1.el7.x86_64
##再安装
rpm -ivh 01_mysql-community-common-5.7.29-1.el7.x86_64.rpm
rpm -ivh 02_mysql-community-libs-5.7.29-1.el7.x86_64.rpm
rpm -ivh 03_mysql-community-libs-compat-5.7.29-1.el7.x86_64.rpm
rpm -ivh 04_mysql-community-client-5.7.29-1.el7.x86_64.rpm
rpm -ivh 05_mysql-community-server-5.7.29-1.el7.x86_64.rpm
1）文件权限问题
需要在root账号下操作，拷贝完源文件后，需要修改为mysql用户和组。
2）如果拷贝的文件启动报错，不是因为权限的原因，可以使用初始化命令，先初始化MySQL启动。然后再拷贝数据库文件。
由于之前开启了binlog，并没有设置binlog的保留天数，日志文件数据量特别大，于是使用了下面两种方式清理历史的日志文件。
purge binary logs to ‘mysql-bin.009560’;
purge binary logs before ‘2022-01-01 23:59:59’;
执行上面的清理任务后，将剩余的文件直接拷贝到新机器，发现启动MySQL日志错误，一直启动不起来。
最后通过重新初始化后，将MySQL启动。然后拷贝已有的数据库文件，来解决binlog日志的问题。
mysqld --initialize --console
3）my.cnf配置参考
datadir=/data/mysql
socket=/var/lib/mysql/mysql.sock
explicit_defaults_for_timestamp=true
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
# explicit_defaults_for_timestamp=true
max_connections=1500
max_connect_errors=10
character_set_server=utf8
innodb_read_io_threads=10
innodb_write_io_threads=30
max_allowed_packet=1G
# 跳过所有错误
slave-skip-errors=all
innodb_force_recovery=6
log-bin=mysql-bin
server-id=201
binlog_format=row
binlog-do-db=bigdata
# 必须为FULL，MySQL-5.7后才有该参数
binlog_row_image=FULL
expire_logs_days=15
#sql_mode
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
[client]
socket=/var/lib/mysql/mysql.sock
16:50-17:50点会进行大数据集群主节点的迁移，
影响hive相关的所有服务，包括flink写iceberg，trino查询的相关操作。
涉及到hive的元数据库迁移，trino主节点的迁移，
zookeeper组件的服务:
hadoop集群的相关服务：
数据库相关的服务：
由于服务存在相关依赖性,按照从前到后的顺序启动，需要依次为：
zookeeper > JournalNode > NameNode = ResourceManager
目前已有3个节点的JournalNode，下线一个再上线后，如果有异常，参考以下解决。
https://blog.51cto.com/u_15346267/3668885
操作步骤：
(1) 停止zookeeper服务 zkServer.sh stop
zkServer.sh stop
(2) 停止JournalNode服务
hadoop-daemon.sh stop journalnode
(3)停止NameNode服务
hadoop-daemon.sh stop namenode
(4) 停止ResourceManager服务
yarn-daemon.sh stop resourcemanager
(5) 停止Hive服务
ps -ef|grep hive
kill
(6) 停止MySQL服务(root账号)
systemctl stop mysqld
(7) 停止Trino服务(57服务器)
./launch stop
hadoop账号拷贝以下目录:
# 拷贝/home/hadoop目录
/home/hadoop/.ssh
scp -r /home/hadoop/* hadoop@192.168.10.11:/home/hadoop/
# 拷贝/opt/name目录
scp -r /opt/name/* hadoop@192.168.10.11:/opt/name/
修改mysql的配置，添加innodb_force_recovery=6
# mysql数据库拷贝
scp -r ibdata1 ib_logfile0 ib_logfile1 ibtmp1 ib_buffer_pool information_schema MDPS SUBGRAPH TRADE V3DATA bigdata hive log logi_kafka_manager mysql performance_schema pid sys root@192.168.10.12:/data/mysql/
scp -r ibdata1 ib_logfile0 ib_logfile1 ibtmp1 ib_buffer_pool information_schema MDPS SUBGRAPH TRADE V3DATA bigdata hive log logi_kafka_manager mysql performance_schema pid sys root@192.168.10.11:/data/mysql/
(1) 启动MySQL，并验证
通知运维修改IP地址，重启服务器。
(1) 重启MySQL, 并验证
(2) 启动zk,并验证
(3) 启动JournalNode,并验证
(4) 启动NameNode,并验证
(5) 启动ResourceManager,并验证
(6) 启动Hive,并验证
(7) 启动Trino,并验证
尽管之前做了很多准备和测试工作，但是在迁移过程中还是发生了很多意想不到的问题。
（1）某个文件夹下日志过于大，170w个文件，拷贝花费了很久。
（2）56机器节点做了防火墙等验证发现是关闭的，但是57没看了，结果57上居然有防火墙开着，导致mysql外部链接一直存在着问题。
因为这个问题，导致多次重启服务，发现dbveaver一只堵住无法连接。直接早上同事提醒时，才去看了看发现真有防火墙开着。
（3）直接拷贝原有机器上的.ssh，导致其他datanode的节点和新的name节点通信时，一只提示以下错误。然后只能手工一个个去做ssh-keygen -R "192.168.10.57"命令。
这个建议下次可以直接在新节点上重新生成ssh，做免密了，不使用旧的可能更简单点。
（4）环境变量复制粘贴出现遗漏了。
（5）因为mysql连接在57上一直出现故障，所以拿原有的机器上的数据库备份，然后做恢复到56上。这个恢复占用了很大时间。
（6）zk的服务必须从最小的数字启动到最大的数字，恰好我迁移的节点上有个2个最小的节点数字，导致最小的那个数字没启动起来，所以目前有4个zk在服务了，据说3.5以上版本会解决以上问题。
（7）发现hive-site.xml中HA模式配置的ZK节点有错误的节点，属于历史更换时，未修改到位。
（8）原有的yarn-site.xml都是超配的，一直没有根据每个节点的不同配置去修改。
总之问题很多，以后做事的时候还需要非常的细心，有部分是自己粗心大意。
这是由于使用了旧的机器上的.ssh文件，当时直接拷贝过来的，错误如下：
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:LXB7o2TU/rkL3OfYtltEdvlC8WoKPxAh4HOs2MfFetg.
Please contact your system administrator.
Add correct host key in /home/hadoop/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/hadoop/.ssh/known_hosts:37
ECDSA host key for cdh192-57 has changed and you have requested strict checking.
Host key verification failed.
[hadoop@cdh192-56 ~]$
解决方案也相对简单，使用下面命令替换know_hosts，然后需要重新ssh，第一次需要输入yes的。
ssh-keygen -R "192.168.10.57"
ssh-keygen -R "192.168.10.56"
以下是全量备份命令
# 全量备份
/usr/bin/mysql -uroot -proot < /home/all_db_20220915.sql
# 全量恢复
/usr/bin/mysql -uroot -proot < /home/all_db_20220915.sql
如果需要放后台执行，将上面命令放到shell脚本中，比如backup.sh,
然后nohup ./backup.sh 2>&1 &
nginx默认是轮询策略，如果一些请求执行耗时很长，某些很短，很不均匀，就会导致各个节点请求占用时间不一致，采用轮询并不是一个好的策略。
least_conn 使用最小连接可以使分发更均衡一点。这个是在hive使用nginx做负载均衡时可以调整的策略，以下为样例配置。
stream{
log_format basic '$remote_addr [$time_local] ' '$protocol $status $bytes_sent $bytes_received' '$session_time';
upstream hiveserver2 {
least_conn; #路由策略:least_conn:最少连接
server cdh01.xx.com:10000;
server cdh01.xx.com:10000;
}
server{ #hiveserver2 jdbc 负载均衡
listen 10010;
proxy_pass hiveserver2;
}
}
如果机器配置不同，则需要根据具体的机器情况，修改对影的配置。
这里涉及到cpu核数、内存大小、任务中间结果目录大小、用户任务的日志存放目录大小
yarn.nodemanager.resource.cpu-vcores： 单节点最大的可用核数，比如72核，设置70，预留2个给系统使用。这里假如系统只有72核，你即使配置了100也不会有任何异常，但是超配了。
yarn.nodemanager.resource.memory-mb：单节点最大可用内存数，比如512G，设置496G，预留16G给系统使用。这里也可以超配，系统不会报异常。
yarn.nodemanager.local-dirs：中间结果存放目录，当shuffle数据较大时，需要写磁盘，如果空间预留不足，当该节点空间少于10%时，将会自动下架datanode服务。
yarn.nodemanager.log-dirs： 任务日志目录，同上，如果空间预留不足，当该节点空间少于10%时，将会自动下架datanode服务。
具体参考下面：
<property>
<description>Number of vcores that can be allocated
for containers. This is used by the RM scheduler when allocating
resources for containers. This is not used to limit the number of
physical cores used by YARN containers.description>
<name>yarn.nodemanager.resource.cpu-vcoresname>
<value>70value>
property>
<property>
<name>yarn.nodemanager.resource.memory-mbname>
<value>508723value>
property>
<property>
<name>yarn.nodemanager.local-dirsname>
<value>/dfs/data1/nm-local-dir/,/dfs/data2/nm-local-dir/,/dfs/data2/nm-local-dir/,/dfs/data3/nm-local-dir/,/dfs/data4/nm-local-dir/,/dfs/data5/nm-local-dir/,/dfs/data6/nm-local-dir/,/dfs/data7/nm-local-dir/,/dfs/data8/nm-local-dir/,/dfs/data9/nm-local-dir/,/dfs/data10/nm-local-dir/value>
property>
<property>
<name>yarn.nodemanager.log-dirsname>
<value>/dfs/data1/userlogs/,/dfs/data2/userlogs/,/dfs/data2/userlogs/,/dfs/data3/userlogs/,/dfs/data4/userlogs/,/dfs/data5/userlogs/,/dfs/data6/userlogs/,/dfs/data7/userlogs/,/dfs/data8/userlogs/,/dfs/data9/userlogs/,/dfs/data10/userlogs/value>
property>
查看CPU的核数：
cat /proc/cpuinfo| grep 'processor'|wc -l