Claude hỗ trợ Database Migration — Từ MySQL sang PostgreSQL an toàn

Migration database từ MySQL sang PostgreSQL là một trong những dự án phức tạp nhất mà team engineering phải đối mặt. Hai hệ thống có nhiều điểm khác biệt về data types, syntax, stored procedures, và hành vi mặc định. Claude có thể đóng vai trò trợ lý đắc lực trong toàn bộ quá trình — từ lập kế hoạch, sinh migration scripts, đến viết queries kiểm tra dữ liệu sau migration.

Chiến lược Migration: Big Bang vs Gradual

Quyết định đầu tiên và quan trọng nhất là chọn chiến lược migration phù hợp.

Big Bang Migration

Chuyển toàn bộ database trong một lần, thường vào cuối tuần hoặc thời gian bảo trì.

• Ưu điểm: Đơn giản về mặt kỹ thuật, không cần duy trì hai hệ thống song song, thời gian dự án ngắn
• Nhược điểm: Downtime dài (có thể nhiều giờ), rủi ro cao — nếu fail phải rollback toàn bộ, áp lực thời gian lớn
• Phù hợp khi: Database nhỏ (dưới 50GB), ứng dụng nội bộ chấp nhận được downtime, team có kinh nghiệm migration

Gradual Migration

Chuyển từng bảng hoặc từng module, chạy song song hai database trong giai đoạn chuyển tiếp.

• Ưu điểm: Rủi ro thấp — fail một phần không ảnh hưởng toàn bộ, gần zero-downtime, có thể rollback từng phần
• Nhược điểm: Phức tạp hơn nhiều, cần dual-write hoặc sync mechanism, thời gian dự án dài hơn
• Phù hợp khi: Database lớn, ứng dụng production cần uptime cao, migration phức tạp cần test từng phần

Prompt để Claude tư vấn chiến lược

Tôi cần migration database từ MySQL sang PostgreSQL.
Hãy tư vấn chiến lược phù hợp dựa trên thông tin sau:

Database hiện tại:
- Kích thước: [Ví dụ: 120GB]
- Số bảng: [Ví dụ: 85 bảng]
- Có stored procedures: [Có/Không, số lượng]
- Có triggers: [Có/Không, số lượng]
- Có views: [Có/Không, số lượng]

Ứng dụng:
- Loại: [Web app / Mobile backend / Internal tool]
- Traffic: [Requests/giây vào peak]
- SLA uptime: [Ví dụ: 99.9%]
- Có thể chấp nhận downtime: [Có/Không, bao lâu]

Team:
- Số engineer: [Số người]
- Kinh nghiệm PostgreSQL: [Có/Không]
- Timeline mong muốn: [Ví dụ: 3 tháng]

Hãy phân tích và đề xuất chiến lược cụ thể, kèm timeline
và danh sách rủi ro cần lưu ý.

Schema Mapping: MySQL -> PostgreSQL

Một trong những bước quan trọng nhất là mapping data types giữa hai hệ thống. Claude giúp bạn xử lý các khác biệt phức tạp.

Bảng mapping data types cơ bản

Prompt để Claude sinh schema mapping

Dưới đây là schema MySQL của tôi. Hãy chuyển đổi sang
PostgreSQL với các yêu cầu:

1. Map data types chính xác (tham khảo bảng mapping chuẩn)
2. Chuyển AUTO_INCREMENT sang SERIAL hoặc IDENTITY
3. Chuyển ENUM sang PostgreSQL ENUM types
4. Xử lý UNSIGNED bằng CHECK constraints
5. Giữ nguyên tên bảng và cột (trừ khi trùng reserved keywords)
6. Chuyển indexes và foreign keys
7. Ghi chú những chỗ cần chú ý đặc biệt

Schema MySQL:
"""
[Dán output của mysqldump --no-data]
"""

Output: PostgreSQL CREATE TABLE statements với comments giải thích
mỗi thay đổi so với MySQL.

Xử lý các trường hợp phức tạp

Một số khác biệt không đơn giản là đổi data type:

Case sensitivity: MySQL mặc định case-insensitive cho string comparison (trừ khi dùng collation binary), trong khi PostgreSQL mặc định case-sensitive. Nếu ứng dụng phụ thuộc vào case-insensitive search, cần thêm CITEXT extension hoặc dùng LOWER() trong queries.

Auto-increment behavior: MySQL sẽ tự tăng ID ngay cả khi INSERT bị rollback, tạo gaps trong sequence. PostgreSQL SERIAL cũng có hành vi tương tự, nhưng nếu dùng GENERATED ALWAYS AS IDENTITY, behavior có thể khác. Cần test kỹ nếu ứng dụng phụ thuộc vào sequential IDs.

Date handling: MySQL cho phép giá trị '0000-00-00' cho DATE columns. PostgreSQL không cho phép. Cần chuyển thành NULL hoặc một giá trị mặc định hợp lệ.

-- Tìm các giá trị ngày không hợp lệ trước khi migrate
SELECT COUNT(*) FROM orders WHERE order_date = '0000-00-00';
SELECT COUNT(*) FROM users WHERE birth_date = '0000-00-00';

-- Cập nhật trước khi migrate
UPDATE orders SET order_date = NULL WHERE order_date = '0000-00-00';
UPDATE users SET birth_date = NULL WHERE birth_date = '0000-00-00';

Claude sinh Migration Scripts

Sau khi có schema mapping, bước tiếp theo là sinh scripts để thực hiện migration.

Prompt sinh migration script

Dựa trên schema mapping sau, hãy sinh migration script hoàn chỉnh:

Schema MySQL gốc:
"""
[Dán schema MySQL]
"""

Schema PostgreSQL đích:
"""
[Dán schema PostgreSQL đã mapping]
"""

Hãy tạo:
1. Script tạo database và extensions cần thiết
2. Script tạo ENUM types
3. Script tạo bảng theo thứ tự phụ thuộc (dependency order)
4. Script tạo indexes
5. Script tạo foreign keys (tạo sau khi import data)
6. Script migrate data cho từng bảng (INSERT INTO ... SELECT)
7. Script cập nhật sequences sau khi import data
8. Script verify: đếm rows mỗi bảng MySQL vs PostgreSQL

Mỗi script có header comment giải thích mục đích.
Sử dụng transaction cho mỗi bảng để dễ rollback.

Xử lý stored procedures

Đây là phần khó nhất của migration vì syntax khác biệt hoàn toàn:

Chuyển stored procedure MySQL sau sang PostgreSQL function.
Giải thích từng thay đổi syntax:

MySQL stored procedure:
"""
DELIMITER $$
CREATE PROCEDURE calculate_monthly_revenue(
    IN p_year INT,
    IN p_month INT,
    OUT p_total DECIMAL(15,2)
)
BEGIN
    SELECT COALESCE(SUM(amount), 0) INTO p_total
    FROM orders
    WHERE YEAR(order_date) = p_year
    AND MONTH(order_date) = p_month
    AND status = 'completed';
END$$
DELIMITER ;
"""

Yêu cầu:
1. Chuyển sang PostgreSQL function (không dùng procedure)
2. Giải thích sự khác biệt giữa MySQL PROCEDURE và PostgreSQL FUNCTION
3. Xử lý các hàm date khác nhau (YEAR(), MONTH() -> EXTRACT())
4. Sử dụng RETURNS thay vì OUT parameter nếu phù hợp

Data Validation Queries

Sau khi migrate, bạn cần xác nhận dữ liệu đã chuyển chính xác. Claude giúp sinh các queries kiểm tra.

Prompt sinh validation queries

Tôi vừa migrate dữ liệu từ MySQL sang PostgreSQL.
Hãy tạo bộ queries kiểm tra cho bảng sau:

Tên bảng: orders
Các cột: id, user_id, product_id, quantity, unit_price, total_amount,
         status, order_date, created_at, updated_at

Tạo queries kiểm tra:
1. Row count comparison (MySQL vs PostgreSQL)
2. Checksum/hash comparison cho 5 cột quan trọng nhất
3. MIN/MAX/AVG cho các cột số
4. NULL count cho từng cột
5. Distinct value count cho cột status
6. Date range comparison (MIN/MAX dates)
7. Sample data comparison (10 rows ngẫu nhiên)
8. Foreign key integrity check

Format: Cặp queries MySQL và PostgreSQL cạnh nhau để dễ so sánh.

Script validation tự động

import mysql.connector
import psycopg2

def validate_table(table_name, mysql_conn, pg_conn):
    """So sánh dữ liệu giữa MySQL và PostgreSQL cho một bảng."""
    results = {"table": table_name, "checks": []}

    # Check 1: Row count
    mysql_cur = mysql_conn.cursor()
    mysql_cur.execute(f"SELECT COUNT(*) FROM {table_name}")
    mysql_count = mysql_cur.fetchone()[0]

    pg_cur = pg_conn.cursor()
    pg_cur.execute(f"SELECT COUNT(*) FROM {table_name}")
    pg_count = pg_cur.fetchone()[0]

    results["checks"].append({
        "name": "row_count",
        "mysql": mysql_count,
        "postgresql": pg_count,
        "match": mysql_count == pg_count
    })

    # Check 2: Numeric column aggregates
    numeric_checks = ["SUM(total_amount)", "AVG(total_amount)",
                       "MIN(total_amount)", "MAX(total_amount)"]
    for check in numeric_checks:
        mysql_cur.execute(f"SELECT {check} FROM {table_name}")
        pg_cur.execute(f"SELECT {check} FROM {table_name}")
        m_val = mysql_cur.fetchone()[0]
        p_val = pg_cur.fetchone()[0]

        # So sánh với tolerance cho floating point
        match = abs(float(m_val or 0) - float(p_val or 0)) < 0.01
        results["checks"].append({
            "name": check,
            "mysql": str(m_val),
            "postgresql": str(p_val),
            "match": match
        })

    return results

def run_full_validation(tables, mysql_config, pg_config):
    """Chạy validation cho tất cả bảng."""
    mysql_conn = mysql.connector.connect(**mysql_config)
    pg_conn = psycopg2.connect(**pg_config)

    all_results = []
    for table in tables:
        result = validate_table(table, mysql_conn, pg_conn)
        status = "PASS" if all(c["match"] for c in result["checks"]) else "FAIL"
        print(f"[{status}] {table}")
        all_results.append(result)

    mysql_conn.close()
    pg_conn.close()
    return all_results

Zero-Downtime Migration Approach

Đối với ứng dụng production cần uptime cao, zero-downtime migration sử dụng kỹ thuật dual-write và progressive cutover.

Giai đoạn 1: Setup replication

Thiết lập continuous replication từ MySQL sang PostgreSQL. Có thể dùng các công cụ như Debezium, pgloader, hoặc custom sync scripts.

Giai đoạn 2: Dual-write

Ứng dụng ghi dữ liệu vào cả MySQL và PostgreSQL đồng thời:

class DualWriteRepository:
    def __init__(self, mysql_conn, pg_conn, primary="mysql"):
        self.mysql = mysql_conn
        self.pg = pg_conn
        self.primary = primary

    def create_order(self, order_data):
        """Ghi vào cả hai database."""
        # Ghi vào primary trước
        if self.primary == "mysql":
            result = self._write_mysql(order_data)
            try:
                self._write_pg(order_data)
            except Exception as e:
                # Log lỗi nhưng không fail — PostgreSQL chưa phải primary
                log_sync_error("create_order", order_data, e)
        else:
            result = self._write_pg(order_data)
            try:
                self._write_mysql(order_data)
            except Exception as e:
                log_sync_error("create_order", order_data, e)

        return result

Giai đoạn 3: Shadow reads

Đọc từ cả hai database, so sánh kết quả nhưng chỉ trả về kết quả từ primary:

async def read_with_shadow(query, mysql_conn, pg_conn):
    """Đọc từ cả hai DB, so sánh, trả về kết quả từ primary."""
    mysql_result = await mysql_conn.execute(query.mysql_version)
    pg_result = await pg_conn.execute(query.pg_version)

    if mysql_result != pg_result:
        log_discrepancy(query, mysql_result, pg_result)

    return mysql_result  # Vẫn trả về từ MySQL (primary)

Giai đoạn 4: Cutover

Chuyển primary từ MySQL sang PostgreSQL. Nếu có vấn đề, chuyển lại ngay.

Rollback Plan

Mọi migration đều cần rollback plan chi tiết. Đây là phần nhiều team bỏ qua nhưng lại quan trọng nhất.

Tôi đang chuẩn bị migration MySQL sang PostgreSQL.
Hãy giúp tôi xây dựng rollback plan chi tiết:

Thông tin migration:
- Chiến lược: [Big bang / Gradual]
- Số bảng: [Số lượng]
- Downtime window: [Thời gian]
- Điều kiện rollback: Khi nào cần rollback?

Rollback plan cần bao gồm:
1. Tiêu chí quyết định rollback (metrics nào vượt ngưỡng)
2. Các bước rollback cụ thể theo thứ tự
3. Ước tính thời gian rollback
4. Cách xử lý data đã ghi vào PostgreSQL trong thời gian chuyển đổi
5. Communication plan (thông báo cho team và stakeholders)
6. Post-rollback action items

Testing Checklist

Checklist đầy đủ cho migration database, đánh giá từng mục trước khi go-live:

• Schema validation: Tất cả bảng, cột, constraints, indexes đã được tạo đúng
• Data integrity: Row count khớp, checksums khớp, không mất dữ liệu
• Data types: Giá trị được chuyển đổi chính xác (đặc biệt dates, decimals, booleans)
• Application queries: Tất cả queries trong ứng dụng chạy đúng trên PostgreSQL
• Stored procedures: Functions đã chuyển đổi cho kết quả đúng
• Performance: Query performance không tệ hơn đáng kể so với MySQL
• Encoding: Unicode/UTF-8 hiển thị đúng, đặc biệt tiếng Việt có dấu
• Sequences: Auto-increment sequences bắt đầu từ giá trị đúng
• Foreign keys: Tất cả quan hệ tham chiếu hoạt động chính xác
• Backup: Có backup đầy đủ của MySQL trước khi bắt đầu
• Rollback tested: Đã thử rollback ít nhất một lần trong staging
• Monitoring: Dashboard theo dõi PostgreSQL đã sẵn sàng

Prompt tổng hợp cho toàn bộ quy trình

Tôi cần hỗ trợ migration MySQL sang PostgreSQL.
Hiện tại tôi đang ở giai đoạn: [Lập kế hoạch / Schema mapping /
Data migration / Validation / Cutover]

Vấn đề cụ thể cần giải quyết:
[Mô tả vấn đề]

Thông tin bổ sung:
[Schema, error messages, hoặc queries cụ thể]

Hãy giúp tôi giải quyết vấn đề này, kèm:
1. Giải thích nguyên nhân
2. Giải pháp cụ thể (có code/SQL)
3. Cách kiểm tra giải pháp đã hoạt động
4. Lưu ý cho các bước tiếp theo

Xử lý Triggers và Views

Ngoài stored procedures, triggers và views cũng cần được chuyển đổi cẩn thận.

Chuyển đổi Triggers

MySQL triggers và PostgreSQL triggers có syntax khác biệt đáng kể. PostgreSQL yêu cầu tách trigger function và trigger definition:

-- MySQL trigger
CREATE TRIGGER update_stock_after_order
AFTER INSERT ON order_items
FOR EACH ROW
BEGIN
    UPDATE products
    SET stock = stock - NEW.quantity
    WHERE id = NEW.product_id;
END;

-- PostgreSQL tương đương
-- Bước 1: Tạo trigger function
CREATE OR REPLACE FUNCTION update_stock_after_order()
RETURNS TRIGGER AS $$
BEGIN
    UPDATE products
    SET stock = stock - NEW.quantity
    WHERE id = NEW.product_id;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- Bước 2: Gắn trigger vào bảng
CREATE TRIGGER update_stock_after_order
AFTER INSERT ON order_items
FOR EACH ROW
EXECUTE FUNCTION update_stock_after_order();

Chuyển đổi Views

Views thường chuyển đổi dễ hơn vì SQL cơ bản tương đối giống nhau. Tuy nhiên cần chú ý các hàm đặc thù của MySQL:

Chuyển các views MySQL sau sang PostgreSQL.
Chú ý các hàm cần thay đổi:
- IFNULL() -> COALESCE()
- IF() -> CASE WHEN
- GROUP_CONCAT() -> STRING_AGG()
- DATE_FORMAT() -> TO_CHAR()
- NOW() giống nhau nhưng timezone behavior khác
- LIMIT trong subquery behavior khác

Views cần chuyển:
"""
[Dán CREATE VIEW statements]
"""

Với mỗi view, giải thích những thay đổi đã thực hiện.

Performance Tuning sau Migration

Sau khi migrate thành công, performance tuning là bước quan trọng tiếp theo. PostgreSQL có nhiều tính năng mà MySQL không có, và bạn nên tận dụng chúng.

Index optimization

PostgreSQL hỗ trợ nhiều loại index hơn MySQL. Claude có thể giúp bạn tối ưu:

Sau khi migrate từ MySQL sang PostgreSQL, tôi cần tối ưu indexes.
Dưới đây là các slow queries phổ biến nhất (từ pg_stat_statements):

Query 1: [Dán query + execution time]
Query 2: [Dán query + execution time]
Query 3: [Dán query + execution time]

Schema liên quan: [Dán schema các bảng liên quan]
Indexes hiện có: [Dán danh sách indexes]

Hãy đề xuất:
1. Indexes mới cần tạo (B-tree, GIN, GiST, hoặc BRIN)
2. Indexes hiện có có thể xóa (không được sử dụng)
3. Partial indexes cho các trường hợp cụ thể
4. EXPLAIN ANALYZE cho mỗi query trước và sau khi thêm index

PostgreSQL-specific optimizations

• JSONB indexes: Nếu có cột JSON, PostgreSQL JSONB với GIN index cho phép query trực tiếp vào JSON fields, nhanh hơn nhiều so với MySQL JSON
• Partial indexes: Tạo index chỉ cho subset dữ liệu thường query, ví dụ: CREATE INDEX idx_active_orders ON orders(created_at) WHERE status = 'active'
• BRIN indexes: Cho bảng lớn với dữ liệu có thứ tự tự nhiên (timestamps), BRIN index nhỏ hơn B-tree rất nhiều
• Table partitioning: PostgreSQL native partitioning hiệu quả hơn MySQL partitioning trong nhiều trường hợp

Connection pooling

PostgreSQL xử lý connections khác MySQL. Mỗi connection trong PostgreSQL tạo một process riêng (không phải thread), tốn nhiều memory hơn. Sử dụng connection pooler như PgBouncer là gần như bắt buộc trong production:

# pgbouncer.ini cấu hình cơ bản
[databases]
myapp = host=localhost port=5432 dbname=myapp

[pgbouncer]
listen_port = 6432
listen_addr = 0.0.0.0
auth_type = md5
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20
min_pool_size = 5

Các lỗi thường gặp và cách xử lý

Dưới đây là những lỗi phổ biến nhất khi migrate từ MySQL sang PostgreSQL và cách Claude giúp bạn xử lý:

• Column name trùng reserved keyword: PostgreSQL có nhiều reserved keywords hơn MySQL. Ví dụ: "user", "order", "group" cần được đặt trong dấu ngoặc kép hoặc đổi tên.
• Implicit type casting: MySQL tự động cast types trong nhiều trường hợp (ví dụ: so sánh string với number). PostgreSQL yêu cầu explicit casting, dẫn đến nhiều queries bị lỗi sau migration.
• GROUP BY behavior: MySQL cho phép SELECT cột không có trong GROUP BY (khi ONLY_FULL_GROUP_BY tắt). PostgreSQL luôn yêu cầu tất cả cột non-aggregate phải có trong GROUP BY.
• LIMIT/OFFSET syntax: Cú pháp giống nhau nhưng PostgreSQL không hỗ trợ LIMIT trong UPDATE/DELETE (cần dùng subquery với CTID).
• Timezone handling: MySQL TIMESTAMP tự động chuyển timezone, PostgreSQL TIMESTAMP WITHOUT TIME ZONE không làm điều này. Cần quyết định dùng WITH hoặc WITHOUT TIME ZONE.

Bước tiếp theo

Database migration là dự án phức tạp nhưng hoàn toàn khả thi khi có kế hoạch chi tiết và công cụ hỗ trợ phù hợp. Claude giúp bạn tăng tốc đáng kể ở các bước lặp lại — sinh migration scripts, mapping schema, viết validation queries — để bạn tập trung vào các quyết định kiến trúc quan trọng. Khám phá thêm các hướng dẫn về data engineering tại Thư viện Ứng dụng.