https://devops-monk.com/tags/mysql/Recent content in Mysql on Devops MonkHugoen-usSun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-changelog-formats/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-changelog-formats/Liquibase supports four changelog formats: XML, YAML, JSON, and SQL. The format you pick affects readability, tooling support, and what features are available. This article shows the same changeset in all four formats so you can compare them directly — then explains when each format is the right choice. The Same Change in All Four Formats To make comparison concrete, here is a single changeset — creating the users table from the e-commerce schema — written in every format.https://devops-monk.com/tutorials/liquibase/liquibase-changelog-organization/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-changelog-organization/A single changelog file works fine for a tutorial. It stops working the moment two developers add migrations on the same day, or when you need to find the changeset that introduced a column added six months ago, or when a feature branch’s migrations must be reviewed independently before merging. Changelog organization is not a polish step — it is what determines whether Liquibase stays manageable at scale or turns into a source of merge conflicts and mystery failures.https://devops-monk.com/tutorials/liquibase/liquibase-migration-patterns/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-migration-patterns/Most Liquibase guides explain change types by listing them. This article is different — it walks through twelve patterns you will encounter repeatedly in a real project, explains the MySQL-specific behaviour of each, and shows the rollback you need to write alongside every change. All examples build on the ecommerce database established in Part 1. By the end, you will have a complete reference you can reach for on any working day.https://devops-monk.com/tutorials/liquibase/liquibase-contexts-labels/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-contexts-labels/The most common multi-environment problem in database migrations: seed data that should run in dev and staging but must never touch production. The naive solution is maintaining separate changelogs per environment. The correct solution is contexts and labels — Liquibase’s built-in filtering mechanism that lets a single changelog serve every environment. This article covers both features, explains the critical difference between them, and shows exactly how to wire them into Spring Boot profiles.https://devops-monk.com/tutorials/liquibase/liquibase-core-commands/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-core-commands/Liquibase has over 50 commands. In practice, you will use fewer than ten of them for 95% of your work. This article covers those ten commands — what each one does, when to reach for it, and what the output tells you. Every example builds on the ecommerce database and users table from Article 4. The commands are organized by what you’re trying to accomplish: inspect, apply, undo, and verify.https://devops-monk.com/tutorials/liquibase/liquibase-core-concepts/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-core-concepts/Before writing a single migration, you need the mental model. Understanding how Liquibase thinks about changelogs, changesets, and identity prevents the most common mistakes — ones that are painful to fix after deployment. The Changelog The changelog is the file Liquibase reads. It contains an ordered list of changesets. Think of it as your database’s Git history — a sequential record of every change ever made. # db/changelog/db.changelog-master.yaml databaseChangeLog: - changeSet: id: "20240101-001" author: abhay changes: - createTable: tableName: users columns: - column: name: id type: BIGINT autoIncrement: true constraints: primaryKey: true nullable: false - changeSet: id: "20240101-002" author: abhay changes: - addColumn: tableName: users columns: - column: name: email type: VARCHAR(255) constraints: nullable: false unique: true The changelog format (YAML, XML, SQL) doesn’t matter for understanding the concept — it’s always a list of changesets in order.https://devops-monk.com/tutorials/liquibase/liquibase-diff-reverse-engineering/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-diff-reverse-engineering/Most Liquibase tutorials start with a blank database. Most real projects start with a production database that has been evolving for years without version control. This article covers the complete workflow for adopting Liquibase on an existing database — generating a baseline changelog, bootstrapping Liquibase tracking, detecting drift between environments, and maintaining snapshots for offline comparisons. The Onboarding Problem An existing database has no DATABASECHANGELOG table. Running liquibase update with a fresh changelog would try to create tables that already exist, causing immediate failures.https://devops-monk.com/tutorials/liquibase/introduction-to-liquibase/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/introduction-to-liquibase/Your application code is in Git. Every change is tracked, reviewed, and reversible. Your database schema is not — it lives in someone’s head, a shared wiki page, or a folder of SQL scripts with names like fix_final_v3.sql. This is the problem Liquibase solves. The Problem: Database Drift On a typical team without database versioning: Developer A adds a column locally and forgets to tell anyone Developer B’s tests fail on a table that exists on A’s machine but not on B’s Staging has 3 extra columns that production doesn’t — or vice versa Nobody knows what the “correct” schema state is Deploying to production means manually running SQL scripts while hoping nothing was missed This is database drift — the schema diverges between environments and nobody tracks when or why.https://devops-monk.com/tutorials/liquibase/liquibase-mysql-specific-patterns/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-mysql-specific-patterns/Liquibase’s change types generate standard SQL. MySQL has quirks — character set requirements that differ from the standard, a storage engine option absent from other databases, row format constraints that affect index key length, and DDL locking behaviour that makes a 10-second table lock acceptable in dev and catastrophic in production. This article covers the MySQL-specific patterns that you will need once you move from tutorial projects to real production databases.https://devops-monk.com/tutorials/liquibase/liquibase-preconditions/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-preconditions/A migration assumes the database is in a specific state. It assumes the table it references exists, the column it modifies is the right type, the user running it has the right privileges, and the database is the right engine. When those assumptions are violated — a hotfix was applied manually, a migration ran out of order, someone ran the wrong changelog against the wrong database — the migration fails in a way that can be hard to diagnose.https://devops-monk.com/tutorials/liquibase/liquibase-property-substitution/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-property-substitution/A changeset that hard-codes the schema name ecommerce works in production but breaks when your staging database is called ecommerce_staging. A changeset that seeds a specific admin email works in dev but shouldn’t run with the same value in staging. Property substitution lets you parameterize these values so one changelog serves every environment. How Property Substitution Works Liquibase replaces ${property-name} tokens in your changelog with the value assigned to that property before executing any SQL.https://devops-monk.com/tutorials/liquibase/liquibase-production-rollback/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-production-rollback/Article 9 covered what rollback commands exist. This article covers how to make rollback reliable in production — where a slow or broken rollback costs real money and real users. The difference between knowing the commands and having a working rollback strategy is process: mandatory tagging, pre-generated rollback files, CI gates, and a decision tree that removes guesswork during an incident. Why Rollback Fails in Production Rollback failures in production share a small set of root causes:https://devops-monk.com/tutorials/liquibase/liquibase-rollback-strategies/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-rollback-strategies/Rollback is the thing you build at 2am when the deployment broke production. The problem is that 2am is exactly the wrong time to discover your rollback blocks are missing, incomplete, or untested. This article covers rollback from a strategy perspective: how Liquibase generates rollback, when you must write it yourself, how to handle change types that cannot be rolled back at all, and how to validate your rollback strategy in CI so it works when you need it.https://devops-monk.com/tutorials/liquibase/liquibase-spring-boot-integration/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-spring-boot-integration/Running Liquibase from the CLI is fine for learning and for standalone scripts. In a real Spring Boot application, you want migrations to run automatically at startup — before the application code touches the database. Spring Boot’s Liquibase auto-configuration handles this with zero boilerplate: add the dependency, point to your changelog, and migrations run before the application context is ready. This article covers the complete integration: Maven/Gradle setup, how auto-run works and why, the full spring.https://devops-monk.com/tutorials/liquibase/liquibase-stored-objects-mysql/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-stored-objects-mysql/Tables and columns are straightforward in Liquibase — one change type per operation, automatic rollback, clean history. Stored procedures, views, and triggers are different. They contain body SQL that uses semicolons internally, which conflicts with Liquibase’s default statement splitting. They are replaced rather than altered. And unlike tables, modifying them frequently over time is expected. This article covers the mechanics and patterns that make stored objects manageable in Liquibase. The Core Problem: Delimiter Conflicts A stored procedure body contains semicolons to terminate each statement inside it:https://devops-monk.com/tutorials/liquibase/liquibase-team-collaboration/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-team-collaboration/A solo developer can treat Liquibase conventions as suggestions. A team of five cannot. When two developers both write “the next migration” on the same day, without a convention that prevents collision, you get duplicate IDs, merge conflicts on the master changelog, or — worst case — two changesets that silently overwrite each other in DATABASECHANGELOG. This article is the operating agreement for teams using Liquibase: what conventions to establish, how to structure the git workflow, what the PR review checklist looks like, and what to do when conflicts happen despite the conventions.https://devops-monk.com/tutorials/liquibase/liquibase-first-migration/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-first-migration/You’ve read about changesets, tracking tables, and changelog formats. Now you’re going to run your first real migration against a live MySQL database. By the end of this article you will have connected Liquibase to MySQL, written a changelog that creates the users table for our e-commerce app, previewed the SQL it generates, applied it, and verified the result in the database. This is the article where things become real.https://devops-monk.com/tutorials/liquibase/liquibase-zero-downtime-deployments/Sun, 03 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/liquibase/liquibase-zero-downtime-deployments/A RENAME COLUMN statement takes milliseconds. But if your application is still running the old code when the rename executes, every query that uses the old column name fails immediately. Zero-downtime schema changes are not about making DDL faster — they are about sequencing changes so that no single step breaks the running application. The expand-contract pattern is the standard solution. It breaks dangerous migrations into safe, incremental phases that allow old and new application code to coexist with the same database during deployment.