1.Node.js-0007-CentOS 7.9 安装 Node.js 18.x-06-尝试低版本
2.runc hang 导致 Kubernetes 节点 NotReady
3.MySQL Shell 8.0.32 for GreatSQL编译二进制包
4.msys2编译FFmpeg全网最详细步骤

Node.js-0007-CentOS 7.9 安装 Node.js 18.x-06-尝试低版本

       部署一个前端应用

       需要 Node.js 环境

       现在安装一个耍耍

       （1）本系列文章

       格瑞图：Node.js--CentOS 7.9 安装 Node.js .x

       格瑞图：Node.js--CentOS 7.9 安装 Node.js .x--编译 gcc

       格瑞图：Node.js--CentOS 7.9 安装 Node.js .x--编译 make

       格瑞图：Node.js--CentOS 7.9 安装 Node.js .x--编译 glibc

       格瑞图：Node.js--CentOS 7.9 安装 Node.js .x--安装

       格瑞图：Node.js--CentOS 7.9 安装 Node.js .x--修复操作系统

       9、源码尝试低版本（1）尝试 node .x

       说明 CentOS 7.9 可以支持 Node.js 到 .x

       其他更低一点的编译版本，肯定也没有问题。卡住

       尝试一下 .x~

       （2）尝试 node .x

       （3）node .x 的源码问题

       需要 GLIBC_2. 至 GLIBC_2. 版本，那就编译 glibc-2.？

       （4）尝试 glibc-2.

       下载源码解压并创建构建目录

       开始配置

       配置警告

       configure: WARNING: *** The编译se auxiliary programs are missing or incompatible versions: makeinfo *** some features or tests will be disabled. *** Check the INSTALL file for required versions.

       安装依赖

       安装完毕

       再次配置没有警告，开始编译

       运行了 分钟。卡住美美咖源码。源码。编译

       不知道什么情况，卡住先掐了~

       看了目录中生成了 libc.so 但是源码无法使用，还是编译心急了，要在等等。卡住

       重新执行一下

       还是源码在下图高亮处卡着，再等等

       确认一下 make 在做事情，编译而不是卡住卡住了：

       查看 CPU 利用率：

       查看进程操作文件：

       使用 lsof 查看一下进程 操作的文件。

       再次运行

       再次运行

       两天后

       运行了 分钟，差不多 小时了。根据当前时间，也 2 天多点了。

       算是废了，后边逐步提高一下版本试试。挖坑 -- ::

       N、后记

       United States Glacier National Park

       美国冰川国家公园

       ~

runc hang 导致 Kubernetes 节点 NotReady

       Kubernetes 1..3 OS: CentOS 7.9. Kernel: 5.4.-1.el7.elrepo.x_ Docker: ..6

       线上告警提示集群中存在 2-3 个 K8s 节点处于 NotReady 的状态，并且 NotReady 状态一直持续。问题的解决可以通过两种方法，我们先来看看 A 方案。htpp源码

       针对 docker hang 住这样的现象，通过搜索资料后发现了以下两篇文章里也遇到了相似的问题。这两篇文章都提到了是由于 pipe 容量不够导致 runc init 往 pipe 写入卡住了，将 /proc/sys/fs/pipe-user-pages-soft 的限制放开，就能解决问题。查看问题主机上 /proc/sys/fs/pipe-user-pages-soft 设置的是 。所以将它放大 倍 echo > /proc/sys/fs/pipe-user-pages-soft，然而 kubelet 还是没有恢复正常，pleg 报错日志还在持续，runc init 程序也没有退出。考虑到 runc init 是 kubelet 调用 CRI 接口创建的，可能需要将 runc init 退出才能使 kubelet 退出。通过文章中的说明，只需要将对应的 pipe 中的内容读取掉，runc init 就能退出。尝试了几个后，runc init 果然退出了。再次检查，节点状态切换成 Ready，pleg 报错日志也消失了，观察一天也没有出现节点 NotReady 的情况，问题（临时）解决。

       对解决方案 A 的疑问，虽然问题解决了，但是ignition 源码仔细读 /proc/sys/fs/pipe-user-pages-soft 参数的说明文档，发现这个参数跟本次问题的根本原因不太对得上。pipe-user-pages-soft 含义是对没有 CAP_SYS_RESOURCE CAP_SYS_ADMIN 权限的用户使用 pipe 容量大小做出限制，默认最多只能使用 个 pipe，一个 pipe 容量大小为 k。这里就有疑问：为什么容器 root 用户 pipe 容量会超过限制。

       定位问题最直接的方法，就是阅读源码。先查看下 Linux 内核跟 pipe-user-pages-soft 相关的代码。线上内核版本为 5.4.-1，切换到对应的版本进行检索。在创建 pipe 时，内核会通过 too_many_pipe_buffers_soft 检查是否超过当前用户可使用 pipe 容量大小。如果发现已经超过，则将容量大小从 个 PAGE_SIZE 调整成 2 个 PAGE_SIZE。通过机器上执行 getconf PAGESIZE 可以获取到 PAGESIZE 是 字节，也就是说正常情况下 pipe 大小为 字节，但是由于超过限制，pipe 大小被调整成 字节，这就有可能出现数据无法一次性写入 pipe 的问题。

       找到问题根本原因的第一步，往往是在线下环境复现问题。由于线上环境已经通过方案 A 做了紧急修复，因此，需要找到一种必现的手段。功夫不负有心人，右侧源码在 issue 中找到了相同的问题，并且可以通过以下方法复现。执行命令之后，立刻就出现 runc init 卡住的情况。通过 lsof -p 查看 runc init 打开的文件句柄情况，可以看到 fd4、fd5、fd6 都是 pipe 类型，其中，fd4 和 fd6 编号都是 ，是同一个 pipe。如何来获取 pipe 大小来实际验证下「疑问 2」中的猜想呢？Linux 下没有现成的工具可以获取 pipe 大小，但是内核开放了系统调用 fcntl（fd, F_GETPIPE_SZ）可以获取到，代码如下。编译好之后，查看 pipe 大小情况如下。重点看下 fd4 和 fd6，两个句柄对应的是同一个 pipe，获取到的容量大小是 = 2 * PAGESIZE。所以的确是因为 pipe 超过软限制导致 pipe 容量被调整成了 2 * PAGESIZE。

       对解决方案 A 疑问的探索，对解决方案 B 的考虑，线上应该如何做修复呢？是否需要把 docker 所有组件都升级呢？如果把 dockerd/containerd/runc 等组件都升级的话，就需要将业务切走然后才能升级，整个过程相对比较复杂，wce源码并且风险较高。因此考虑是否可以单独升级 runc？因为在 Kubernetes v1. 版本中还没有弃用 dockershim，因此运行容器整个调用链为：kubelet → dockerd → containerd → containerd-shim → runc → container。不同于 dockerd/containerd 是后台运行的服务端，containerd-shim 调用 runc，实际是调用了 runc 二进制来启动容器。因此，只需要升级 runc，对于新创建的容器，就会使用新版本的 runc 来运行容器。

       通过测试环境验证，的确不会出现 runc init 卡住的情况了。最终，逐步将线上 runc 升级成 v1.1.1，并将 /proc/sys/fs/pipe-user-pages-soft 调整回原默认值。runc hang 住的问题圆满解决。

       总结，本次故障的原因是，操作系统对 pipe-user-pages-soft 有软限制，但是由于容器 root 用户的 UID 与宿主机一致都是 0，内核统计 pipe 使用量时没有做区分，导致当 UID 为 0 的用户 pipe 使用量超过软限制后，新分配的 pipe 容量会变小。而 runc 1.0.0-rc 正好会因为 pipe 容量太小，导致数据无法完整写入，写入阻塞，进而 runc init 卡住，kubelet pleg 状态异常，节点 NotReady。修复方案是 runc 通过 goroutine 及时读取 pipe 内容，防止写入阻塞。

MySQL Shell 8.0. for GreatSQL编译二进制包

       构建MySQL Shell 8.0. for GreatSQL

       写在前面

       之前已经写过一篇前传 MySQL Shell 8.0. for GreatSQL编译安装，最近再次编译MySQL Shell二进制包时，发现了一些新问题，因此重新整理更新本文档。

       几处新问题

       这次编译MySQL Shell发现几个新问题，下面一一列举。

       针对这些情况，为了方便社区用户，我直接将整个二进制包编译工作打包成Docker镜像，有需要的直接拉取镜像创建容器，只需耐心等上几分钟即可得到MySQL Shell for GreatSQL二进制包了。

       使用方法很简单，类似下面这样即可：

       接下来回退到宿主机，将容器中的二进制包拷贝出来

       然后解压缩，就可以在宿主机环境下使用了。

       说完用Docker容器构建二进制包的方法，再说下手动编译全过程，有兴趣的同学也可以跟着自己动手做一遍，增加体感。

       手动编译过程

       2.1 准备Docker环境

       参考编译环境要求参考 GreatSQL-Shell Dockerfile ，构建好一个Docker镜像环境，基本上照着做就行，这里不赘述。

       2.2 下载源码包

       先下载准备好下列几个源码包：

       下载完后都放在/opt/ 目录下，并解压缩。

       2.3 修改MySQL Shell源码包

       打开链接： gitee.com/GreatSQL/Grea...，下载GreatSQL补丁包文件 mysqlsh-for-greatsql-8.0..patch。

       为了让MySQL Shell支持GreatSQL仲裁节点（ARBITRATOR）特性，需要打上补丁包：

       2.4 编译相关软件包1..1 antlr4-4.

       编译antlr4：

       如果你的网络环境无法直接从github上下载二进制包，则先自行下载二进制包 github.com/google/googl...，并放到antlr4代码包中相应位置，再修改antlr4代码，略过下载步骤，详见下面的做法：

       之后就可以用上面的方法进行编译，而不会在下载二进制包环节卡住不动。

       2.4.2 patchelf-0..5

       2.4.3 protobuf-3..4

       2.4.4 rpcsvc-proto-1.4

       编译MySQL Shell

       3.1 编译MySQL 8.0.

       在MySQL 8.0.源码目录中，编译生成MySQL客户端相关依赖库，这是编译MySQL Shell之前要先做的事：

       3.2 编译MySQL Shell 8.0. for GreatSQL

       编译完MySQL 8.0.后，切换到MySQL Shell源码目录下，准备继续编译：

       编译完成后，会把二进制文件安装到/usr/local/greatsql-shell-8.0.--Linux-glibc2.-x_ 目录下。

       3.3 运行测试

       运行mysqlsh测试前，还要先将libprotobuf.so动态库文件拷贝放到MySQL Shell目录下，再运行测试：

       好了，开始感受GreatSQL 8.0.-新版本特性，以及MGR仲裁节点的魅力吧 O(∩_∩)O哈哈~

       延伸阅读

       本文完。

       Enjoy GreatSQL :)

       关于GreatSQL

       GreatSQL数据库是一款开源免费数据库，可在普通硬件上满足金融级应用场景，具有高可用、高性能、高兼容、高安全等特性，可作为MySQL或Percona Server for MySQL的理想可选替换。

       相关链接

       GreatSQL社区

       Gitee

       GitHub

       Bilibili

       技术交流群

       微信：添加GreatSQL社区助手好友，微信号wanlidbc发送验证信息加群

       QQ群：

       Enjoy GreatSQL :)

       关于 GreatSQL

       GreatSQL是适用于金融级应用的国内自主开源数据库，具备高性能、高可靠、高易用性、高安全等多个核心特性，可以作为MySQL或Percona Server的可选替换，用于线上生产环境，且完全免费并兼容MySQL或Percona Server。

       相关链接： GreatSQL社区 Gitee GitHub Bilibili

       GreatSQL社区：

       社区有奖建议反馈： greatsql.cn/thread--1...

       社区博客有奖征稿详情： greatsql.cn/thread--...

       （对文章有疑问或者有独到见解都可以去社区官网提出或分享哦~）

       技术交流群：

       微信&QQ群：

       QQ群：

       微信群：添加GreatSQL社区助手（微信号：wanlidbc ）好友，待社区助手拉您进群。

msys2编译FFmpeg全网最详细步骤

       本文提供详细步骤使用msys2编译FFmpeg源码，无需安装mingw。msys2在Windows上模拟Linux环境，允许使用大多数shell命令，类似于虚拟机但更轻量级。首先，从msys2.github.io下载并安装msys2到D盘，避开系统盘C盘。

       在安装过程中，若进度卡住，可取消安装后重新尝试。安装完毕后，进入安装目录启动msys2_shell.cmd，并调整字符集以避免中文乱码。确保设置生效后重启msys2_shell.cmd。

       接着，更换msys2的国内源，可参考相关指南。免费音视频学习资源推荐，包括FFmpeg、WebRTC、RTMP等技术，点击下方链接免费报名，先保存学习路径。

       使用msys2安装软件，如yasm、make、diffutils、pkg-config。若安装缓慢，多次尝试直至完成。通过命令查看gcc安装状态。

       下载最新FFmpeg源码（FFmpeg4.2.2），创建名为“SourceCode”的文件夹，解压源码并存放其中。

       通过命令行进入msys2目录，配置FFmpeg编译参数，例如指定安装路径。生成的Makefile文件将用于编译过程。此步骤可使用批处理文件执行以提高效率。

       编译完成后，ffmpeg库和可执行文件位于msys/usr/local/ffmpeg/bin目录。将msys\mingw\bin下的dll库复制到msys\usr\local\ffmpeg\bin，以确保依赖性。

       需x库时，先编译x库，再编译FFmpeg。遵循本指南的详细步骤，您将成功在Windows上使用msys2编译FFmpeg源码。