Panel: Running Databases in Containers
summary
Shows concrete wins and concrete failures: people run MySQL/Vitus and TiDB in Docker on Kubernetes using Kubernetes operators to automate failover, but operators once deleted PVs and an upgrade heuristic nuked host volumes causing unrecoverable loss. Workarounds include localPersistentVolume patterns, conservative operator deletes, automated s3 backups plus restore tests, and design changes for cache warm‑start. Also warn about scale cost — a single experiment produces runaway cloud bills. Test disaster drills and assume worst case.
AI-written summary · about
chapters (26)
- 0:00Introduction
- 1:00Panel Introductions
- 3:33What do containers mean to you
- 5:27Are containers deterministic
- 6:38Containers as a fit for purpose
- 7:46Flexibility with containers
- 9:57Scale
- 11:31Orchestration
- 12:52Lego analogy
- 14:46Orchestration and containers
- 17:01Kubernetes operators
- 18:41Inmemory cache
- 21:31Database Containerization
- 22:16Cluster Scalability
- 24:21Point in Time Recovery
- 25:28Kubernetes and Databases
- 26:43HBase and Kubernetes
- 29:09Kubernetes and operators
- 35:11Deployment
- 36:21Story Mode
- 37:11Teddy Operator
- 44:16Kubernetes Primitives
- 45:11Backups
- 49:31Critical Issues
- 51:41Runaway Scaling
- 55:01Cost
related talks
47mFrom a Database in Container to DBaaS on Kubernetes
25mAre Containers Ready for Production Databases?
38mThe Container Operator's Manual
45mBest Practices for Running Databases on Kubernetes
38mThe Container Operator’s Manual
36mFrom a Database in Container to DBaaS on Kubernetes
34mPanel Discussion: Databases
44mRunning Non-Cloud-Native Databases in Cloud-Native Environments