先给三个问题一个明确结论：可以在控制台直接重置，不用重装系统；重置本身不会丢数据；离线重置一般需要重启一次才生效。 一、先区分两种密码你丢的是 ECS 操作系统登录密码，不是华为云账号密码。控制台重置改的是系统账号密码，Linux 通常是 root 或 ubuntu，Windows 是 Administrator。账号密码与云账号密码互不影响，改完后云账号登录方式不变。 二、推荐操作顺序1. 先确认实例状态和登录方式：如果当初是密钥对登录，重置密码后仍可能因 sshd 禁用密码登录而连不上，需要先用密钥或控制台远程登录进去放开密码登录。2. 操作前先给系统盘做一个快照，成本低，万一误点重装等操作也有回退点。3. 控制台路径：弹性云服务器 ECS → 实例列表 → 目标实例 → 更多 → 重置密码，按提示设置符合复杂度的新密码。4. 按控制台提示重启实例，再用新密码登录验证，旧密码随即失效。 三、为什么不会丢数据重置只修改系统账号的密码信息，不格式化系统盘，不动数据盘，不重建实例。真正会清空系统盘的是重装系统、切换操作系统、更换系统盘，这几个按钮与重置密码位置相近，操作时一定要看清名称，不要点错。 四、重置后仍连不上的排查顺序1. 用户名是否正确：Ubuntu 镜像默认 ubuntu，其他常见镜像多为 root，Windows 为 Administrator。2. 安全组是否放行端口：Linux 为 22，Windows 为 3389。3. sshd 是否禁用密码登录：检查 PasswordAuthentication 是否为 no，密钥登录的实例常见此问题。4. 账号是否因多次输错被锁定，需要解除锁定后再试。5. 用控制台远程登录验证：远程登录能进，说明系统和密码基本正常，问题多在网络或 sshd 配置；远程登录也进不去，再考虑系统层面修复。 一句话总结：先快照，再重置，重启后用新密码验证；不要用重装系统代替重置密码。

补一个前面几楼讲得相对少的角度：从运维视角看故障域和迁移路径。客户端分片没有中心节点，单应用实例故障只影响该实例，分片规则随应用版本走，扩容时连接数随实例数线性增长，排查时看应用日志即可定位到分片SQL。代理中间件则把连接、路由、慢SQL集中到Proxy层，DBA可统一看路由命中率和慢查询，但Proxy节点本身成为关键路径，需要多节点加负载均衡，节点故障时要靠健康检查摘除，否则会拖慢所有应用。迁移建议：先在测试环境用真实分片键和跨库查询压测，再用双写或影子流量验证路由，确认无误后按应用灰度切流，不要一次性全量切换；无论哪种方式，跨库事务和跨库分页都要单独验证，不能默认中间件替你解决。

收到,但是没中奖,可惜了

分库分表后，单库自增主键最大的问题不是性能，而是各分片各自递增必然重复，所以必须有一个跨分片全局唯一的生成规则。选型先看三个问题：是否需要有序、是否能接受中心依赖、单机写入量有多大。 一、常见方案对比1. UUID：无需中心节点，生成简单；随机 UUID 无序、128 位字符串较长，做主键时 B+ 树插入分散、索引和存储成本高。只要求唯一、不要求有序的日志、事件、追踪 ID 可以用，优先用带时间前缀的 UUIDv7，索引友好度好于随机 UUID。2. 数据库自增加步长：按分片数设步长和起始偏移，例如分片数 4，四个库分别从 1、2、3、4 起步、步长 4，全局递增且实现简单，但扩容改步长麻烦，中心库压力和单点问题仍在，只适合中小规模。3. 号段模式：号段表按业务保存下一个可用区间，发号服务一次批量取一段（例如 1000 个）放在内存里递增，用完再取。一次数据库交互可发上千个号，数据库压力被摊薄，重启只是丢掉未用完的号段，不会重复；代价是多一个中心依赖，号段服务要做高可用，适合大多数业务表，也是性价比最高的选择。4. Snowflake：64 位整数，结构是 1 位符号位 + 41 位毫秒时间戳 + 10 位机器 ID + 12 位序列号，单机每毫秒最多 4096 个，41 位时间戳约可用 69 年。时间戳在高位，ID 趋势递增，对 B+ 树插入友好，无中心依赖，适合高并发、多机房场景；代价是强依赖时钟，这也是下面要重点处理的问题。机器 ID 还可以再拆为数据中心 ID 和工作节点 ID，例如 5 位 + 5 位，便于按机房分配。 二、Snowflake 时钟回拨为什么会重复Snowflake 假设时间只向前。发号器会记录上次发号时间戳 lastTimestamp，一旦当前时间 now 小于 lastTimestamp，说明时钟回拨了；如果仍用回拨后的时间戳和原来的机器 ID、序列号组合，就可能生成与之前相同的 ID。回拨来源常见于 NTP 校时跳变、虚拟机快照恢复、容器迁移和人工改时间，不是只改一行代码就能避免的。 三、时钟回拨分层处理1. 小幅回拨等待：回拨在阈值内（例如几毫秒到 1 秒，阈值写进配置而不是藏在代码常量里），生成器自旋等待，直到系统时间追上 lastTimestamp 再继续。业务只会短暂变慢，不会丢号，这是对业务影响最小的做法。2. 超过阈值拒绝并告警：回拨超过阈值时直接抛异常、拒绝发号，让上游重试或走降级，宁可写入失败，也不要静默生成可能重复的主键。同时要告警并记录回拨幅度，由运维确认时钟后再恢复。3. 机器 ID 漂移：10 位机器位最多 1024 个节点，实际部署往往远小于这个数。可以预留一部分机器位作备用 workerId：正常用主 workerId，检测到回拨且无法等待时切换到未使用的备用 workerId 继续发号，因为机器位不同，即使时间戳重复也不会撞号；等时钟恢复后再切回主 workerId，并做好切换记录。4. 预留位与持久化：可以从时间戳位中让出 1 到 2 位作回拨计数，用计数器吸收短时回拨，代价是可用年限缩短，每让 1 位大约少 34 年；更稳妥的做法是把 lastTimestamp 持久化到 ZooKeeper、etcd 或数据库，服务重启后先读回上次值并校验，防止重启后时间倒退造成重复。两种做法可以组合，但不要只依赖内存里的 lastTimestamp。 四、落地时容易忽略的细节1. 机器 ID 必须中心化分配和回收：不要用 IP 末位、Pod 序号或进程号推导 workerId，容器重建、迁移后这些值会变，最容易撞号。启动时向注册中心申请并续租，拿不到就拒绝启动。2. 校时方式：NTP/Chrony 尽量用平缓校正而不是跳变校时，禁止业务机器人工改时间，改时间前先停掉发号服务，并监控时间偏移，偏移超阈值先告警。3. 主键和分片键分开：雪花 ID 高位是时间，直接做分片键会让写流量持续压向最新分片，形成写热点。分片键宜用分布均匀的业务字段（例如用户 ID 取模），雪花 ID 只做主键。4. 前后端精度：雪花 ID 是 64 位长整数，超过 JavaScript 安全整数范围，返回前端必须序列化成字符串，否则末几位会被抹掉。5. 上线前做回拨演练：模拟小幅回拨、大幅回拨、序列号打满、重启后时间倒退，确认等待、拒绝、切换备用 workerId、告警、持久化校验几条路径都真的走得通。 五、选型结论只要求唯一、不要求有序：UUIDv7；写入量不大、能接受中心依赖：号段模式；超高并发、不能有中心单点：Snowflake 加回拨检测、备用 workerId 和持久化 lastTimestamp；要求强一致的跨库事务，ID 方案本身解决不了，还要结合分片键和业务幂等一起设计。一句话：先按有序性、中心依赖和写入量选方案，再把时钟回拨当作一定会发生的事来防御，而不是当作偶发异常来事后补救。

先说结论：报错 lookup xxx.default.svc.cluster.local on 10.247.3.10:53: read udp i/o timeout 的意思是，Pod 在超时时间内没有收到 DNS 响应。间歇性、几秒自愈、重试成功，说明 CoreDNS 大概率没有彻底挂，而是某个环节在高峰或个别节点上丢包、排队或被限流。Running 只说明进程在，不说明查询没有排队。定位不要先扩容，要用对照实验把故障段定死：客户端、Service、CoreDNS、节点网络、上游，一段一段排除。 一、先定性：三个问题缩小范围1. 只在集群内 Service 名超时，还是外部域名也超时？前者与上游无关，查 CoreDNS 和节点链路；后者再查 forward 上游。2. 全集群抖，还是只集中在个别节点、个别 Pod？只在个别节点复现，优先查该节点网络和 conntrack，而不是 CoreDNS 全局。3. 超时是否与业务高峰、定时任务同步？同步出现多半是请求量冲高导致的排队或限流。动手前先记下故障时间、Pod 所在节点、查询域名和解析结果，后面所有对照都要和这个时间对齐。 二、客户端侧：先排除查询被放大在故障 Pod 内看 cat /etc/resolv.conf，确认 nameserver 是不是当前 kube-dns Service 的 ClusterIP。先用 kubectl -n kube-system get svc kube-dns 核实 10.247.3.10 是否仍是当前地址，集群重建或改过 Service 后地址会变，别拿着旧地址查半天。默认 ndots:5 下，短名字会按 search 域逐个拼接试解析，一次业务调用可能放大成多次查询；Go、Java 等运行时的解析器还会同时发 A 和 AAAA 两路查询。再乘以业务并发，CoreDNS 的 QPS 会被放大数倍。对照：dig 完整域名 xxx.default.svc.cluster.local（带结尾点更好）与 dig 短名字 xxx 分别测。完整域名稳定、短名字才抖，优先让业务代码用完整域名，必要时在 Pod 的 dnsConfig 里收紧 search 域或调 ndots，并在测试 Pod 先验证。另外，glibc 默认单次查询超时 5 秒、重试 2 次，这就是“失败持续几秒后又自行恢复”的来源之一：不是 DNS 自己好了，是重试赶上了空闲窗口。不要只看一次成功，要连续测 20 到 50 次看失败率和耗时分布：for i in $(seq 1 50); do dig xxx.default.svc.cluster.local +time=2 +tries=1 | grep 'Query time' || echo timeout; done 三、四组对照实验，把故障段定死1. Service IP 对 CoreDNS Pod IP：dig @10.247.3.10 xxx.default.svc.cluster.local 与 dig @ xxx.default.svc.cluster.local 对比。Service IP 超时、Pod IP 正常，查 kube-proxy、Service 端点和节点数据面；两者都超时，查 CoreDNS 负载和节点网络。2. 集群内对外部：nslookup xxx.default.svc.cluster.local 与 nslookup www.example.com。集群内域名由 CoreDNS 的 kubernetes 插件直接回答，一般不走上游；只有外部域名异常，才重点查 forward 配置和上游。3. 故障节点对正常节点：同一查询在不同节点 Pod 里各跑 50 次。只在个别节点抖，查该节点；全集群抖，查 CoreDNS 全局。4. 高峰对平峰：把超时时刻与业务 QPS、定时任务、CoreDNS 指标曲线对齐。 四、CoreDNS 本体：日志、指标、资源三件套kubectl -n kube-system get pods -o wide | grep coredns，看副本分布、重启次数、是否集中在同一节点；kubectl -n kube-system logs -l k8s-app=kube-dns --since=30m | grep -iE 'timeout|SERVFAIL|refused'，看故障时段有没有超时、SERVFAIL、转发失败。节点 CPU 不高不等于 CoreDNS 不被限流，要看 Pod 自身的 CPU limit 和节流：kubectl top pod、describe pod 看 RESTARTS 和 events，Prometheus 里看 container_cpu_cfs_throttled_seconds_total 是否在故障时段抬升。关键指标（Prometheus）：请求量 sum(rate(coredns_dns_requests_total[5m])) by (rcode)，P99 延迟 histogram_quantile(0.99, sum(rate(coredns_dns_request_duration_seconds_bucket[5m])) by (le))，缓存命中率 coredns_cache_hits_total / coredns_dns_requests_total，转发失败看 coredns_forward 相关指标。延迟和 SERVFAIL 与故障时间同步抬升，才是 CoreDNS 瓶颈的实锤；指标平稳而客户端超时，问题多半在链路或客户端。副本数不要拍脑袋：按峰值 QPS 除以单副本可承受 QPS 估算，至少保留 2 副本、用反亲和打散到不同节点；节点多时可配 CoreDNS Autoscaler 按节点数自动调副本。扩容前先备份 Corefile，生产变更走 CCE 组件配置持久化，不要只 kubectl scale 临时改。 五、节点网络：conntrack、抓包、TCP 53UDP 查询量大时，conntrack 表满或 UDP 超时回收会表现为随机丢包式超时，扩 CoreDNS 副本解决不了。节点上看：cat /proc/sys/net/netfilter/nf_conntrack_count 与 nf_conntrack_max 的比值、conntrack -S、dmesg -T | grep -i 'nf_conntrack: table full'。表满要调大 nf_conntrack_max，并同步调大 nf_conntrack_buckets，只调上限会加剧哈希冲突。抓包确认请求到底有没有到 CoreDNS：在 CoreDNS Pod 所在节点 tcpdump -i any -nn port 53 -c 100。有请求无响应，看 CoreDNS；无请求，看 iptables/IPVS 转发或 Service 端点是否为空（kubectl -n kube-system get endpoints kube-dns，以及 endpointslices）。别漏 TCP 53：响应超过 512 字节被截断时会转 TCP 重查，安全组或 NetworkPolicy 只放 UDP 53、没放 TCP 53，大记录查询就会间歇失败。VPC 网络模式下还要看节点 ENI 配额与路由。 六、上游与 Corefilekubectl -n kube-system get configmap coredns -o yaml，重点看 forward、cache、errors、health、ready、loop、loadbalance、kubernetes 插件的配置与顺序。外部域名异常时，从 CoreDNS Pod 内直接 dig @上游地址> www.example.com，验证上游可达性与延迟，并确认上游地址、路由、安全组没有阻断 UDP/TCP 53。不要未经评估把 forward 改成固定公共 DNS，要用网络环境允许且经过验证的上游，并确认其具备内网域名解析能力。 七、找噪声源：是谁在打爆 CoreDNS扩容前先找噪声源，否则只是把噪声放大。临时开启 CoreDNS 的 log 插件（或用 Prometheus 按客户端聚合），把查询按来源 Pod IP 聚合排序；常见噪声源是某个 Pod 的短名字高频查询、健康检查或重试风暴。找到后先修客户端（完整域名、合理重试间隔与退避、应用层缓存），再谈扩容。 八、根治方向与验证按证据选，不要一次全改：1. search/ndots 放大：业务用完整域名，收紧 dnsConfig。2. CoreDNS 排队或单点：加副本、反亲和打散、放宽 CPU limit、配 Autoscaler。3. 跨节点 UDP 丢包或 conntrack 压力：部署 NodeLocal DNSCache（节点本地缓存，Pod 先问本机 169.254.20.10，未命中再转发 CoreDNS），可把 CoreDNS 的 QPS 降一个数量级，同时消除跨节点 UDP 查询和连接跟踪压力。4. 重复查询多：评估 cache 30 等短期缓存，TTL 不宜过长，避免服务地址变更后客户端长期拿到旧记录；负向缓存也可能延迟新建服务被发现。验证：改完不要只看一次成功，在多个节点的业务 Pod 里连续 dig 50 次，看超时率是否归零、P99 延迟是否回落；对照故障时段看 SERVFAIL 数是否回落；并给 DNS P99 延迟、SERVFAIL 率、CoreDNS CPU 节流加告警，下次抖动能第一时间定位到段。

df -h 只看「區塊容量」，寫入失敗報 No space left on device（ENOSPC）的原因不只容量。建議先定位、再清理，依序排查。 【一】先確認寫入路徑落在哪個檔案系統：很多人只看根目錄的 df -h，但報錯的目錄可能掛在別的分區，例如 /tmp 是 tmpfs，/var/log 或 /data 是獨立掛載。先對報錯路徑本身執行 df -h 與 df -i，確認看的是同一塊盤。 【二】查 inode 是否耗盡：執行 df -i，查看 IUse% 是否到 100%。到 100% 時，即使容量還有空間也建不了新檔案。常見元凶是海量小檔案，例如 session、快取、郵件佇列。先用 find / -xdev -type d -size +100k 定位小檔案最多的目錄，再清理舊的暫存檔與日誌分片。 【三】查已刪除但仍被行程佔用的檔案（最常見）：檔案被 rm 後，只要還有行程持有檔案描述符，磁碟空間就不會釋放，df 和 du 都看不到。執行 lsof | grep deleted 或 lsof +L1，看到 deleted 且 SIZE 很大的項目，重新啟動對應服務或讓它重新開啟日誌檔，空間立即釋放。應急時可對 /proc//fd/ 做截斷，但生產環境優先重啟服務。 【四】查保留塊：ext4 預設給 root 保留約 5% 空間，df -h 顯示的剩餘空間包含這部分，普通使用者實際可用的是 Avail 欄位。執行 tune2fs -l /dev/xxx | grep -i reserved 確認比例，必要時用 tune2fs -m 調整，建議留 1%，不要直接調成 0。 【五】查掛載點遮擋：某個目錄又被掛上另一個檔案系統時，舊內容會被遮住，df 與 du 看到的不是同一層。執行 findmnt 或 cat /proc/mounts 核對掛載關係，確認寫入路徑與 df 統計的是同一層。 【六】查 Docker／日誌佔滿：服務跑在容器裡時，容器內的 df 不一定是宿主機的真實剩餘空間，要看宿主機上 overlay 層所在分區的 df -h 與 df -i，執行 docker system df 查看容器層占用。另外檢查 /var/log 與 /var/lib/docker 是否被日誌或映像層佔滿，可用 journalctl --vacuum-size=100M 清理日誌，或 docker system prune 清理無用映像，prune 前先確認沒有正在使用的映像與容器。 排查順序建議：df -h 報錯目錄 → df -i → lsof | grep deleted → tune2fs 查保留塊 → findmnt 核對掛載 → docker system df 查容器層。依序走一遍，多數「有空間卻寫不進」的問題都能定位。

結論先說：只關機不等於停費；確定徹底不用了，要做「刪除／釋放」，並把雲硬碟和彈性公網 IP 一併處理掉。 一、按量付費 ECS 的費用分四塊，關機後表現各不相同1. 實例算力（vCPU／記憶體）：普通關機後，vCPU 和記憶體資源仍為你保留占用，會繼續按實例規格計費。只有在關機時勾選「關機不收費」（部分規格／區域支援，控制台關機時會有提示），關機期間算力才停止計費。2. 雲硬碟（系統碟＋資料碟）：獨立按容量計費，開關機都不影響它；系統碟一般隨實例刪除，資料碟預設保留，刪實例後仍會單獨計費。3. 彈性公網 IP（EIP）：獨立計費；綁定時按頻寬／流量計費，解綁後若不釋放，會改收閒置保有費。4. 快照／映像／備份：超出免費額度的部分也會按容量持續計費。 二、兩種場景怎麼做場景 A：短期暫停、之後還要用——關機時選「關機不收費」，並把不用的 EIP 釋放掉；需要時再開機，資料都在。注意關機後實例仍占用配額。場景 B：確定徹底不用——先備份（整機映像或雲硬碟快照，並確認備份可用）→ 控制台刪除實例（勾選同時刪除系統碟，資料碟按需一併刪除）→ 解綁並釋放不再用的 EIP → 清理多餘快照／備份 → 到費用中心「帳單 → 按產品／按資源」核對，確認沒有持續出帳的項目。 三、容易踩的坑1. 資料碟預設不隨實例刪除，很多人刪了實例還在為一塊碟付費。2. 關機後再開機，公網 IP 在非固定頻寬場景可能變化，走域名解析的要注意。3. 建議開啟費用告警／預算，按量付費最容易出現「忘了釋放」的持續扣費。 一句話：關機是「暫停使用」，釋放才是「停止計費」。