@meanmachine

这其实都是 PVE 的锅，很多功能就是懒得去做。

既然如此，我就不做 systemctl restart networking 这个操作了，

我自己写管理脚本，直接管理 iptables 的 NAT 与 端口映射，甚至通过 HASH 检测把 iptables 没办法去重的问题也一起解决了。

PVE 这点管理功能，都做不好，那我自己来做。PVE 官方真菜。

@lwch
iptables 、路由表、/etc/resolv.conf 都没变化。

而且，虚拟机重启解决不了这个问题，但是虚拟机恢复执行 systemctl restart networking 之前的快照，却能恢复网络。

1.无论哪个工种，做到顶端，都有“奔头”。比如保洁，高端保洁，比如别墅保洁、豪车保洁，从业收入不一定比程序员差。

2.选择行业，缺钱首选来钱快的。在不缺钱的情况下，才选择自己喜欢的行业。

3.学历、年龄，不是限制项目，兴趣与态度才是。

1.性能与资源粒度是个矛盾。只考虑性能的话，可以按 NUMA 把资源进行平均划分，甚至可以给每个 CPU Thread 安排一个专有资源池，这样就避免了 CPU 竞争内存的问题，接着甚至可以把这部分专有资源池直接优化到 L3 cache 里去。这种优化的本质是空间换时间，会存在一定程度的资源浪费，比如某些不怎么干活的 CPU Thread ，它的专有资源池可能就不怎么使用。

2.如果存在避免不了竞争的资源区域，用 O1 的环形队列来代替 List 、Queue 等结构。这种优化的本质是极端的空间换时间，存在空间的大量浪费，但高端网络设备都这样搞。

@king666wyx

1.数据库安全是分很多等级的。比如自己玩的数据库，做好了定期备份，并且不在乎丢失最后几条数据，那么用 Mysql Docker 是没问题的。

2.你说的对，要确保数据安全，应该从数据库处理机制入手，而不是 docker 。

3.正经企业级的数据库安全，一般是这样做的：

A.多副本节点的完全冗余。

B.每个节点又有 CDP （连续数据保护）作为支撑。

C.普通 2 - 3 级等保系统，会有专门备份一体机，每日一个完整备份。

金融级一般是 1 小时一个完整备份。

@king666wyx 再仔细看看？ docker 层面的问题，我在上面已经说了。

不经意之间 BMW 钥匙掉在地上，然后说是前年年底公司发的。

1.那些说啥五类跑万兆的，也是够了。

五类在理论上的确可以跑这种速度，但线材质量不过关，装修师傅不小心扯一下就断了，抗干扰能力也差，不然大家还去买六类甚至七类干嘛？


2.装修与网络施工，属于初中知识水平，B 站与知乎一大把的教程，而且现在网购也极其方便，自己买工具打打洞、穿穿管、布布线，多大点事？而且家装又不需要熔纤，打光笔与光衰测试仪，京东都在 2 百元以内。


3.如果还没进行装修施工，或者打算重新布线，个人推荐：

每个房间至少 2 条 6 类屏蔽线，不要买自己做头子的，买已经做好头子的成品线。线要买长一些的，但每隔 60 米一定要加一台铁壳交换机作为中继，可以买网线直通头，这也比自己做头子要强。

不要买 7 类线，因为不划算，超过 6 类的走光纤。每个房间放 1 对铠装 SC-SC 单模成品光纤 + 1 对 铠装 LC 单模双工成品光纤 + 铠装 6 芯光缆留作备用。先穿管布线，但别急着埋管，穿管布线完成后，先测通断与光衰，因为千兆甚至万兆的网络，对光衰范围有严格要求。

网络设备有个定律，如果你想稳定跑到 A 速率，那么周边设备与性能必须要达到更高的 B 速率。

比如，要稳在百兆，需要千兆的设备与性能。

想稳定在 1G 速率，需要至少 2.5G 速率的设备与性能。

@king666wyx

崩溃的意思是，因为软件 bug 或硬件缺陷，导致程序没按正常逻辑去处理。

这些都不是 innodb_flush_log_at_trx_commit 能够处理的事情。

比如 DB 在 malloc 时没处理 NUMA 的场景，导致 malloc 失败，DB 整体崩溃，而此时恰好 DB 有别的线程在处理日志数据落地到数据文件的逻辑，DB 崩溃造成数据文件的 lock 没处理，且存在脏数据。

再比如内存条是非 ECC / RECC 的，且突然有了坏块，坏块位置刚好是 DB 事务 queue length 位置，由 length 由 1024 突然变成 拷斤锟，于是 queue 后续的 data 读到了内存中的未知区域，这些数据被当成正常数据刷入日志文件，最后日志数据落地到数据文件时，发现数据结构与表结构对不上，报错。

这些还是内部逻辑。

外部的情况会更复杂，比如使用超过物理磁盘容量的稀疏虚拟磁盘文件，当实际数据量超出物理磁盘容量后，如果存储组件有 bug ，会导致超过容量的数据全部存储失败，且无告警。

再比如某些分布式文件系统，内部有 bug ，双副本的独占文件块在被 DB 使用时，其中某个物理节点被管理员强制进入维护状态。此时文件系统，本来应该按业界操作规范，先另寻可用物理节点，然后进行版本记录 -> 版本之前的历史数据同步 -> 版本后的新数据同步 -> 锁上整个分布式文件系统的写操作 -> 同步最后差异数据 -> 解锁写操作。但因为 bug 的存在，当某个物理节点被管理员强制进入维护状态时，另一个可用物理节点的超时等待时间过长，积压数据过多，积压的数据因程序 bug ，没能进入 swap 与 持久存储缓存，导致这唯一可用的节点也因为 oom 而崩了，最终丢失数据。

还有一个不仅是丢失数据，而是直接数据全毁的例子，某知名大牌虚拟化厂商，其快照实现有 bug ，本来多层快照，在 HDD 介质中，导出时，因需要大量 4k rand 操作，来进行多层快照合并，速度贼慢，而且写这块实现的程序员，贪图方便，使用了无缓存无副本的直接对快照文件进行文件内处理的高风险方法；此时，用户态的管理工具，是另一个程序员写的，两人没沟通、没写上处理逻辑，导致管理工具，没有等待与检查快照合并逻辑，而是简单粗暴地直接使用了一个超时时间，超时后就直接中断快照合并逻辑。当快照数量多，数据量大的情况下，前者的合并操作因超时，被后者打断，导致了在用户角度看来，复制整个虚拟磁盘或虚拟机时，超时失败，且原始虚拟机磁盘数据损坏。简单来说，就好比，你复制一个电影，复制失败了，且原始的电影也播放不了。

@ACEonly

PVE 是基于 Debian 的，没必要在 LXC 里面再去套娃 Debian 。

你直接在 Debian 里，装 Docker ，然后 Docker 跑 OMV 就行了。

楼上们的数学，没认真学吧。

1.不重复填入 S(10) = 55 。

2.重复填入 24 * 3 = 72 。

3.差值：72 - 55 = 17 。

这 17 其实就是被用了 2 次的格子的填法。

去掉镜像，这 2 个格子，组合起来，只有 2 种填法：10 + 7 与 9 + 8 。

4.

A.剩下的数字，从小到大排序；

B.3 个四边形，和从大到小排序；

C.先填格子少的四边形。

按以上 3 个排序规则，能很快填完。

@jdz 想省心的话，一线品牌机比较合适，买的时候加钱延长保修期。

1.有可能是，花了大价钱，买通了关系，拿到了官方认证。

2.有了官方认证，数据根本不需要爬。

体制内的这些系统，基本上是包给体制外的公司做的，直接在这类外包公司里找内鬼，给钱买数据就好。内鬼因为知道这些公司有官方认证，也不怕卖数据被查。

所以，数据来源一点都不重要，重要的是要拿到这类很敏感的官方认证，需要为打通关系，交多少钱，以及怎么安全交钱。

歪个楼：为啥会怕拉网线？

不缺时间，甚至可以自己买材料，买工具，自学，B 站与知乎大把教程，拉网线与装修施工，是中专（相当于初中）阶段的课程，你都是个开发了，这点事情分分钟搞定。

而且，自己搞定还有个好处，可以根据自己的想法，加合适芯数的光纤，加屏蔽 7 类线材，等等，不需要担心施工队偷工减料。

#-------------------------
#-------------------------
1.DB 的 HA ，需要彻底隔离的至少 2 个物理 Node 。而且，如果需要强一致性，DB Client 还不能直接访问 DB Server ，而是 DB Client 需要访问 DB Middleware ，比如 DB Proxy ，通过 DB Proxy 来连接两个物理节点的 DB ，来保证两个物理节点的数据，同时 flush to 持久化存储介质后，DB Proxy 才能 Response to DB Client：该事务执行成功。

这是最低配最入门版本的 HA ，扯这事，是因为，你就一个单节点 Mysql ，崩溃后，就算数据全丢都很正常，所以不用太在意损坏数据卷，因为你不做 HA ，相当于不在乎数据安全问题。

#-------------------------
#-------------------------
2.当 Mysql 容器崩溃后，也就是 Mysql 的单个物理节点崩溃后，发生什么事情都不奇怪，所以发生连接未正常关闭就太正常了，比如 Mysql 直接挂掉，导致 DB Server 的连接管理组件崩溃，tcp-socket 没向 DB Client 做任何回应，也接着崩了，DB Client 那边：

A.可能会直接 tcp keep alive 超时，然后报连接未正常关闭错误。

B.DB Server 崩溃后，DB Server 的上层宿主，比如 OS 、docker 的网络管理组件等等，可能会发出 tcp 关闭数据包 FIN Packet ，同时 DB Client 业务层发现 tcp 连接关闭后，业务层面却没有执行安全关闭逻辑，然后也会报这个连接未正常关闭错误。

我没有具体研究过 Mysql 逻辑，但数据库在这个问题上的处理逻辑都差不多。

#-------------------------
#-------------------------
3.物理机硬件损伤也比较大 ？？？？？

你是觉得，存储介质，在那里噼里啪啦响着，就容易损坏对吧？

比如以前有这样的说法，硬盘一直开着 BT 下载，就很容易坏。道理的确是这样，但问题是，你买硬盘回来，是打算宠着用，每天还要亲亲抱抱举高高嘛？

硬盘用坏，不是因为 Mysql 或 Redis 崩溃，而是机械硬盘长期非连续读写，磁头经常移动，寿元当然消耗得快。SSD 的 TLC 甚至廉价 QLC ，无论你 4k rand io 还是 seq io ，长时间大量写入，也容易耗光它的寿元。

其它数据库类型及存储也同理。

另外，与其怕这，还不如担心灰尘导致内存条击穿，造成内存故障，如果内存不是 RECC / ECC ，以及数据传输没做校验，导致数据复制与移动发生错误，这个问题更要命。

我给 1 楼整理一下格式：

USB-Type 乱象
1.USB2.0
2.USB3.0
3.USB3.0 E-Marker
4.USB3.1 Gen1 E-Marker
5.USB3.1 Gen2 E-Marker
6.USB3.2 Gen1 E-Marker
7.USB3.2 Gen2 E-Marker
8.USB3.2 Gen2×2 E-Marker
9.雷电 3 E-Marker
10.USB2.0 PD2.0
11.USB3.0 PD2.0
12.USB3.0 E-Marker PD2.0
13.USB3.1 Gen1 E-Marker PD2.0
14.USB3.1 Gen2 E-Marker P2.0
15.USB3.2 Gen1 E-Marker PD2.0
16.USB3.2 Gen2 E-Marker PD2.0
17.USB3.2 Gen2×2 E-Marker PD2.0
18.雷电 3 E-Marker PD2.0
19.USB3.0 E-Marker PD3.0 3A
20.USB3.1 Gen1 E-Marker PD3.0 3A
21.USB3.1 Gen2 E-Marker P3.0 3A
22.USB3.2 Gen1 E-Marker PD3.0 3A
23.USB3.2 Gen2 E-Marker PD3.0 3A
24.USB3.2 Gen2×2 E-Marker PD3.0 3A
25.雷电 3 E-Marker PD3.0 3A
26.USB3.0 E-Marker PD3.0 PPS 3A
27.USB3.1 Gen1 E-Marker PD3.0 PPS 3A
28.USB3.1 Gen2 E-Marker P3.0 PPS 3A
29.USB3.2 Gen1 E-Marker PD3.0 PPS 3A
30.USB3.2 Gen2 E-Marker PD3.0 PPS 3A
31.USB3.2 Gen2×2 E-Marker PD3.0 PPS 3A
32.雷电 3 E-Marker PD3.0 PPS 3A
33.USB3.0 E-Marker PD3.0 5A
34.USB3.1 Gen1 E-Marker PD3.0 5A
35.USB3.1 Gen2 E-Marker P3.0 5A
36.USB3.2 Gen1 E-Marker PD3.0 5A
37.USB3.2 Gen2 E-Marker PD3.0 5A
38.USB3.2 Gen2×2 E-Marker PD3.0 5A
39.雷电 3 E-Marker PD3.0 5A
40.USB3.0 E-Marker PD3.0 PPS 5A
41.USB3.1 Gen1 E-Marker PD3.0 PPS 5A
42.USB3.1 Gen2 E-Marker P3.0 PPS 5A
43.USB3.2 Gen1 E-Marker PD3.0 PPS 5A
44.USB3.2 Gen2 E-Marker PD3.0 PPS 5A
45.USB3.2 Gen2×2 E-Marker PD3.0 PPS 5A
46.雷电 3 E-Marker PD3.0 PPS 5A
47.USB2.0 SuperVOOC
48.USB3.0 SuperVOOC
49.USB3.1 Gen1 SuperVOOC
50.USB3.1 Gen2 SuperVOOC
51.USB3.2 Gen1 SuperVOOC
52.USB3.2 Gen2 SuperVOOC
53.USB2.0 小米快充）
54.USB2.0 vivo22.5W 快充）
55.USB2.0 vivo44W 快充）
56.USB2.0 vivo120W 快充）
57.USB2.0 SCP
58.USB3.0 SCP
59.USB3.1 SCP
60.USB3.2 Gen1 SCP
61.USB3.2 Gen2 SCP