<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Operations on Chen Kai Blog</title><link>https://www.chenk.top/en/tags/operations/</link><description>Recent content in Operations on Chen Kai Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 30 Apr 2024 09:00:00 +0000</lastBuildDate><atom:link href="https://www.chenk.top/en/tags/operations/index.xml" rel="self" type="application/rss+xml"/><item><title>Databases (8): Databases in Practice — Migration, Monitoring, and War Stories</title><link>https://www.chenk.top/en/databases/08-database-in-practice/</link><pubDate>Tue, 30 Apr 2024 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/databases/08-database-in-practice/</guid><description>&lt;p>Knowing how databases work internally is half the battle. The other half is keeping them running in production without losing data, dropping availability, or waking up at 3 AM. This article covers the operational knowledge that comes from experience — the things nobody teaches you until something breaks.&lt;/p>
&lt;hr>
&lt;h2 id="schema-migrations-changing-the-engine-while-flying" class="heading-anchor">Schema Migrations: Changing the Engine While Flying&lt;a href="#schema-migrations-changing-the-engine-while-flying" class="heading-link" aria-label="Permalink to this section" title="Copy link to this section">#&lt;/a>
&lt;/h2>&lt;p>Your schema will change. New features require new columns, new tables, new indexes. The question is how to evolve the schema without downtime.&lt;/p></description></item></channel></rss>