Reference // Tra cứu kỹ thuậtdatabase

Database

DOC PATH reference/database/operations

📘 Mục đích: Tra cứu nhanh các lệnh và tác vụ vận hành MongoDB, MySQL. Thay các giá trị dạng <HOST>, <PORT>, <DATABASE>, <USER>, <BACKUP_PATH> trước khi chạy lệnh.

⚠ Các thao tác restore, DROP, --drop, PURGE BINARY LOGS, thay đổi user/quyền hoặc dừng query có thể làm mất dữ liệu hay gián đoạn dịch vụ. Xác nhận đúng môi trường, chuẩn bị backup đã kiểm tra và thử trên staging trước.

1. Tra cứu nhanh

Hệ quản trị	Kết nối CLI	Kiểm tra dịch vụ	Backup cơ bản
MongoDB	`mongosh "mongodb://<HOST>:<PORT>"`	`systemctl status mongod`	`mongodump --uri "<URI>" --out <BACKUP_PATH>`
MySQL	`mysql -u <USER> -p -h <HOST>`	`systemctl status mysql`	`mysqldump -u <USER> -p <DATABASE> > <BACKUP_FILE>.sql`

🔐 Không ghi password trực tiếp vào connection string, lệnh lưu trong shell history hoặc tài liệu này. Dùng prompt nhập password, file cấu hình có permission phù hợp hoặc secret manager mà công cụ hỗ trợ.

Đối chiếu thuật ngữ

Bảng dưới giúp đối chiếu khái niệm, không có nghĩa SQL và MongoDB hoạt động giống nhau. Cần chọn data model theo cách ứng dụng đọc, ghi và liên kết dữ liệu.

SQL		MongoDB
Table	→	Collection
Row / Record	→	Document
Column	→	Field
Primary key	→	`_id`, thường dùng kiểu `ObjectId`
JOIN	→	`$lookup` hoặc thiết kế embedded document, tùy data model
Schema khai báo theo table	→	Schema linh hoạt, có thể áp dụng validation

Tham khảo vai trò của _id và cách tạo ObjectId trong MongoDB BSON Types.

Ví dụ: cùng dữ liệu, hai cách lưu

SQL (nhiều bảng)

-- Bảng users
id | name | city
1 | An | HCM

-- Bảng orders
id | user_id | item
1 | 1 | Laptop

MongoDB (1 document)

{
  "name": "An",
  "city": "HCM",
  "orders": [
    { "item": "Laptop" }
  ]
}

Khi nào dùng MongoDB?

Phù hợp	Cân nhắc kỹ
Cấu trúc document thay đổi theo loại dữ liệu	Transaction trải rộng trên nhiều document hoặc shard
Lưu log, sự kiện, session	Dữ liệu có nhiều quan hệ và ràng buộc tham chiếu
Workload phù hợp để mở rộng bằng sharding	Báo cáo cần nhiều JOIN và truy vấn tổng hợp phức tạp
Dữ liệu dạng document từ API	Đội vận hành chưa quen data model và công cụ MongoDB

MongoDB hỗ trợ transaction trên nhiều document. Với hệ thống tài chính hoặc kế toán, cần đánh giá data model, tính nhất quán, kiểu dữ liệu số và yêu cầu báo cáo; không nên chọn database chỉ theo tên lĩnh vực. Xem MongoDB Transactions.

Bảng quyền dưới đây chỉ đối chiếu theo mục đích sử dụng. MongoDB role và MySQL privilege có phạm vi, tập quyền khác nhau; kiểm tra quyền cụ thể trước khi cấp cho user.

MongoDB role	MySQL privilege gần tương ứng	Mô tả
`read`	`SELECT`	Chỉ đọc dữ liệu
`readWrite`	`SELECT, INSERT, UPDATE, DELETE`	Đọc và ghi dữ liệu
`dbAdmin`	`ALTER, CREATE, DROP, INDEX`	Quản trị cấu trúc database
`userAdmin`	`CREATE USER, ALTER USER, DROP USER, GRANT OPTION`	Quản lý user và phân quyền
`root`	`ALL PRIVILEGES ON . WITH GRANT OPTION`	Toàn quyền trên server

2. MongoDB (port 27017)

Thông tin nền tảng & service

Hạng mục	Giá trị thường gặp
Service	`mongod`
Config	`/etc/mongod.conf`
Data	`/var/lib/mongodb/`
Log	`/var/log/mongodb/mongod.log` hoặc `journalctl -u mongod`

systemctl status mongod
systemctl is-enabled mongod
mongod --version
mongosh --version
journalctl -u mongod -n 100 --no-pager

Kết nối & kiểm tra nhanh

🔐 Không ghi password trực tiếp trong connection string hoặc lệnh lưu vào shell history. Dùng -p để nhập tương tác hoặc cơ chế secret được công cụ hỗ trợ.

# Local mặc định
mongosh

# Remote; hệ thống sẽ hỏi password
mongosh --host <HOST> --port <PORT> -u <USER> -p --authenticationDatabase <AUTH_DB>

// Chạy trong mongosh
db.adminCommand({ ping: 1 })
db.getName()
show dbs
db.stats()
db.getCollectionNames()
db.getCollection("<COLLECTION>").countDocuments({})

Vận hành database, collection & user

// Database và collection
use <DATABASE>
show collections
db.createCollection("<COLLECTION>")
db.getCollection("<COLLECTION>").stats()

// User: cấp quyền tối thiểu theo database cần dùng
use <DATABASE>
db.createUser({
  user: "<USER>",
  pwd: passwordPrompt(),
  roles: [{ role: "readWrite", db: "<DATABASE>" }]
})
db.grantRolesToUser("<USER>", [{ role: "dbAdmin", db: "<DATABASE>" }])
db.changeUserPassword("<USER>", passwordPrompt())

⚠ db.<collection>.drop(), db.dropDatabase(), db.dropUser() và thay đổi quyền có thể không khôi phục được ngay. Kiểm tra đúng database/collection, backup và quy trình phê duyệt trước khi chạy.

Monitoring & replica set

// Trạng thái server và truy vấn đang chạy
db.serverStatus()
db.currentOp({ active: true })

// Chỉ dùng khi đã xác định đúng operation cần dừng
// db.killOp(<OPERATION_ID>)

// Replica set
rs.status()
rs.conf()
rs.printSecondaryReplicationInfo()
db.hello()

💡 Khi kiểm tra replica set, tập trung vào vai trò PRIMARY/SECONDARY, replication lag, trạng thái health và dung lượng disk. Chỉ thử failover trên production theo kế hoạch đã được duyệt.

Backup

📘 Có thể backup từ secondary để giảm tải primary sau khi kiểm tra replication lag và read preference. Với replica set, --oplog lưu các thay đổi phát sinh trong lúc dump; khi restore phải replay oplog để tạo dữ liệu nhất quán tại thời điểm kết thúc dump. Ví dụ một database bên dưới không có --oplog, nên không đảm bảo một trạng thái nhất quán tại cùng thời điểm nếu vẫn có ghi dữ liệu.

# Toàn bộ instance, nén thành một archive
mongodump \
  --uri "mongodb://<USER>@<HOST>:<PORT>/?authSource=<AUTH_DB>" \
  --archive="<BACKUP_PATH>/mongo-$(date +%F-%H%M).archive.gz" \
  --gzip \
  --oplog

# Một database
mongodump \
  --uri "mongodb://<USER>@<HOST>:<PORT>/?authSource=<AUTH_DB>" \
  --db "<DATABASE>" \
  --archive="<BACKUP_PATH>/<DATABASE>-$(date +%F-%H%M).archive.gz" \
  --gzip

Kiểm tra tối thiểu: exit code, dung lượng file và checksum. Lưu thêm thời điểm backup, phiên bản MongoDB, host và database nguồn để đối chiếu khi restore.

sha256sum <BACKUP_FILE> > <BACKUP_FILE>.sha256
sha256sum -c <BACKUP_FILE>.sha256

Restore

⚠ Restore có thể ghi đè dữ liệu. Luôn ưu tiên restore sang database hoặc môi trường staging khác trước; không dùng --drop nếu chưa xác nhận rõ phạm vi dữ liệu cần thay thế.

Ví dụ đổi namespace dưới đây dùng để kiểm tra dữ liệu được restore sang database khác. Để khôi phục full dump được tạo bằng --oplog, phải dùng mongorestore --oplogReplay trên môi trường đích phù hợp; không kết hợp với các tùy chọn giới hạn hoặc đổi namespace như --nsFrom và --nsTo. Ví dụ này không thay thế quy trình khôi phục full dump kèm oplog. Xem mongodump và mongorestore.

# Restore sang database mới để validation
mongorestore \
  --uri "mongodb://<USER>@<HOST>:<PORT>/?authSource=<AUTH_DB>" \
  --gzip \
  --archive="<BACKUP_FILE>" \
  --nsFrom="<SOURCE_DB>.*" \
  --nsTo="<TARGET_DB>.*"

# Chỉ dùng khi cần thay thế collection/database đích đã được phê duyệt
# mongorestore --uri "<URI>" --gzip --archive="<BACKUP_FILE>" --drop

Sau restore, kiểm tra số collection, số document trong các collection quan trọng, index, quyền của user ứng dụng và log khi ứng dụng kết nối database mới.

Checklist vận hành MongoDB

Xác nhận đúng host, port, database và vai trò node trước khi thao tác.
Kiểm tra systemctl status mongod, log lỗi và dung lượng filesystem.
Với replica set: kiểm tra PRIMARY/SECONDARY và replication lag.
Backup phải có exit code thành công, checksum hợp lệ và kết quả restore thử đã được xác nhận.
Các thao tác thay đổi có kế hoạch rollback và được ghi nhận.

3. MySQL (port 3306)

Thông tin nền tảng & service

Hạng mục	Giá trị thường gặp
Service	`mysql` (Ubuntu/Debian) hoặc `mysqld` (RHEL-family)
Config	`/etc/mysql/my.cnf`, `/etc/mysql/mysql.conf.d/mysqld.cnf` hoặc `/etc/my.cnf`
Data	`/var/lib/mysql/`
Log	`journalctl -u mysql` hoặc error log được khai báo trong cấu hình

systemctl status mysql
mysql --version
mysqladmin ping -h <HOST> -P <PORT> -u <USER> -p
journalctl -u mysql -n 100 --no-pager

Kết nối & kiểm tra nhanh

🔐 Không ghi password trực tiếp trong lệnh, script, shell history hoặc tài liệu. Dùng -p để nhập tương tác, option file có permission hạn chế hoặc secret manager được công cụ hỗ trợ.

mysql -h <HOST> -P <PORT> -u <USER> -p

SELECT VERSION();
SELECT CURRENT_USER(), USER();
SELECT DATABASE();
SHOW DATABASES;
SHOW FULL PROCESSLIST;
SHOW REPLICA STATUS\G

Vận hành database, table & user

USE <DATABASE>;
SHOW TABLES;
SHOW TABLE STATUS LIKE '<TABLE>';
SELECT COUNT(*) FROM <TABLE>;

CREATE USER '<USER>'@'<HOST>' IDENTIFIED BY '<PASSWORD>';
GRANT SELECT, INSERT, UPDATE, DELETE ON <DATABASE>.* TO '<USER>'@'<HOST>';
SHOW GRANTS FOR '<USER>'@'<HOST>';

⚠ DROP DATABASE, DROP TABLE, DROP USER, ALTER TABLE trên table lớn và thay đổi quyền có thể gây mất dữ liệu, lock hoặc gián đoạn ứng dụng. Đánh giá phạm vi ảnh hưởng, thời gian thực hiện và cơ chế lock; chuẩn bị backup hoặc phương án rollback trước khi thao tác.

Monitoring & replication

SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Threads_running';
SHOW GLOBAL STATUS LIKE 'Uptime';
SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS\G
SHOW REPLICA STATUS\G

💡 Kiểm tra slow query, lock, mức sử dụng connection, disk usage, error log và replication lag trước khi cân nhắc KILL. Chỉ dừng session đã xác định rõ và đánh giá tác động tới ứng dụng.

Backup

📘 --single-transaction phù hợp với InnoDB và giảm nhu cầu lock khi dump; tùy chọn này không đảm bảo tính nhất quán cho table non-transactional hoặc khi có DDL chạy đồng thời. Lên lịch backup vào thời điểm phù hợp và kiểm tra restore định kỳ.

# Backup một database; bao gồm object cần thiết và nén output
mysqldump \
  -h <HOST> -P <PORT> -u <USER> -p \
  --single-transaction --routines --events --triggers \
  <DATABASE> | gzip > "<BACKUP_PATH>/<DATABASE>-$(date +%F-%H%M).sql.gz"

# Backup toàn bộ instance khi phù hợp với mục tiêu recovery
mysqldump \
  -h <HOST> -P <PORT> -u <USER> -p \
  --all-databases --routines --events --triggers \
  | gzip > "<BACKUP_PATH>/all-databases-$(date +%F-%H%M).sql.gz"

Kiểm tra tối thiểu: exit code của cả mysqldump và gzip, dung lượng file và checksum. Nếu Bash chưa bật pipefail, exit code của pipeline chỉ phản ánh lệnh cuối; gzip thành công không chứng minh dump đầy đủ. Lưu thêm thời điểm backup, phiên bản MySQL và danh sách database đã dump. Xem Bash pipeline exit status.

sha256sum <BACKUP_FILE> > <BACKUP_FILE>.sha256
sha256sum -c <BACKUP_FILE>.sha256

Restore & point-in-time recovery

⚠ Restore ghi đè hoặc replay binary log có thể thay đổi nhiều dữ liệu. Restore thử trên server staging trước, xác định chính xác mốc khôi phục và giữ nguyên bản backup gốc.

# Restore vào database đích đã tạo trước
gunzip -c "<BACKUP_FILE>.sql.gz" | mysql -h <HOST> -P <PORT> -u <USER> -p <TARGET_DATABASE>

# Kiểm tra binary log trước khi lập kế hoạch PITR
mysql -h <HOST> -P <PORT> -u <USER> -p -e "SHOW VARIABLES LIKE 'log_bin';"
mysql -h <HOST> -P <PORT> -u <USER> -p -e "SHOW BINARY LOGS;"

# Ví dụ replay log đến ngay trước thời điểm lỗi; chạy trước trên staging
mysqlbinlog \
  --start-datetime="<YYYY-MM-DD HH:MM:SS>" \
  --stop-datetime="<YYYY-MM-DD HH:MM:SS>" \
  --database="<DATABASE>" \
  <BINLOG_FILE> | mysql -h <HOST> -P <PORT> -u <USER> -p <TARGET_DATABASE>

⚠ PURGE BINARY LOGS có thể phá vỡ khả năng PITR hoặc replication nếu purge sai mốc. Chỉ thực hiện sau khi xác minh retention, backup và trạng thái tất cả replica.

Checklist vận hành MySQL

Xác nhận đúng host, port, user, database và vai trò primary/replica.
Kiểm tra service, error log, disk, connection/thread và slow query/lock.
Với replication: kiểm tra lỗi SQL/IO, lag và binary log retention.
Backup phải có exit code thành công, checksum hợp lệ và kết quả restore thử đã được xác nhận.
Đánh giá tác động và chuẩn bị phương án rollback cho mọi thay đổi schema, quyền hoặc dữ liệu.