MySQL / MariaDB

MySQL và MariaDB khác nhau thế nào?

MariaDB là bản fork của MySQL (2009, sau khi Oracle mua Sun/MySQL), do chính các thành viên sáng lập MySQL cũ tạo ra. Về cơ bản MariaDB vẫn tương thích giao thức và cú pháp SQL với MySQL, nhưng có driver, storage engine và tính năng phát triển độc lập theo thời gian:

Kiến trúc tổng thể

Server chia làm 2 lớp chính:

• SQL Layer (Server layer): Parser, Optimizer, Cache, xử lý view/trigger/stored procedure — giống nhau giữa các storage engine.
• Storage Engine Layer (pluggable): Chịu trách nhiệm đọc/ghi dữ liệu vật lý, transaction, locking, index.

Các storage engine quan trọng

Các tiến trình/thành phần chạy nền InnoDB cần nhớ

• Buffer Pool: cache dữ liệu + index trong RAM, quyết định lớn tới hiệu năng (innodb_buffer_pool_size).
• Redo log (ib_logfile): đảm bảo durability, ghi trước khi commit (WAL - Write Ahead Log).
• Undo log: phục vụ MVCC và rollback.
• Doublewrite buffer: chống lỗi partial page write khi crash.
• Binary log (binlog): log ở tầng server, dùng cho replication và point-in-time recovery — không phải riêng của InnoDB.

Cài đặt MariaDB trên RHEL/Rocky/AlmaLinux (dnf/yum)

Nên dùng repo chính thức của MariaDB thay vì repo mặc định của distro để chủ động chọn version:

# Thêm repo chính thức MariaDB (ví dụ 10.11 LTS)
curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10.11"

# Cài server + client
sudo dnf install -y MariaDB-server MariaDB-client

# Khởi động và enable service
sudo systemctl enable --now mariadb

# Cấu hình bảo mật ban đầu (đặt root pass, xóa test db, disable remote root...)
sudo mysql_secure_installation
Copy

Cài đặt trên Ubuntu/Debian (apt)

sudo apt update
sudo apt install -y mariadb-server mariadb-client

sudo systemctl enable --now mariadb
sudo mysql_secure_installation

# Kiểm tra version và trạng thái
mysql --version
sudo systemctl status mariadb
Copy

Cài đặt offline (không có Internet) — dùng RPM local

Thường gặp trong datacenter kín mạng (giống mô hình anh làm với NGINX Plus HA offline). Quy trình chuẩn:

1. Trên máy có Internet: dnf download --resolve --alldeps MariaDB-server MariaDB-client để tải toàn bộ gói + dependency.
2. Copy thư mục RPM sang máy đích qua SCP/USB/SMB.
3. Tạo repo local bằng createrepo_c hoặc cài trực tiếp bằng dnf install ./*.rpm (dnf tự resolve dependency nội bộ thư mục nếu đủ gói).
4. Kiểm tra rpm -qa | grep -i maria để xác nhận đã cài đủ.

Cài đặt bằng Docker (môi trường test/dev)

docker run -d --name mariadb-test \
  -e MARIADB_ROOT_PASSWORD=StrongPass123! \
  -e MARIADB_DATABASE=appdb \
  -p 3306:3306 \
  -v mariadb_data:/var/lib/mysql \
  mariadb:10.11

# Kết nối thử
docker exec -it mariadb-test mariadb -uroot -p
Copy

Kiểm tra sau cài đặt

mysql -u root -p -e "SELECT VERSION();"
mysql -u root -p -e "SHOW ENGINES\G"
mysql -u root -p -e "SHOW VARIABLES LIKE 'datadir';"
sudo ss -lntp | grep 3306
Copy

Quản lý user và phân quyền

-- Tạo user chỉ cho phép kết nối từ 1 host cụ thể (best practice)
CREATE USER 'app_user'@'10.0.1.%' IDENTIFIED BY 'StrongPass!23';

-- Cấp quyền theo nguyên tắc least-privilege
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'app_user'@'10.0.1.%';

-- Quyền replication cho user dùng để dựng slave
CREATE USER 'repl'@'10.0.2.%' IDENTIFIED BY 'ReplPass!23';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.2.%';

-- Áp dụng thay đổi
FLUSH PRIVILEGES;

-- Xem quyền hiện có của 1 user
SHOW GRANTS FOR 'app_user'@'10.0.1.%';

-- Thu hồi quyền
REVOKE DELETE ON appdb.* FROM 'app_user'@'10.0.1.%';
Copy

Roles (MariaDB 10.0.5+ / MySQL 8.0+)

CREATE ROLE 'readonly_role';
GRANT SELECT ON appdb.* TO 'readonly_role';

CREATE USER 'reporting'@'10.0.3.%' IDENTIFIED BY 'Pass!23';
GRANT 'readonly_role' TO 'reporting'@'10.0.3.%';
SET DEFAULT ROLE 'readonly_role' FOR 'reporting'@'10.0.3.%';
Copy

Roles giúp quản lý quyền theo nhóm chức năng thay vì gán trực tiếp từng user — khi thay đổi chính sách chỉ cần sửa role, không phải sửa từng tài khoản.

Quản lý database/schema

CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
SHOW DATABASES;
USE appdb;
SHOW TABLES;
SHOW TABLE STATUS\G
SHOW CREATE TABLE orders\G
Copy

Xử lý user hết hạn / khóa tài khoản

-- Khóa / mở khóa tài khoản
ALTER USER 'app_user'@'10.0.1.%' ACCOUNT LOCK;
ALTER USER 'app_user'@'10.0.1.%' ACCOUNT UNLOCK;

-- Đặt chính sách hết hạn mật khẩu
ALTER USER 'app_user'@'10.0.1.%' PASSWORD EXPIRE INTERVAL 90 DAY;

-- Đổi mật khẩu ngay
ALTER USER 'app_user'@'10.0.1.%' IDENTIFIED BY 'NewPass!23';
Copy

Các lệnh quản trị thường dùng hàng ngày

-- Xem process/connection đang chạy
SHOW FULL PROCESSLIST;

-- Kill 1 session/query bị treo
KILL 12345;

-- Xem trạng thái server tổng quan
SHOW STATUS LIKE 'Threads%';
SHOW STATUS LIKE 'Innodb_buffer_pool%';

-- Xem biến cấu hình đang áp dụng
SHOW VARIABLES LIKE '%timeout%';
Copy

So sánh các phương pháp backup

mysqldump — backup logic

# Backup 1 database, dùng --single-transaction để không khóa bảng InnoDB
mysqldump -u root -p --single-transaction --routines --triggers --events \
  --master-data=2 appdb > appdb_$(date +%F).sql

# Backup toàn bộ instance (tất cả database)
mysqldump -u root -p --single-transaction --all-databases --routines --triggers \
  > full_backup_$(date +%F).sql

# Restore
mysql -u root -p appdb < appdb_2026-07-07.sql
Copy

mariabackup — backup vật lý (hot backup, không khóa)

# Full backup
mariabackup --backup --target-dir=/backup/full \
  --user=root --password=xxxx

# Chuẩn bị (prepare) trước khi restore — apply log để đưa về trạng thái consistent
mariabackup --prepare --target-dir=/backup/full

# Restore: dừng service, xóa datadir cũ, copy-back
sudo systemctl stop mariadb
sudo mv /var/lib/mysql /var/lib/mysql_old
mariabackup --copy-back --target-dir=/backup/full
sudo chown -R mysql:mysql /var/lib/mysql
sudo systemctl start mariadb

# Incremental backup (dựa trên full backup trước đó)
mariabackup --backup --target-dir=/backup/inc1 \
  --incremental-basedir=/backup/full \
  --user=root --password=xxxx
Copy

Point-in-time Recovery (PITR) bằng binlog

Kịch bản: full backup lúc 00:00, sự cố xóa nhầm dữ liệu lúc 09:15, cần khôi phục tới ngay trước 09:15.

# 1. Restore full backup (từ mariabackup hoặc mysqldump) trước

# 2. Xác định binlog position/thời điểm cần dừng lại
mysqlbinlog --start-datetime="2026-07-07 00:00:00" \
            --stop-datetime="2026-07-07 09:14:59" \
            /var/log/mysql/mysql-bin.000123 | mysql -u root -p

# Hoặc theo GTID range nếu dùng GTID replication
mysqlbinlog --include-gtids="0-1-100:1-500" mysql-bin.000123 | mysql -u root -p
Copy

Kiểm tra tính toàn vẹn bản backup

• Luôn restore thử trên môi trường riêng (staging) định kỳ — backup chưa từng restore thử = backup chưa được kiểm chứng.
• Với mariabackup, kiểm tra log xtrabackup_checkpoints để xác nhận LSN (Log Sequence Number) hợp lệ.
• Giám sát dung lượng và thời gian chạy backup theo thời gian để phát hiện bất thường sớm.

Vị trí file cấu hình

/etc/my.cnf
/etc/my.cnf.d/*.cnf         # RHEL/Rocky
/etc/mysql/my.cnf
/etc/mysql/mariadb.conf.d/*.cnf   # Ubuntu/Debian

# Xem thứ tự file được load
mysql --help --verbose | grep -A1 "Default options"
Copy

Các tham số InnoDB quan trọng nhất

Tham số Connection & Timeout

[mysqld]
max_connections = 500
max_connect_errors = 1000000
wait_timeout = 600
interactive_timeout = 600
connect_timeout = 10

# Thread pool (giảm overhead khi nhiều connection đồng thời - MariaDB)
thread_handling = pool-of-threads
thread_pool_size = 8   # thường = số CPU core
Copy

Ví dụ my.cnf cho server production tầm trung (32GB RAM, SSD)

[mysqld]
innodb_buffer_pool_size = 20G
innodb_buffer_pool_instances = 10
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 1
innodb_flush_method = O_DIRECT
innodb_file_per_table = 1
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000

max_connections = 500
table_open_cache = 4000
tmp_table_size = 256M
max_heap_table_size = 256M

# Binlog (bắt buộc nếu dùng replication)
log_bin = mysql-bin
binlog_format = ROW
server_id = 101
expire_logs_days = 7

# Slow query log — luôn bật để phục vụ tuning
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
Copy

Áp dụng thay đổi runtime (không cần restart)

-- Với biến dynamic, có thể set ngay không cần restart
SET GLOBAL innodb_io_capacity = 2000;
SET GLOBAL max_connections = 500;

-- Kiểm tra biến nào là dynamic
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; -- KHÔNG dynamic, cần restart để đổi (trừ khi dùng online resize từ 5.7+/10.2+)
Copy

Nguyên lý hoạt động

Master ghi mọi thay đổi vào binlog. Slave có 2 thread chính:

• IO Thread: kết nối tới master, đọc binlog và ghi vào relay log cục bộ.
• SQL Thread: đọc relay log và apply lại các thay đổi vào dữ liệu local.

Bước 1 — Cấu hình Master

/etc/my.cnf.d/server.cnf trên MASTER
[mysqld]
server_id = 101
log_bin = mysql-bin
binlog_format = ROW
binlog_do_db = appdb          # tùy chọn, giới hạn DB replicate
expire_logs_days = 7
sync_binlog = 1
Copy

sudo systemctl restart mariadb

-- Tạo user replication
CREATE USER 'repl'@'10.0.2.%' IDENTIFIED BY 'ReplPass!23';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.2.%';
FLUSH PRIVILEGES;
Copy

Bước 2 — Lấy snapshot dữ liệu ban đầu từ Master

-- Khóa toàn bộ để lấy vị trí binlog nhất quán (nếu dùng mysqldump)
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;   -- Ghi lại File và Position hiển thị ra

-- Ở terminal khác, dump dữ liệu (giữ lock)
mysqldump -u root -p --all-databases --routines --triggers > full_dump.sql

-- Sau khi dump xong, mở khóa
UNLOCK TABLES;
Copy

Bước 3 — Cấu hình & khởi tạo Slave

/etc/my.cnf.d/server.cnf trên SLAVE
[mysqld]
server_id = 102
relay_log = relay-bin
read_only = 1
log_bin = mysql-bin      # bật nếu slave này có thể làm master của slave khác (chained replication)
Copy

sudo systemctl restart mariadb

-- Import dữ liệu đã dump từ master
mysql -u root -p < full_dump.sql

-- Trỏ slave về master, dùng File/Position ghi lại ở Bước 2
CHANGE MASTER TO
  MASTER_HOST='10.0.1.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='ReplPass!23',
  MASTER_LOG_FILE='mysql-bin.000005',
  MASTER_LOG_POS=15420;

START SLAVE;
Copy

Bước 4 — Xác minh replication hoạt động

SHOW SLAVE STATUS\G
Copy

Các trường quan trọng cần kiểm tra:

Xử lý lỗi replication dừng giữa chừng

-- Xem chi tiết lỗi
SHOW SLAVE STATUS\G   -- xem Last_SQL_Errno, Last_SQL_Error

-- Cách 1 (rủi ro): bỏ qua 1 lỗi cụ thể rồi tiếp tục — CHỈ dùng khi đã hiểu rõ hậu quả
STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;

-- Cách 2 (an toàn hơn): rebuild lại slave từ backup mới của master
STOP SLAVE;
RESET SLAVE ALL;
-- Restore lại full backup mới + CHANGE MASTER TO như bước 3
Copy

GTID (Global Transaction ID) là gì?

Thay vì phải nhớ chính xác File/Position như replication truyền thống, mỗi transaction được gán một định danh duy nhất toàn cục (GTID). Khi failover hoặc dựng slave mới, không cần tính toán position thủ công — server tự đồng bộ dựa trên GTID đã apply.

Cấu hình GTID trên MariaDB

Trên Master (my.cnf)
[mysqld]
server_id = 101
log_bin = mysql-bin
binlog_format = ROW
gtid_domain_id = 1
Copy

Trên Slave — trỏ về master bằng GTID, không cần File/Position
CHANGE MASTER TO
  MASTER_HOST='10.0.1.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='ReplPass!23',
  MASTER_USE_GTID=slave_pos;

START SLAVE;
SHOW SLAVE STATUS\G   -- kiểm tra Using_Gtid: Slave_Pos, Gtid_IO_Pos
Copy

Failover với GTID — promote slave thành master mới

Trên slave được chọn làm master mới:
STOP SLAVE;
RESET SLAVE ALL;
SET GLOBAL read_only = 0;

Các slave còn lại trỏ về master mới, vẫn dùng GTID — MariaDB tự tính điểm tiếp tục chính xác
CHANGE MASTER TO MASTER_HOST='10.0.1.11', MASTER_USE_GTID=slave_pos;
START SLAVE;
Copy

Semi-synchronous Replication

Replication mặc định là asynchronous: master commit xong không chờ slave xác nhận đã nhận — nếu master chết ngay sau đó, dữ liệu vừa commit có thể chưa kịp tới bất kỳ slave nào (mất dữ liệu khi failover).

Semi-sync yêu cầu master chờ ít nhất 1 slave xác nhận đã nhận (ACK) binlog trước khi trả kết quả commit về client — giảm nguy cơ mất dữ liệu, đổi lại tăng độ trễ (latency) mỗi lần commit.

Cài plugin (Master)
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
SET GLOBAL rpl_semi_sync_master_enabled = 1;
SET GLOBAL rpl_semi_sync_master_timeout = 1000; # ms, timeout rơi về async nếu không ACK kịp

Cài plugin (Slave)
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_slave_enabled = 1;

-- Restart slave thread để plugin có hiệu lực
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;

-- Kiểm tra trạng thái trên master
SHOW STATUS LIKE 'Rpl_semi_sync_master_status';
SHOW STATUS LIKE 'Rpl_semi_sync_master_clients';
Copy

Multi-source Replication

Một slave nhận dữ liệu từ nhiều master khác nhau cùng lúc (thường dùng để hợp nhất dữ liệu từ nhiều nguồn vào 1 kho tổng hợp/reporting).

MariaDB dùng khái niệm "connection name" để phân biệt các nguồn
CHANGE MASTER 'source1' TO
  MASTER_HOST='10.0.1.10', MASTER_USER='repl', MASTER_PASSWORD='xxx',
  MASTER_USE_GTID=slave_pos;

CHANGE MASTER 'source2' TO
  MASTER_HOST='10.0.1.20', MASTER_USER='repl', MASTER_PASSWORD='xxx',
  MASTER_USE_GTID=slave_pos;

START SLAVE 'source1';
START SLAVE 'source2';

SHOW ALL SLAVES STATUS\G
Copy

Khác biệt cốt lõi so với Master-Slave

Cài đặt cụm Galera 3 node (MariaDB)

# Cài gói trên cả 3 node
sudo dnf install -y MariaDB-server MariaDB-client galera-4

# Mở firewall các port cần thiết trên cả 3 node
sudo firewall-cmd --permanent --add-port={3306,4444,4567,4568}/tcp
sudo firewall-cmd --permanent --add-port=4567/udp
sudo firewall-cmd --reload
Copy

/etc/my.cnf.d/galera.cnf — GIỐNG NHAU trên cả 3 node, trừ wsrep_node_address/name
[galera]
wsrep_on = ON
wsrep_provider = /usr/lib64/galera-4/libgalera_smm.so
wsrep_cluster_name = "prod_cluster"
wsrep_cluster_address = "gcomm://10.0.1.11,10.0.1.12,10.0.1.13"
wsrep_node_address = "10.0.1.11"     # đổi theo từng node
wsrep_node_name = "galera-node1"     # đổi theo từng node
wsrep_sst_method = mariabackup
wsrep_sst_auth = "sst_user:SstPass!23"

binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
Copy

# Bootstrap CHỈ node đầu tiên (khởi tạo cluster mới, chỉ chạy 1 lần duy nhất)
sudo galera_new_cluster
# hoặc: sudo mariadb -e "SET GLOBAL wsrep_provider_options='pc.bootstrap=true';"

# Các node 2, 3: khởi động bình thường, tự join cluster
sudo systemctl start mariadb

# Kiểm tra trạng thái cluster trên bất kỳ node nào
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_status';"  # cần = Primary
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_local_state_comment';" # cần = Synced
Copy

SST vs IST — cách node mới đồng bộ dữ liệu khi join

• SST (State Snapshot Transfer): đồng bộ toàn bộ dữ liệu từ đầu — dùng khi node mới hoàn toàn hoặc dữ liệu quá cũ so với cluster. Tốn thời gian, tải I/O cao lên node donor.
• IST (Incremental State Transfer): chỉ đồng bộ phần chênh lệch (dựa trên write-set còn lưu trong gcache của donor) — nhanh hơn nhiều, dùng khi node chỉ rời cluster tạm thời (ví dụ restart ngắn).

Xử lý sự cố phổ biến: Cluster không đạt Primary (split-brain)

-- Khi mất quá nhiều node, cluster có thể rơi vào trạng thái "non-Primary"
SHOW STATUS LIKE 'wsrep_cluster_status';  -- trả về "non-Primary"

-- Nếu chắc chắn đây là node còn "sống" duy nhất và cần khôi phục thủ công (RỦI RO):
SET GLOBAL wsrep_provider_options='pc.bootstrap=true';
Copy

Vai trò của MaxScale trong kiến trúc HA

MaxScale đứng giữa application và cụm database (Master-Slave hoặc Galera), đảm nhận:

• Routing thông minh: tự động phân biệt SELECT (đi slave) và INSERT/UPDATE/DELETE (đi master) — gọi là readwritesplit.
• Health check / Monitor: liên tục kiểm tra trạng thái từng node, tự động loại node lỗi khỏi routing.
• Failover tự động: khi master chết, tự động promote 1 slave lên làm master mới (với module mariadbmon) mà application không cần biết.
• Connection pooling & throttling: giảm tải connection overhead lên backend thực.

Cài đặt MaxScale

curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-maxscale
sudo dnf install -y maxscale

# Tạo user chuyên dụng cho MaxScale trên các node DB (quyền monitor + đọc metadata)
-- Chạy trên MASTER:
CREATE USER 'maxscale_monitor'@'10.0.5.%' IDENTIFIED BY 'MaxPass!23';
GRANT REPLICATION CLIENT, REPLICATION SLAVE, SUPER, RELOAD, PROCESS, SHOW DATABASES ON *.* TO 'maxscale_monitor'@'10.0.5.%';

CREATE USER 'maxscale_router'@'10.0.5.%' IDENTIFIED BY 'RoutPass!23';
GRANT SELECT ON mysql.* TO 'maxscale_router'@'10.0.5.%';
Copy

Cấu hình cơ bản /etc/maxscale.cnf

[maxscale]
threads = auto

[server1]
type = server
address = 10.0.1.10
port = 3306
protocol = MariaDBBackend

[server2]
type = server
address = 10.0.1.11
port = 3306
protocol = MariaDBBackend

[server3]
type = server
address = 10.0.1.12
port = 3306
protocol = MariaDBBackend

# Monitor — theo dõi topology Master-Slave và tự động failover
[MariaDB-Monitor]
type = monitor
module = mariadbmon
servers = server1,server2,server3
user = maxscale_monitor
password = MaxPass!23
monitor_interval = 2000ms
auto_failover = true
auto_rejoin = true
failcount = 3

# Service — định nghĩa routing logic
[RW-Split-Service]
type = service
router = readwritesplit
servers = server1,server2,server3
user = maxscale_router
password = RoutPass!23
max_slave_connections = 100%

# Listener — cổng application kết nối vào
[RW-Split-Listener]
type = listener
service = RW-Split-Service
protocol = MariaDBClient
port = 4006
Copy

sudo systemctl enable --now maxscale

# CLI quản trị MaxScale
sudo maxctrl list servers
sudo maxctrl list services
sudo maxctrl list monitors
sudo maxctrl show server server1
Copy

So sánh nhanh MaxScale vs ProxySQL

Xử lý sự cố thường gặp với MaxScale

# Server bị đánh dấu Down dù DB vẫn chạy — thường do sai user/pass hoặc firewall
sudo maxctrl show server server1
# Xem log chi tiết lý do health-check fail
sudo tail -f /var/log/maxscale/maxscale.log

# Failover không tự động xảy ra dù master chết
# Kiểm tra: auto_failover=true đã bật? failcount đã đạt ngưỡng chưa?
sudo maxctrl list monitors --details

# Buộc failover thủ công (khẩn cấp)
sudo maxctrl call command mariadbmon failover MariaDB-Monitor
Copy

Vì sao cần Keepalived phía trước MaxScale?

MaxScale bản thân cũng là 1 điểm chịu lỗi đơn (single point of failure) nếu chỉ chạy 1 instance. Giải pháp phổ biến: chạy 2+ instance MaxScale (active-passive), đặt Keepalived phía trước để quản lý 1 VIP (Virtual IP) chung — application chỉ cần biết đúng 1 địa chỉ VIP duy nhất.

sudo dnf install -y keepalived
sudo systemctl enable keepalived
Copy

vrrp_script chk_maxscale {
    script "/usr/bin/systemctl is-active maxscale"
    interval 2
    weight -20      # giảm priority 20 điểm nếu MaxScale service down
    fall 2
    rise 2
}

vrrp_instance VI_MAXSCALE {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass Secret123
    }

    virtual_ipaddress {
        10.0.5.100/24
    }

    track_script {
        chk_maxscale
    }
}
Copy

vrrp_script chk_maxscale {
    script "/usr/bin/systemctl is-active maxscale"
    interval 2
    weight -20
    fall 2
    rise 2
}

vrrp_instance VI_MAXSCALE {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100          # THẤP hơn node MASTER
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass Secret123
    }

    virtual_ipaddress {
        10.0.5.100/24
    }

    track_script {
        chk_maxscale
    }
}
Copy

sudo systemctl restart keepalived

# Trên node đang giữ VIP, kiểm tra bằng ip addr
ip addr show eth0 | grep 10.0.5.100

# Xem log VRRP
sudo journalctl -u keepalived -f

# Test failover: dừng maxscale trên node MASTER, quan sát VIP chuyển sang BACKUP
sudo systemctl stop maxscale
# Trong vài giây, VIP phải xuất hiện trên node BACKUP
Copy

Các nguồn dữ liệu giám sát chính

Phân tích slow query log với mysqldumpslow / pt-query-digest

# Công cụ built-in đơn giản
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

# Công cụ mạnh hơn (Percona Toolkit) — phân tích chi tiết, gom nhóm theo pattern
pt-query-digest /var/log/mysql/slow.log > slow_report.txt
Copy

Phát hiện query thiếu index / full table scan

EXPLAIN SELECT * FROM orders WHERE customer_id = 12345;
-- Chú ý cột "type": ALL = full table scan (xấu), ref/range/const = có dùng index (tốt)
-- Chú ý cột "rows": ước lượng số dòng phải quét — càng lớn càng đáng lo

-- Từ MySQL 8.0.18+ / MariaDB 10.5+: EXPLAIN ANALYZE cho số liệu thực tế thay vì ước lượng
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 12345;
Copy

Chẩn đoán Lock & Deadlock

-- Xem transaction đang mở và lock đang chờ (InnoDB)
SELECT * FROM information_schema.INNODB_TRX\G
SELECT * FROM information_schema.INNODB_LOCK_WAITS\G

-- Xem chi tiết deadlock gần nhất (rất hữu ích khi debug)
SHOW ENGINE INNODB STATUS\G
-- Tìm section "LATEST DETECTED DEADLOCK"
Copy

Bảng lỗi thường gặp trong production

Checklist khi nhận cảnh báo "DB chậm" (triage nhanh)

1. SHOW FULL PROCESSLIST — có query nào chạy quá lâu hoặc bị Lock không?
2. SHOW ENGINE INNODB STATUS\G — kiểm tra section TRANSACTIONS, xem có deadlock gần đây không.
3. Kiểm tra tài nguyên hệ thống: iostat -x 2, vmstat 2, top — CPU/I/O/RAM có đang bão hòa không.
4. Kiểm tra SHOW STATUS LIKE 'Innodb_buffer_pool_reads' tăng nhanh bất thường → buffer pool miss nhiều, có thể do query mới thiếu index hoặc buffer pool quá nhỏ.
5. Nếu là slave: SHOW SLAVE STATUS\G — kiểm tra Seconds_Behind_Master.
6. Đối chiếu với thời điểm deploy gần nhất — nhiều sự cố "DB chậm" thực chất bắt nguồn từ query mới hoặc migration schema thiếu index.

Bật SSL/TLS cho kết nối client-server

# Tạo certificate (tự ký, hoặc dùng CA nội bộ cho production thực)
sudo mysql_ssl_rsa_setup --datadir=/var/lib/mysql

# my.cnf
[mysqld]
ssl_cert = /var/lib/mysql/server-cert.pem
ssl_key  = /var/lib/mysql/server-key.pem
ssl_ca   = /var/lib/mysql/ca.pem
require_secure_transport = ON   # bắt buộc mọi kết nối phải dùng SSL
Copy

-- Bắt buộc SSL riêng cho 1 user cụ thể (thay vì toàn server)
ALTER USER 'app_user'@'10.0.1.%' REQUIRE SSL;

-- Kiểm tra kết nối hiện tại có dùng SSL không
SHOW STATUS LIKE 'Ssl_cipher';
Copy

Firewall — chỉ mở đúng port cần thiết

# Chỉ cho phép subnet application server kết nối tới 3306, chặn toàn bộ nguồn khác
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="10.0.1.0/24" port protocol="tcp" port="3306" accept'
sudo firewall-cmd --permanent --zone=public --remove-port=3306/tcp  # đảm bảo không có rule mở toàn bộ
sudo firewall-cmd --reload
Copy

Nguyên tắc phân quyền (least-privilege) đã học ở Bài 03, áp dụng lại có hệ thống

• Không bao giờ dùng tài khoản root cho application — luôn tạo user riêng với quyền tối thiểu cần thiết.
• Tách biệt user theo chức năng: user cho application (CRUD), user cho backup (SELECT + LOCK TABLES/RELOAD), user cho monitor (PROCESS, REPLICATION CLIENT), user cho replication (REPLICATION SLAVE only).
• Định kỳ audit SELECT user, host FROM mysql.user; để phát hiện tài khoản thừa, tài khoản wildcard host không cần thiết.
• Vô hiệu hóa hoặc xóa các plugin/tính năng không dùng (ví dụ FEDERATED engine nếu không cần).

Audit log (theo dõi ai làm gì)

# MariaDB Audit Plugin (thường có sẵn từ 10.0+)
INSTALL PLUGIN server_audit SONAME 'server_audit';

SET GLOBAL server_audit_logging = ON;
SET GLOBAL server_audit_events = 'CONNECT,QUERY_DDL,QUERY_DML,QUERY_DCL';
SET GLOBAL server_audit_file_path = '/var/log/mysql/audit.log';
Copy

Checklist hardening trước khi go-live production