我有一个基于 DRBD、Corosync 和 KVM 的简单的两节点 CentOS 集群。
当我尝试通过 yum 更新其软件包时，它会列出类似的内容
Updating:
clusterlib x86_64 3.0.12.1-23.el6_2.1 updates 94 k
corosync x86_64 1.4.1-4.el6_2.3 updates 188 k
corosynclib x86_64 1.4.1-4.el6_2.3 updates 171 k
drbd83-utils x86_64 8.3.13-1.el6.elrepo elrepo 223 k
glibc x86_64 2.12-1.47.el6_2.12 updates 3.8 M
glibc-common x86_64 2.12-1.47.el6_2.12 updates 14 M
kernel-firmware noarch 2.6.32-220.23.1.el6 updates 6.3 M
kernel-headers x86_64 2.6.32-220.23.1.el6 updates 1.6 M
kmod-drbd83 x86_64 8.3.13-1.el6.elrepo elrepo 174 k
libvirt x86_64 0.9.4-23.el6_2.9 updates 1.5 M
libvirt-client x86_64 0.9.4-23.el6_2.9 updates 2.8 M
libvirt-python x86_64 0.9.4-23.el6_2.9 updates 308 k
matahari x86_64 0.4.4-12.el6_2 updates 18 k
matahari-agent-lib x86_64 0.4.4-12.el6_2 updates 40 k
matahari-broker x86_64 0.4.4-12.el6_2 updates 25 k
matahari-host x86_64 0.4.4-12.el6_2 updates 43 k
matahari-lib x86_64 0.4.4-12.el6_2 updates 43 k
matahari-network x86_64 0.4.4-12.el6_2 updates 36 k
matahari-service x86_64 0.4.4-12.el6_2 updates 51 k
matahari-sysconfig x86_64 0.4.4-12.el6_2 updates 32 k
qemu-img x86_64 2:0.12.1.2-2.209.el6_2.5 updates 338 k
qemu-kvm x86_64 2:0.12.1.2-2.209.el6_2.5 updates 1.2 M
qpid-cpp-client x86_64 0.14-14.el6_2 updates 996 k
qpid-cpp-client-ssl x86_64 0.14-14.el6_2 updates 106 k
qpid-cpp-server x86_64 0.14-14.el6_2 updates 990 k
qpid-cpp-server-ssl x86_64 0.14-14.el6_2 updates 58 k
qpid-qmf x86_64 0.14-7.el6_2 updates 410 k
如何判断更新特定包是否意味着某种停机？ （例如需要重启虚拟机或整机）
答案1
更新服务后几乎总是需要重新启动该服务。
如果您询问此重新启动是否是在更新期间由 yum 自动执行的，那么没有保证的方法可以知道（除了提取每个软件包的 RPM 预安装/安装后脚本之外）。 RPM 预安装/后安装脚本可以做任何它想做的事情。
您的最佳实践应该始终是拥有镜像生产的开发/测试环境，以便您可以首先在这些环境中执行类似的测试。
这不仅有助于确定软件包升级是否会导致服务重新启动，而且还可以让您在投入生产之前发现任何不兼容或可能出现的问题。
答案2
kmod-drbd83是您的 DRBD 内核模块。如果要激活此更新，您必须卸载它（即停止 drbd）。这意味着 drbd 会停机。
glibc-update 之后，您也应该重新启动。
因此，切换或故障转移所有服务、安装更新、重新启动并故障恢复。
答案3
如果您没有手动更改任何存储库，那么安装这些更新是安全的。对于停机，在安装之前，yum 会通知您这一点。或者至少，安装后，它会问你要做什么
答案4
在大多数情况下，您不必重新启动服务器，而是在更新过程中重新启动服务。话虽如此，查看您的更新列表，我发现您有内核更新，这些更新几乎总是需要重新启动服务器才能加载新内核。