Flyway Schema迁移：生产环境新增表且保留既有带数据表的需求与问题

Got it, let's break this down clearly—you're totally right that Flyway's default behavior can feel risky when you're working with a live production database that you can't afford to mess up. The key here is using Flyway's baseline feature to mark your current database state as the starting point, so Flyway leaves it alone and only runs your new migration scripts. Here's exactly what to do:

Step 1: Disable Flyway's Clean Feature (Critical!) #

First, lock down Flyway's clean command to prevent accidental deletion of your existing tables. Add this to your Flyway configuration (whether it's a .properties file, environment variables, or command-line args):

flyway.cleanDisabled=true

This ensures even if someone runs the wrong command, your production tables stay untouched.

Step 2: Baseline Your Existing Database #

Flyway needs to recognize your current production schema (with all existing tables and data) as the "initial" state it shouldn't modify. You have two straightforward options:

Option A: Run the Baseline Command Manually #

If you can run Flyway commands directly against your production database, execute:

flyway baseline

By default, this marks your current database as version 1. If you want to reserve 1 for future migrations, set a custom baseline version like:

flyway baseline -baselineVersion=0

Option B: Auto-Baseline on First Migrate #

If you prefer Flyway to handle the baseline automatically when you first run migrations, add this to your config:

flyway.baselineOnMigrate=true

This tells Flyway: "If there's no existing schema history table, create it and mark the current database state as the baseline version."

Step 3: Write Your New Migration Scripts #

Create new migration files following Flyway's naming rule: V{version}__{description}.sql. For example, if your baseline version is 1, your first new script would be V2__create_user_metadata_table.sql. Only include SQL to create new tables—no DROP or ALTER statements for existing tables (unless you've thoroughly planned and tested those changes).

Example script content:

CREATE TABLE user_metadata (
    id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT NOT NULL,
    preferences JSON,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (user_id) REFERENCES users(id)
);

Step 4: Run the Migration #

Execute the migrate command:

flyway migrate

Flyway will check its auto-created flyway_schema_history table, recognize your baseline version, and only run migrations with higher versions. It will create your new tables without touching any existing data or tables.

Quick Best Practices #

• Test in Staging First: Always replicate your production database in a staging environment and run the full baseline + migrate flow there to confirm no issues.
• Leave the Schema History Table Alone: Flyway uses flyway_schema_history to track applied migrations—don't edit or delete this table.
• Double-Check Scripts: Scan every migration script to ensure it doesn't modify existing tables unless you explicitly intend to.

内容的提问来源于stack exchange，提问作者VIJ