运维 – gitweixin

Docker 6月 12,2025

docker服务器：connect to host cdh04 port 22: No route to host 分析并解决

🔍 一、排查思路总览

确认目标主机（cdh04）是否运行正常
确认目标主机的 Docker 容器是否运行并绑定了 SSH 端口
确认网络配置是否通
确认 SSH 服务是否正常监听并运行
确认防火墙和安全组设置

🧪 二、详细排查步骤

✅ 1. Ping 主机名是否能通（DNS or Hosts 问题）

ping cdh04

如果提示：ping: unknown host cdh04
- 说明主机名无法解析，检查 /etc/hosts 或 DNS。
如果提示：Destination Host Unreachable
- 说明网络层面有问题，继续往下查。

✅ 2. 确认是否为 Docker 容器内部主机

如果你是用 Docker 模拟 CDH 集群，那么 cdh04 可能是某个容器的别名。可通过以下命令确认：

docker ps -a | grep cdh04

如果找不到：

容器可能没有启动；
容器网络未配置正确；
或者该容器已崩溃。

可用以下命令查看网络：

docker network ls docker network inspect <网络名>

✅ 3. 检查容器是否监听 22 端口

进入宿主机，检查容器绑定端口：

docker inspect cdh04 | grep -A 5 "PortBindings"

确认是否有：

"22/tcp": [   {     "HostPort": "2222"   } ]

表示你需要用 ssh -p 2222 用户名@宿主机IP 才能访问，而不是直接 ssh cdh04。

✅ 4. 检查 SSH 服务是否运行

进入容器：

docker exec -it cdh04 bash

确认：

ps -ef | grep sshd

如果没有：

service ssh start

或者：

/etc/init.d/ssh start

还可以查看日志：

cat /var/log/auth.log

✅ 5. 容器网络是否正常（重要）

查看容器网络是否被桥接成功：

docker network inspect bridge

容器是否有 IP：

docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' cdh04

从宿主机 ping 容器 IP：

ping <容器IP>

如果 ping 不通，可以尝试重启容器网络：

systemctl restart docker

或使用：

docker network rm <网络名>  # 慎用，确认后使用 docker network create ...

✅ 6. 防火墙与安全设置

查看 iptables（或 firewalld）是否阻拦了：

iptables -L -n | grep 22

或者：

systemctl status firewalld

临时关闭测试：

systemctl stop firewalld iptables -F

💡 三、常见问题与建议

问题	原因	解决方式
`No route to host`	宿主机到容器路由不通	检查容器网络、端口映射
`Connection refused`	容器未运行 SSH 服务或未监听 22 端口	启动 ssh 服务，检查监听端口
ping 不通容器	Docker 网络异常	重建 docker 网络或检查 bridge 网络配置
容器无法被主机名访问	`/etc/hosts` 缺失或 DNS 配置错误	添加主机映射或使用容器 IP

作者 east

运维 4月 18,2025

centos服务器如何查看是 x64(avx2)、x64(no avx2)还是arm64

要判断 CentOS 服务器 是 x86_64（支持 AVX2 / 不支持 AVX2） 还是 ARM64 架构，可以使用以下命令组合来精准确认架构类型及 AVX 指令集支持情况。

✅ 一、查看 CPU 架构（x86_64 vs aarch64）

bashCopyEdituname -m

输出示例：

x86_64 👉 表示是 Intel/AMD 架构（64位）
aarch64 👉 表示是 ARM 架构（64位 ARM）

✅ 二、进一步查看是否支持 AVX2 指令集

bashCopyEditcat /proc/cpuinfo | grep -m 1 flags

或者（更加清晰地只看 AVX 相关的）：

bashCopyEditcat /proc/cpuinfo | grep -m 1 flags | grep -o 'avx[^ ]*'

如果输出中包含：

avx：支持 AVX
avx2：支持 AVX2
avx512f 等：支持 AVX-512（极少数高端 CPU）

✅ 三、使用 `lscpu` 更清晰（推荐）

bashCopyEditlscpu

输出示例中关注两行：

bashCopyEditArchitecture:        x86_64       # 架构
Flags:               ... avx avx2 ...  # 支持指令集

🧠 最终判断表格：

uname -m	Flags 中包含 AVX2	判断结果
x86_64	有 avx2	x64（支持 AVX2） ✅
x86_64	无 avx2	x64（无 AVX2）⚠️
aarch64	–	ARM64（不支持 AVX2）❌

🚀 快速一键命令总结：

bashCopyEditecho "架构: $(uname -m)"; lscpu | grep -i 'avx'

作者 east

bug清单, 运维 3月 23,2025

解决Error: /usr/lib64/libc.so.6: version `GLIBC_2.18′ not found

在centos运行node应用，分析下面报错并给出解决方案：node:internal/modules/cjs/loader:1282 return process.dlopen(module, path.toNamespacedPath(filename)); ^ Error: /usr/lib64/libc.so.6: version `GLIBC_2.18′ not found (required by /home/wwwroot/gitweixin/tool/svg2jpgApi/node_modules/canvas/build/Release/librsvg-2.so.2) at Object.Module._extensions..node (node:internal/modules/cjs/loader:1282:18) at Module.load (node:internal/modules/cjs/loader:1076:32) at Function.Module._load (node:internal/modules/cjs/loader:911:12) at Module.require (node:internal/modules/cjs/loader:1100:19) at require (node:internal/modules/cjs/helpers:119:18) at Object.<anonymous> (/home/wwwroot/gitweixin/tool/svg2jpgApi/node_modules/canvas/lib/bindings.js:3:18) at Module._compile (node:internal/modules/cjs/loader:1198:14) at Object.Module._extensions..js (node:internal/modules/cjs/loader:1252:10) at Module.load (node:internal/modules/cjs/loader:1076:32) at Function.Module._load (node:internal/modules/cjs/loader:911:12) { code: ‘ERR_DLOPEN_FAILED’

在CentOS上运行Node应用时遇到的GLIBC版本问题，可以通过以下步骤解决：

错误分析

根本原因：应用依赖的canvas模块需要GLIBC_2.18，但当前系统的GLIBC版本过低（如CentOS 7默认使用GLIBC 2.17）。
影响：系统缺失所需GLIBC版本，导致Node无法加载原生模块（librsvg-2.so.2）。

解决方案

方法1：重新构建`canvas`模块（推荐优先尝试）

安装构建依赖：bash复制sudo yum install -y gcc-c++ cairo cairo-devel libjpeg-turbo-devel pango pango-devel giflib-devel
重新编译canvas：bash复制# 删除现有模块并重新安装 rm -rf node_modules npm install
- 如果问题依旧，尝试强制重建原生模块：bash复制npm rebuild canvas –update-binary

方法2：升级GLIBC（谨慎操作）

警告：升级GLIBC可能导致系统不稳定，仅建议在测试环境中使用。

下载并编译GLIBC 2.18：bash复制# 安装依赖 sudo yum install -y bison make gcc # 下载源码 wget http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.gz tar -xzf glibc-2.18.tar.gz cd glibc-2.18 # 编译安装（指定目录避免覆盖系统文件） mkdir build && cd build ../configure –prefix=/opt/glibc-2.18 make -j4 sudo make install
临时指定GLIBC路径运行Node应用：bash复制LD_LIBRARY_PATH=/opt/glibc-2.18/lib node your-app.js

方法3：使用Docker容器（推荐生产环境）

通过Docker隔离环境，避免修改宿主机GLIBC。

创建Dockerfile：Dockerfile复制FROM centos:7 # 安装依赖 RUN yum install -y gcc-c++ cairo cairo-devel libjpeg-turbo-devel pango pango-devel giflib-devel # 安装Node.js RUN curl -sL https://rpm.nodesource.com/setup_14.x | bash – RUN yum install -y nodejs # 复制应用代码 WORKDIR /app COPY package*.json ./ RUN npm install COPY . . CMD [“node”, “your-app.js”]
构建并运行容器：bash复制docker build -t node-app . docker run -it –rm node-app

方法4：使用第三方仓库（如SCL）

CentOS 7可通过Software Collections（SCL）获取较新工具链。

启用SCL仓库：bash复制sudo yum install -y centos-release-scl
安装高版本开发工具链：bash复制sudo yum install -y devtoolset-8
使用新工具链编译应用：bash复制scl enable devtoolset-8 bash rm -rf node_modules npm install

总结建议

推荐方案：优先尝试方法1（重新构建）或方法3（Docker），避免直接升级GLIBC的风险。
生产环境：强烈建议使用Docker容器化部署，确保环境一致性。
备用方案：若必须升级GLIBC，务必在测试环境中验证稳定性。

作者 east

Hive, 运维 8月 15,2024

运行sqoop出错：Missing argument for option: username


sqoop export \
--connect  jdbc:mysql://$host:3306/zgcn?characterEncoding=UTF-8 \
--username $user \
--password $pwd \
-m 1 \
...

运行报错：
Missing argument for option: username

从错误日志来看，Sqoop 报错是因为缺少了 --username 参数的值。这通常意味着 $user 变量没有被正确设置或者在传递给 Sqoop 命令时出现了问题。

分析原因

变量未定义：确保 $user 变量已经被定义并且具有正确的值。
变量未正确传递：如果 $user 是通过环境变量或者其他脚本设置的，需要确保它能被当前执行 Sqoop 的 shell 脚本访问到。
语法错误：检查是否有任何语法错误导致变量展开失败。

完整解决方案

1. 检查变量定义

确保 $user 变量已经正确地定义并且包含了正确的数据库用户名。例如，在 shell 脚本中可以这样定义：

Bash深色版本1user="your_username"

2. 使用双括号进行变量展开

为了避免 shell 执行时的变量展开问题，可以使用双括号 {{ }} 进行变量展开（虽然在 bash 中这不是必需的，但在某些情况下这样做可以避免问题）：

Bash深色版本1--username {{ $user }}

3. 在脚本中直接定义变量

为了确保变量正确传递给 Sqoop 命令，可以在脚本中直接定义这些变量：

#!/bin/bash

# 假设这些变量是从外部传入的或者通过其他方式获取
host="your_host"
user="your_username"
pwd="your_password"
yesday_date="20240814" # 假设昨天的日期是这个值

# 定义其他必要的变量

# Sqoop export 命令
sqoop export \
--connect jdbc:mysql://$host:3306/zgcn?characterEncoding=UTF-8 \
--username $user \
--password $pwd \
...

Bash深色版本1#!/bin/bash
2
3# 假设这些变量是从外部传入的或者通过其他方式获取
4host="your_host"
5user="your_username"
6pwd="your_password"
7yesday_date="20240814" # 假设昨天的日期是这个值
8
9# 定义其他必要的变量
10
11# Sqoop export 命令
12sqoop export \
13--connect jdbc:mysql://$host:3306/zgcn?characterEncoding=UTF-8 \
14--username $user \
15--password $pwd \
16...

4. 检查其他变量

同样，也需要检查 $host, $pwd, 和 $yesday_date 等变量是否都已正确设置。

5. 添加调试信息

为了更好地诊断问题，可以在脚本中添加一些调试输出语句，例如使用 echo 输出变量的值：

echo "Using host: $host"
echo "Using user: $user"
echo "Using password: $pwd"
echo "Using yesday_date: $yesday_date"

Bash深色版本1echo "Using host: $host"
2echo "Using user: $user"
3echo "Using password: $pwd"
4echo "Using yesday_date: $yesday_date"

总结

确认所有必需的变量都已经定义且赋值。
确保变量值正确无误。
使用双括号进行变量展开（可选）。
添加调试输出帮助诊断问题。

重新运行脚本后，如果仍然遇到问题，请检查数据库连接信息和其他配置是否正确。如果问题依旧存在，请提供更多关于脚本的上下文信息以便进一步排查。

作者 east

运维 8月 2,2024

笔记本电脑设备管理器找不到以太网适配器的原因分析和解决方案

可能的原因：

驱动程序问题：适配器的驱动程序可能已损坏、过时或未正确安装。
硬件故障：适配器本身可能存在物理损坏。
配置问题：BIOS/UEFI设置可能禁用了以太网适配器。
操作系统问题：系统文件损坏或者不兼容。
连接问题：适配器可能没有正确连接到主板上。
电脑没有配置：有的没有网口的笔记本电脑是没有以太网卡的，需要通过扩展坞来访问，可以具体咨询电脑厂商的技术支持。

解决方案：

重启电脑：有时候简单的重启就能解决问题。
检查硬件连接：
- 如果是可拆卸的笔记本，尝试重新插入适配器模块。
- 检查适配器的物理连接是否松动。
检查BIOS/UEFI设置：
- 重启电脑并进入BIOS/UEFI设置（通常按F2、F10、Del等键）。
- 查找与网络相关的设置，并确保以太网适配器没有被禁用。
- 保存更改并退出。
更新或重新安装驱动程序：
- 打开“设备管理器”，找到“网络适配器”类别。
- 如果适配器显示为灰色，右击它选择“启用设备”。
- 如果适配器列表为空，尝试右击空白处选择“扫描检测硬件改动”。
- 如果适配器出现但有黄色感叹号，右击它选择“更新驱动程序”。
- 如果无法自动更新，访问制造商网站下载最新驱动程序并手动安装。
使用系统还原：
- 如果您之前创建了系统还原点，可以尝试回滚到一个较早的时间点。
- 开始菜单 > “控制面板” > “系统和安全” > “系统” > “系统保护” > “系统还原”。
检查操作系统问题：
- 使用Windows自带的故障排除工具进行诊断。
- 运行命令提示符作为管理员，输入sfc /scannow来检查和修复系统文件。
专业维修：
- 如果以上方法都无法解决问题，可能是硬件故障，需要专业的技术支持人员检查。

作者 east

运维 8月 2,2024

联想笔记本电脑用了扩展坞不到以太网适配器原因分析及解决方案

可能的原因：

扩展坞问题：扩展坞本身可能存在问题，如硬件故障或不兼容。
驱动程序问题：扩展坞所需的驱动程序可能未正确安装或已损坏。
连接问题：Type-C接口或线缆可能存在接触不良或故障。
系统设置问题：某些系统设置可能会导致适配器不可见。
BIOS/UEFI设置问题：BIOS/UEFI中的某些设置可能会影响扩展坞的功能。
操作系统的兼容性问题：您的操作系统可能不完全支持扩展坞上的以太网适配器。

解决方案：

检查扩展坞和线缆：
- 确保Type-C线缆和扩展坞之间的连接牢固且无损。
- 尝试更换Type-C线缆或使用不同的Type-C端口。
- 确认扩展坞上的以太网接口指示灯是否正常工作。
检查驱动程序：
- 访问联想官网，查找适用于您笔记本型号和扩展坞的最新驱动程序。
- 下载并安装最新的以太网适配器驱动程序。
- 如果扩展坞附带有驱动程序或软件，请确保它们也被正确安装。
检查BIOS/UEFI设置：
- 重启电脑并进入BIOS/UEFI设置。
- 检查与USB或Type-C端口相关的设置，确保它们处于启用状态。
- 保存更改并退出。
系统故障排除：
- 在“设备管理器”中，展开“网络适配器”类别，查看是否能看到通过扩展坞连接的适配器。
- 如果看到适配器但有黄色警告标志，尝试更新驱动程序或禁用后重新启用适配器。
- 如果适配器完全不可见，尝试“扫描检测硬件改动”来刷新设备列表。
运行Windows故障排除工具：
- 打开“设置” > “更新与安全” > “故障排除”。
- 寻找“以太网连接”或“网络适配器”的故障排除选项并运行它。
检查操作系统版本：
- 确保您的操作系统是最新的，并且安装了所有必要的更新。
尝试其他扩展坞或电脑：
- 将扩展坞连接到另一台电脑上测试，看是否能正常工作。
- 将另一台已知工作的扩展坞连接到您的笔记本电脑上，确认是否能识别以太网适配器。

如果上述步骤都不能解决问题，建议通过联想官方网站联系联想的技术支持获取更进一步的帮助。他们可能会建议您进行更深入的硬件检查或提供具体的解决方案。

作者 east

运维 7月 25,2024

解决aide严重影响大数据计算时间问题

大数据离线数仓上线后，由于源头数据倍增到几十亿，发现有的耗时任务跑了几个小时也跑不出结果。明明服务器配置不错，计算内存也还可以。调大计算资源内存后也发现无济于事。

后来发现服务器有aide在运行，严重影响磁盘IO。

iotop -oP
Total DISK READ : 234.02 M/s | Total DISK WRITE : 27.09 M/s
Actual DISK READ: 238.46 M/s | Actual DISK WRITE: 11.52 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND

49757 be/4 unbound 239.94 K/s 0.00 B/s 0.00 % 99.99 % du -sk /data/dfs/dn/current/BP-1594034144-10.0.0.1-1704683739059
33597 be/4 root 7.50 M/s 0.00 B/s 0.00 % 83.99 % aide –check
54216 be/4 root 9.19 M/s 0.00 B/s 0.00 % 83.77 % aide –check
13435 be/4 root 1622.13 K/s 0.00 B/s 0.00 % 83.35 % aide –check
7996 be/4 root 3.06 M/s 0.00 B/s 0.00 % 82.80 % aide –check
25673 be/4 root 8.77 M/s 0.00 B/s 0.00 % 82.68 % aide –check
25721 be/4 root 9.50 M/s 0.00 B/s 0.00 % 81.80 % aide –check
60644 be/4 root 2.11 M/s 0.00 B/s 0.00 % 81.00 % aide –check
44128 be/4 root 10.46 M/s 0.00 B/s 0.00 % 80.85 % aide –check
3670 be/4 root 10.14 M/s 0.00 B/s 0.00 % 80.18 % aide –check
38900 be/4 root 3.06 M/s 0.00 B/s 0.00 % 79.62 % aide –check
46920 be/4 root 9.72 M/s 0.00 B/s 0.00 % 79.49 % aide –check
36099 be/4 root 10.14 M/s 0.00 B/s 0.00 % 79.35 % aide –check
32724 be/4 root 10.46 M/s 0.00 B/s 0.00 % 79.04 % aide –check
21047 be/4 root 9.50 M/s 0.00 B/s 0.00 % 78.96 % aide –check
51881 be/4 root 12.46 M/s 0.00 B/s 0.00 % 77.87 % aide –check
13147 be/4 root 10.77 M/s 0.00 B/s 0.00 % 77.56 % aide –check
36436 be/4 root 10.56 M/s 0.00 B/s 0.00 % 77.34 % aide –check

原来， AIDE 是一款入侵检测工具，它的作用是监控文件系统的完整性，防止未经授权的更改。听起来很不错，对吧？但问题就出在这里。AIDE 在工作时，需要频繁地读取和比对磁盘上的大量文件信息，这就导致了磁盘 IO 操作的大幅增加。

而大数据计算过程，如果内存不够时，需要缓存到磁盘，这时AIDE占用了大量磁盘IO，就会严重拖慢整个大数据计算的进度。

不运行AIDE后，发现耗时的离线计算运行时间缩短为之前的几分之一。

作者 east

Kafka, 运维 6月 27,2024

CDH6.3.2一台服务器宕机后kafka集群无法选举leader

cdh6.3.2集群有一台服务器宕机了，重新恢复后，发现kafka集群无法正常启动，报错日志如下，其中 TopicRunData 是kafka消费的topic。

1、错误分析

[Controller id=469 epoch=67] Controller 469 epoch 67 failed to change state for partition TopicRunData-2 from OfflinePartition to OnlinePartition kafka.common.StateChangeFailedException: Failed to elect leader for partition
TopicRunData -2 under strategy OfflinePartitionLeaderElectionStrategy at kafka.controller.PartitionStateMachine$$anonfun$doElectLeaderForPartitions$3.apply(PartitionStateMachine.scala:390) at kafka.controller.PartitionStateMachine$$anonfun$doElectLeaderForPartitions$3.apply(PartitionStateMachine.scala:388) at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59) at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48) at kafka.controller.PartitionStateMachine.doElectLeaderForPartitions(PartitionStateMachine.scala:388) at kafka.controller.PartitionStateMachine.electLeaderForPartitions(PartitionStateMachine.scala:315) at kafka.controller.PartitionStateMachine.doHandleStateChanges(PartitionStateMachine.scala:225) at kafka.controller.PartitionStateMachine.handleStateChanges(PartitionStateMachine.scala:141) at kafka.controller.PartitionStateMachine.triggerOnlinePartitionStateChange(PartitionStateMachine.scala:123) at kafka.controller.PartitionStateMachine.triggerOnlinePartitionStateChange(PartitionStateMachine.scala:109) at kafka.controller.KafkaController.kafka$controller$KafkaController$$onBrokerStartup(KafkaController.scala:382) at kafka.controller.KafkaController$BrokerChange$.process(KafkaController.scala:1318) at kafka.controller.ControllerEventManager$ControllerEventThread$$anonfun$doWork$1.apply$mcV$sp(ControllerEventManager.scala:94) at kafka.controller.ControllerEventManager$ControllerEventThread$$anonfun$doWork$1.apply(ControllerEventManager.scala:94) at kafka.controller.ControllerEventManager$ControllerEventThread$$anonfun$doWork$1.apply(ControllerEventManager.scala:94) at kafka.metrics.KafkaTimer.time(KafkaTimer.scala:31) at kafka.controller.ControllerEventManager$ControllerEventThread.doWork(ControllerEventManager.scala:93) at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:82)

从提供的错误信息来看，Kafka Broker中存在4个离线分区（offline partitions），并且在尝试将其中一个分区
TopicRunData -2从OfflinePartition状态转换到OnlinePartition状态时失败了。具体原因是未能为该分区选举出领导者（leader）。这个异常是由kafka.common.StateChangeFailedException引发的，并指出在使用OfflinePartitionLeaderElectionStrategy策略下无法选出分区领导者。

结合上面的场景，这是由于服务器宕机造成分区的数据不完整或元数据损坏。

使用kafka-topics.sh命令检查主题状态：

kafka-topics.sh --describe --topic TopicRunData --bootstrap-server cdh01:9092

看到信息如下：

Topic:TopicRunData	PartitionCount:3	ReplicationFactor:1	Configs:min.insync.replicas=1,segment.bytes=1073741824,retention.ms=604800000,max.message.bytes=1000000,min.cleanable.dirty.ratio=0.5,unclean.leader.election.enable=false,retention.bytes=-1,delete.retention.ms=604800000
Topic: TopicRunData	Partition: 0	Leader: 299	Replicas: 299	Isr: 299
Topic: TopicRunData	Partition: 1	Leader: 384	Replicas: 384	Isr: 384
Topic: TopicRunData	Partition: 2	Leader: none	Replicas: 298	Isr:

这意味着每个分区的数据只在一个broker上保存，没有副本。这样如果该broker发生故障，相应的分区数据将不可用，从而影响到数据的高可用性。通常建议至少设置Replication Factor为3以确保高可用。可惜之前由于存储压力等原因只有1个副本。

分区2显示没有Leader（Leader: none），且ISR（In-Sync Replicas）列表为空。这表明分区2目前处于未分配状态，可能是由于负责该分区的broker（Replicas: 298）出现故障或者与ZooKeeper的通信出现问题。这种情况下，该分区的数据无法被消费或生产

2、手动选举leader

为
TopicRunData 主题中无leader的分区手动分配并重新选举leader。执行以下命令：

kafka-preferred-replica-election.sh --bootstrap-server cdh01:9092 --path-to-json-file partition.json

创建一个名为partition.json的文件，其中包含以下内容：

{
  "partitions": [
    {
      "topic": "TopicRunData",
      "partition": 2
    }
  ]
}

这将触发platformMutiRunData主题第2分区的leader重新选举。

partition.json 有可能需要更多参数，请根据实际情况调整或找更详细的教程。

3、清空Topic来解决问题

由于无法手动选择，解决时间又紧迫，根据分析可能丢失数据少，所以想清空TopicRunData 主题的数据，从外部重新导入数据到 TopicRunData 。

注意：这将删除
TopicRunData 主题的所有数据。在执行此操作之前，请确保您了解此操作的后果，并备份好相关数据。

清空 TopicRunData 主题的数据：

kafka-topics.sh --delete --topic
TopicRunData --bootstrap-server cdh01:9092

然后重新创建该主题（如果需要）：

kafka-topics.sh --create --topic
TopicRunData --bootstrap-server cdh01:9092 --replication-factor 1 --partitions 3

检查Kafka集群状态：

kafka-consumer-groups.sh --bootstrap-server cdh01:9092 --describe --group

your_consumer_group请将your_consumer_group替换为您要检查的实际消费者组ID。

确保所有Kafka broker正常运行。

作者 east

mysql, 运维 6月 27,2024

centos离线安装mysql客户端（亲测可用）

由于项目的需要，需要在内网的centos服务器，有mysql客户端远程访问mysql服务器。

1. 下载MySQL客户端

首先，你需要下载MySQL客户端软件包。你可以从MySQL官方网站下载，或者使用CentOS的软件仓库。

https://dev.mysql.com/get/Downloads/MySQL-5.7/mysql-5.7.34-1.el7.x86_64.rpm-bundle.tar

2. 安装MySQL客户端

解压缩下载的文件，并安装RPM包：

tar xvf mysql-5.7.34-1.el7.x86_64.rpm-bundle.tar
rpm -ivh mysql-community-client-5.7.34-1.el7.x86_64.rpm

用命令 which mysql 看到下面结果时说明安装成功了：

/usr/bin/mysql

3. 连接到远程MySQL服务器

使用以下命令连接到远程MySQL服务器：

mysql -u your_username -p -h remote_server_ip

注意事项：

确保远程MySQL服务器允许来自你的CentOS服务器的连接。你可能需要在远程服务器的MySQL配置文件（通常是my.cnf）中设置bind-address为0.0.0.0，并在mysql.user表中授予远程访问权限。
确保防火墙规则允许两个服务器之间的3306端口（MySQL默认端口）的流量。
如果你使用的是较新或较旧的MySQL版本，请下载相应的安装包。

作者 east

运维 5月 4,2024

迁移一台服务器上运行的shell脚本到海豚调度器需要考虑问题

在使用海豚调度器（Dolphin Scheduler）迁移已经在服务器上运行的SHELL脚本时，需要注意以下几个关键点，并根据需要做出相应的修改：

1. 脚本环境适配：

环境变量：确认海豚调度器中的环境变量与原始服务器一致，特别是与Kafka、HDFS、Kettle等相关的环境变量。
依赖关系：确保所有脚本执行的依赖库和软件在海豚调度器上已经正确安装和配置。如果有依赖的软件或库文件，需要在海豚调度器的各个节点上进行相应的安装或配置。

2. 脚本参数和配置：

参数传递：如果脚本需要接收外部参数，需确保在海豚调度器中正确传递。
配置文件：如果脚本使用外部配置文件，应确保这些文件可以在海豚调度器上访问，并检查文件路径是否需要调整。
路径问题：检查脚本中使用的路径是否在海豚调度器的环境中存在，并且是否可以在所有节点上访问到。如果脚本中使用了相对路径，确保相对路径的基准位置在所有节点上都是一致的。

3. 定时任务设置：

定时任务调整：原脚本是持续运行还是定时运行？如果迁移到海豚调度器，可能需要重新配置定时任务规则。
任务依赖：如果任务有依赖关系，需要在海豚调度器中配置相应的上下游依赖。

4. 资源管理：

资源分配：根据脚本执行的需要，为任务分配足够的资源（CPU、内存等）。
磁盘空间：确保海豚调度器有足够的磁盘空间来处理脚本执行过程中产生的数据。

5. 错误处理和日志：

错误处理：脚本中的错误处理机制需要确保可以兼容海豚调度器，以便在出现问题时及时响应。
日志记录：修改脚本以将日志输出到海豚调度器支持的日志系统，便于问题追踪。

6. 安全性和权限：

权限设置：确认脚本运行用户具有执行任务所需的权限。
安全模式：处理HDFS可能遇到的安全模式问题，确保脚本有权限在HDFS上创建和写入文件。

7. 脚本逻辑调整：

持续运行逻辑：原参考信息中提到无需定时即可自动生成每日数据文件的逻辑，在海豚调度器中可能需要调整，比如使用循环和条件判断来控制任务的持续运行。
时间戳处理：如果脚本中涉及到时间戳处理，确保时间同步和时区设置正确。

8. 海豚调度器的特定配置：

任务类型：在创建任务时，选择合适的任务类型（如SHELL类型）。
任务参数：在海豚调度器中设置脚本执行所需参数。
任务超时：设置合理的任务超时时间，防止长时间运行的任务无法正常结束。

9. 测试：

在迁移完成后，进行充分的测试，以确保脚本在海豚调度器上的运行效果与在独立服务器上运行一致。

通过以上步骤，可以确保SHELL脚本在迁移到海豚调度器后能够稳定、高效地运行。同时，要确保整个迁移过程中，遵循项目的实际情况，保障数据迁移工作的连续性和正确性。

作者 east

运维 4月 28,2024

windows11如何设置无线网卡不休眠

为了在家里用向日葵等软件连接上公司的台式电脑，发现尴尬的事情：在家里连接时提示公司的电脑下线了。经排查，发现长时间不用时，公司的台式电脑的无线网卡休眠了。

windows11可以用下面的步骤设置无线网卡不休眠：

1. 设置电源计划

首先，需要确保电源计划设置中允许电脑不休眠。

打开“设置”（可以通过开始菜单或使用快捷键Win +X打开）。
点击“电源选项”。
在下图插入电源时，闲置以下时间后将设备置于睡眠状态，将下拉菜单设置为“从不”或设置一个较长的时间。

2. 防止无线网卡休眠

为了防止无线网卡进入休眠状态，可以修改电源管理设置。

打开设备管理器（可以通过右击“开始”按钮选择“设备管理器”打开）。
展开网络适配器，找到您的无线网卡。
右键点击无线网卡，选择“属性”。
切换到“电源管理”标签页。
取消勾选“允许计算机关闭此设备以节约电源”。
点击“确定”保存设置。

作者 east

分类归档运维