This article summarizes practical usages and command syntax for mysqldump in MySQL / MariaDB 5.5 environments.It covers common export scenarios, important options, and best practices — ideal as a quick reference for backup and restoration tasks. 1. What Is mysqldump? mysqldump is a built-in MySQL/MariaDB utility used to export: The exported result is a plain…
Blog
Mysqldump 匯出語法筆記 (MySQL / MariaDB 5.5)
本文整理了 MySQL / MariaDB 5.5 環境下 mysqldump 指令的匯出語法與實務建議，適合日後備查與快速套用。主要涵蓋單一資料庫、全部資料庫、部分資料表、交易一致性、編碼設定與壓縮匯出等情境。 一、mysqldump 是什麼？ mysqldump 是 MySQL 與 MariaDB 內建的備份工具，用來匯出： 匯出結果為純文字 SQL 檔，可直接使用 mysql 或 mariadb 指令匯入還原。 二、基本匯出語法 匯出單一資料庫 匯出所有資料庫 匯出特定資料表 三、交易一致性與鎖定策略 引數 適用引擎 說明 –single-transaction InnoDB 匯出時不鎖表，資料一致性最佳 –lock-tables MyISAM 匯出前鎖表，避免資料變動 四、常用參數建議 參數 說明 –routines 匯出 Stored Procedures / Functions –events 匯出排程事件 –triggers 匯出觸發器（預設會匯出，但可保險加上） –hex-blob 將 BLOB / TEXT…
Importing MariaDB SQL Files Inside Docker Containers — Practical Notes
This post documents how to import .sql or .sql.gz backup files into MariaDB (version 12.1.1) running inside a Docker container, including common mistakes and their fixes. 1. Background When managing databases in containerized environments, it’s common to deploy MariaDB inside Docker and occasionally import database backups for restoration or migration. Example environment: Item Value Container…
在 Docker 容器中匯入 MariaDB SQL 檔案 — 實務筆記
本文記錄如何在 Docker 容器中執行 MariaDB (12.1.1) 的 SQL 匯入作業，並說明常見錯誤與修正方式，方便日後備查。 一、背景說明 在維運環境中，我們常會在 Docker 容器中部署 MariaDB 資料庫，並需要將備份的 .sql 檔或 .sql.gz 壓縮檔匯入。 以本次環境為例： 項目 設定值 容器名稱 blognufacedb MariaDB 版本 12.1.1-MariaDB 帳號 nuface 密碼 abcd123 資料庫名稱 nuface 匯入檔案 nuface_2025-09-16.sql 二、原始執行指令 執行後出現以下訊息： MariaDB 並未執行匯入，而是列出整份使用說明。 三、問題原因 造成問題的主因是： -p 後面多了一個空白MariaDB 會將 ‘abcd123’ 視為「資料庫名稱」而非密碼，導致參數順序錯亂，程式直接輸出說明文件。 四、正確匯入方式 ✅ 方法 1：-p’密碼’（不能有空白） ✅ 方法 2：使用 –password=密碼 ✅ 方法…
How to Transfer Docker Images Between Machines — Do You Need to Copy the Base Image Too?
In daily DevOps or system administration work, we often build a new Docker image (e.g., XX) on one machine (say, Machine A) and want to move it to another (say, Machine B).A common question arises: If my image XX is built FROM another image YY, do I also need to copy YY to Machine B?…
Docker 映像檔跨機器搬移實務：是否需要一起複製底層 image？
在日常維運或開發中，我們常會在一台主機（例如 A 機器）上建立新的 Docker 映像檔（image），並想將它移轉到另一台主機（B 機器）使用。這時常見的疑問是： 若我在 A 機器上建立的映像 XX 是從 YY 映像衍生（FROM YY）而來，那我在複製時，是否需要把 YY 也一起複製到 B 機器？ 結論先講：👉 不需要另外拷貝 YY！ 🔍 為什麼只要複製 XX 就夠？ Docker 映像是由多層（layer）組成的，XX 映像是以 YY 為基底延伸出的新層。當你使用 docker save 將 XX 打包時，Docker 會自動包含它所依賴的所有父層（也就是 YY 的部分）。 因此，當你在另一台機器使用 docker load 匯入後，Docker 會自動還原整個映像層結構： 💡 正確的搬移方法 方法一：使用 docker save / docker load（離線搬移） 這樣 B 機器就會同時擁有： 方法二：透過私有或公有…
Docker Architecture Insight: Should Each Project Have Its Own Database Container?
When working with Docker-based applications, a common architectural question often comes up: “If multiple projects need a database, should each project run its own database container,or should all projects connect to a single shared database container?” This question looks simple but touches on isolation, security, maintainability, and resource efficiency.Here’s a summary of my practical observations…
Docker 架構思考：每個專案都要有自己的資料庫容器嗎？
在實務開發或系統部署中，常會遇到這個問題： 「在 Docker 架構下，如果不同專案都需要使用資料庫（Database），應該讓每個專案都啟動一個獨立的 DB 容器？還是所有專案共用一個資料庫容器？」 這個問題看似單純，其實關係到整體系統的 隔離性、安全性、維運便利性、以及資源效率。以下是我整理的一些心得與比較，供自己與同業參考。 一、兩種架構方式比較 面向 每個專案一套獨立 DB 容器 共用一套 DB 容器 系統隔離性 高。某個專案出問題（CPU、磁碟滿）不會影響其他專案。 低。多專案共用同一資源池，容易互相影響。 資安風險 帳號與資料完全分離，權限控管簡單明確。 同一引擎內切分 schema/db，權限邊界容易模糊。 版本管理 可自由升級、回滾，互不影響。 必須維持同一版本，升級需協調。 備份/還原 可針對單一專案還原，災難復原容易。 還原時容易波及其他資料。 資源使用 比較吃資源（多個 DB 進程、快取重複佔用）。 資源利用率高，節省記憶體與 CPU。 部署便利 Docker Compose 一鍵啟動，獨立性強。 需事先建立共用 DB，專案依賴性較高。 維運負擔 多套 DB 要維護、監控、備份，負擔較重。 單點維護簡單，但也成為單一故障點。 二、怎麼選比較好？ 🔹 正式環境（Production） 🔹 開發與測試環境（Dev / QA） 三、實務建議 1️⃣…
Using Apache 2.4 on AWS as a Reverse Proxy: Debugging 502s & Hardening in Practice (with vhost-scoped logs and rotatelogs)
This post summarizes a real troubleshooting session; all company/domain details are anonymized.Example domains use demodomain.com, e.g., wmsadmin.demodomain.com. Architecture Overview Typical vhost (simplified): Symptom Troubleshooting Flow (quick checklist) Raise timeouts only on long-running paths Avoid setting a huge global timeout that can tie up workers. Relax timeouts per URI: If mod_reqtimeout is enabled, prevent slow uploads…
在 AWS 上用 Apache 2.4 做反向代理：502 問題排查與實戰調校（含 vhost 分檔與 rotatelogs）
本文整理自一段真實排查經驗，所有公司與網域資訊已去識別化。範例網域以 demodomain.com 表示，例如 wmsadmin.demodomain.com。 架構概述 典型 vhost（簡化示意）： 問題現象 排查思路（速查） 針對長耗時路徑「差異化」放寬 timeout 不要全站一刀切放到很長，避免把 worker 綁死；只對特定 URI 提高 timeout： 若有啟用 mod_reqtimeout，避免慢速上傳被切斷： 如何判讀「滿版的 trace 訊息」？ 看到像這樣的行： 代表只是 偵錯等級很高時，Apache 把上游回應 header 與傳輸流程寫進 error log。不是錯誤。要看真正異常，請降回 LogLevel warn，或在 access log 先找 502 再對照 error log 該時段的 warn/error 級別訊息。 vhost 各自分檔記錄（擺脫 other_vhosts_access.log） 在每個 vhost 內指定 ErrorLog/CustomLog，最簡單： 如不想再用全域 other_vhosts_access.log，可停用： （注意：停用後，沒自訂 CustomLog 的 vhost…