Project: UPI Daily Spend Tracker
UPI Daily Spend Tracker: Turning Daily Bank Alerts into Real-Time Analytics
Deep dives into database technologies like MySQL, GTID replication, high availability, and disaster recovery. Also covering OLAP solutions like Snowflake, distributed systems, Kafka-based event-driven architectures, and cloud infrastructure using AWS services like RDS, S3, and CDC pipelines into modern data warehouses.
UPI Daily Spend Tracker: Turning Daily Bank Alerts into Real-Time Analytics
A real-world production incident where a small table_open_cache caused severe query slowdowns, how we diagnosed it, and what fixed it.
We recently faced a subtle but critical disk space bloat issue on one of our MySQL production nodes, and the root cause turned out to be how Percona’s pt-heartbeat handles logging during log rotation. This blog details the original setup, what went wrong, and the fix that worked for us.
Background
During a recent performance test on one of my MySQL instances, I noticed the Disk I/O Utilization graph pegged at 100%. Queries started slowing down, and it was clear the instance was hitting an I/O bottleneck.
Setting up a disaster recovery (DR) pipeline between your on-premise MySQL database and Amazon RDS can be a game-changer for data resilience. In this blog, I’ll walk through how I automated a reliable backup + replication process using Percona XtraBackup, AWS S3, and RDS’s restore-from-S3 capability.
During a scheduled maintenance window on a Saturday, I promoted one of our MySQL replicas to act as the new primary. Everything went smoothly — replication was caught up, read_only was disabled, writes were flowing in, and the app stayed healthy.
Primary promotion before the introduction of GTID used to be a manual and highly error-prone task. GTIDs simplified it by eliminating the need to be aware of the binary log file names and positions to do a promotion or swap.