<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Mysql on cloudplz</title><link>https://cloudplz.cc/tags/mysql/</link><description>Recent content in Mysql on cloudplz</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Fri, 20 Dec 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://cloudplz.cc/tags/mysql/index.xml" rel="self" type="application/rss+xml"/><item><title>Aurora Migration Toolkit</title><link>https://cloudplz.cc/projects/aurora-migration-toolkit/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/projects/aurora-migration-toolkit/</guid><description>&lt;p&gt;Migrating a single database to Aurora is a project. Migrating fifty —&#10;including multi-terabyte, tier-0 systems with 24/7 write traffic — is a&#10;platform. This is the toolkit and methodology that made it repeatable.&lt;/p&gt;&#10;&lt;h2 id="challenge"&gt;Challenge&#10;&lt;/h2&gt;&#10;&lt;p&gt;Each team&amp;rsquo;s database had different constraints: replication lag budgets,&#10;change-freeze windows, version skew between on-premises MySQL and Aurora,&#10;and applications that had grown assumptions about their database over a&#10;decade. One-off migration plans did not scale to fifty of them.&lt;/p&gt;</description></item><item><title>Vitess Production Deployment</title><link>https://cloudplz.cc/projects/vitess-production-deployment/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/projects/vitess-production-deployment/</guid><description>&lt;p&gt;Running Vitess in production for three years teaches you where horizontal&#10;scaling actually bites: ops discipline, not demos. This is the record of&#10;what it took to run the system that powers YouTube&amp;rsquo;s MySQL fleet, at a&#10;scale far smaller than YouTube&amp;rsquo;s — and why that changes the calculus.&lt;/p&gt;&#10;&lt;h2 id="challenge"&gt;Challenge&#10;&lt;/h2&gt;&#10;&lt;p&gt;A MySQL deployment outgrowing vertical scale: write volume and working&#10;set exceeding what a single well-tuned instance could absorb, with&#10;availability requirements that ruled out naive primary failover.&lt;/p&gt;</description></item><item><title>Vitess vs Aurora: Making the Right MySQL Scaling Decision</title><link>https://cloudplz.cc/writing/vitess-vs-aurora-mysql-scaling/</link><pubDate>Fri, 20 Dec 2024 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/writing/vitess-vs-aurora-mysql-scaling/</guid><description>&lt;p&gt;If you&amp;rsquo;ve outgrown single-instance MySQL, you&amp;rsquo;re facing an uncomfortable choice: build custom sharding logic into your application, migrate to a different database system, or adopt a clustering solution like Vitess.&lt;/p&gt;&#10;&lt;p&gt;Here&amp;rsquo;s the short version, so you know whether to keep reading: &lt;strong&gt;after running Vitess in production for 3 years, we migrated off it — to Aurora.&lt;/strong&gt; Not because Vitess failed us, but because the one capability that justified its operational cost (horizontal write sharding) turned out to be a capability we never actually needed. If your write traffic genuinely exceeds what one large primary can take — think tens of thousands of writes per second sustained, not bursts — Vitess is likely your answer and this post will tell you what operating it really costs. If you&amp;rsquo;re below that bar, Aurora is almost certainly the better decision, and this post will tell you why.&lt;/p&gt;</description></item></channel></rss>