<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>数据库运维 on 黄文卓 | DevOps Engineer</title><link>https://socake.github.io/tags/%E6%95%B0%E6%8D%AE%E5%BA%93%E8%BF%90%E7%BB%B4/</link><description>Recent content in 数据库运维 on 黄文卓 | DevOps Engineer</description><generator>Hugo -- gohugo.io</generator><language>zh-CN</language><managingEditor>17691281867@163.com (Wenzhuo Huang)</managingEditor><webMaster>17691281867@163.com (Wenzhuo Huang)</webMaster><copyright>© 2026 Wenzhuo Huang</copyright><lastBuildDate>Wed, 20 Nov 2024 15:00:00 +0800</lastBuildDate><atom:link href="https://socake.github.io/tags/%E6%95%B0%E6%8D%AE%E5%BA%93%E8%BF%90%E7%BB%B4/index.xml" rel="self" type="application/rss+xml"/><item><title>MongoDB 分片集群实战：从 shard key 设计到 chunk 均衡的全链路</title><link>https://socake.github.io/posts/mongodb-sharding-practice/</link><pubDate>Wed, 20 Nov 2024 15:00:00 +0800</pubDate><author>17691281867@163.com (Wenzhuo Huang)</author><guid>https://socake.github.io/posts/mongodb-sharding-practice/</guid><description>很多团队把 MongoDB 分片当成&amp;quot;设个 shard key 就完事&amp;quot;，结果上线半年后发现 80% 数据在一个 shard 上、balancer 每天搬几十 GB 却怎么都追不上、某个 collection 出现 jumbo chunk 无法分裂。这篇文章把我在几套 MongoDB 分片集群上的经验整理出来，希望能让你在分片之前少走一些弯路。</description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://socake.github.io/posts/mongodb-sharding-practice/featured.jpg"/></item><item><title>Redis Cluster 扩缩容与数据迁移实战：从 SETSLOT 到 Atomic Slot Migration</title><link>https://socake.github.io/posts/redis-cluster-migration/</link><pubDate>Fri, 08 Nov 2024 10:30:00 +0800</pubDate><author>17691281867@163.com (Wenzhuo Huang)</author><guid>https://socake.github.io/posts/redis-cluster-migration/</guid><description>很多团队把 Redis Cluster 当成&amp;quot;开箱即用&amp;quot;的分布式 Redis，直到要做扩缩容或数据迁移时才发现：SETSLOT 协议里有十几种状态，迁移过程中客户端重定向要么不生效要么风暴，migrate 卡住没法断，big key 直接把迁移拖垮。这篇文章把我在几套千亿级 Cluster 上做过的扩缩容、迁移、救火全过一遍。</description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://socake.github.io/posts/redis-cluster-migration/featured.jpg"/></item><item><title>PostgreSQL 膨胀治理：把 autovacuum 调到你真正需要的样子</title><link>https://socake.github.io/posts/postgresql-vacuum-bloat-tuning/</link><pubDate>Tue, 29 Oct 2024 09:30:00 +0800</pubDate><author>17691281867@163.com (Wenzhuo Huang)</author><guid>https://socake.github.io/posts/postgresql-vacuum-bloat-tuning/</guid><description>大部分 PostgreSQL DBA 对 autovacuum 的理解停留在&amp;quot;它会自己跑&amp;quot;，但一旦膨胀起来才发现：默认参数对现代硬件完全不够用，几十个 autovacuum_* 参数各管一摊，出了问题根本不知道从哪儿看。这篇文章把我在几套 PG 集群上治理膨胀的经验整理出来，从 MVCC 原理讲到参数调优、从监控到应急处置。</description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://socake.github.io/posts/postgresql-vacuum-bloat-tuning/featured.jpg"/></item><item><title>TiDB 生产环境实战：从 Placement Rules 到 TiKV 调优的全链路经验</title><link>https://socake.github.io/posts/tidb-production-practice/</link><pubDate>Sat, 05 Oct 2024 10:00:00 +0800</pubDate><author>17691281867@163.com (Wenzhuo Huang)</author><guid>https://socake.github.io/posts/tidb-production-practice/</guid><description>把 TiDB 当成&amp;quot;分布式 MySQL&amp;quot;跑起来并不难，真正难的是让 TiKV 在高并发写入下不抖动、让 PD 调度不误伤业务、让跨机房副本在 RPO=0 的前提下活下去。本文把过去两年我在几套 TiDB 集群上踩过的坑、调过的参数和定过的 SOP 都摊开来讲，不是教程，而是一份能直接照抄的作战手册。</description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://socake.github.io/posts/tidb-production-practice/featured.jpg"/></item></channel></rss>