我們是否需要在生產數據庫（MySQL/InnoDB）上使用屏障？
即使我們使用啟用了屏障的日誌文件系統（EXT3） ，這是否仍然更安全且值得推薦？
例如
mount -o barrier=1 /dev/sda /mntpnt參考：
是的，它總是更安全。認為實際獲得腐敗的機會很低。當文件系統損壞時，修復它很可能會成功。像 InnoDB 這樣的 ACID 兼容數據庫也執行 fsyncs/barriers 以確保送出的更改永久儲存在磁碟上。
不要忘記，在生產環境中，您應該使用帶有冗餘 PSU 和/或 UPS 的高質量伺服器，因此您真正需要該期刊的機會已經很小了。
不啟用它的一個原因可能是性能。當然，這只影響寫入性能。但是這些東西應該被測量，因為它們高度依賴於你的硬體。例如，當在 raid 控制器上使用電池支持的寫記憶體執行時，由於控制器的寫回記憶體，性能損失將與零一樣好。
所以總而言之，我認為風險非常小，但這取決於所面臨的風險。就個人而言，我認為如果風險足夠高以保證這樣做，您應該考慮複製到第二台伺服器。當然，您已經在進行定期備份。
順便說一句：fsync 在 ext3 上效率低下，因為它總是同步所有文件！符合 ACID 的數據庫往往會執行大量 fsync，因此如果可以的話，最好使用 ext4。
您的問題本身就是這樣：我關心的是 MySQL 數據性能還是一致性？
如果一致性是首要的事情，那麼保持 InnoDB 的 ACID 設置。
您的innodb_flush_log_at_trx_commit應該為 1。您可以將其設置為 0 或 2 以提高性能，但在發生崩潰時有失去數據的風險。
您可以使用 tweek innodb_flush_method來增強 MySQL 處理刷新數據的方式。如果您不確定將其設置為什麼，請保留其預設設置。
您可以將sync_binlog設置為 1 以確保事務在送出時被記錄到二進制日誌中。
根據您在 ext3 journaling and barrier 上提供的連結，這是算法：
- 日誌塊被寫入日誌。
- 執行屏障操作。
- 送出記錄被寫入。
- 另一個屏障被執行。
- 元數據寫入在稍後的某個時間點開始。
呸！！！這感覺就像磁碟級別的 ACID 合規性。
想像一下在雲伺服器上執行 VMWare，然後從中創建 VMWare 伺服器？雲執行雲確實會受到性能挑戰。這就是您在使用 ext3 屏障以及將 InnoDB 設置為 sync_binlog=1 和 innodb_flush_log_at_trx_commit=1 時基本上獲得的性能。就 InnoDB 和 ext3 單獨和集體而言，這是最安全和最慢的方法。
為了彌補這一點，您可能需要專注於 InnoDB 的性能調整。
對於初學者，將 sync_binlog 保留為 0。
接下來，配置 InnoDB 以使其使用更多 CPU 和更多核心。此外，更大的 InnoDB 日誌文件會有所幫助。
以下是我過去關於此類調整的一些連結：
- 關於單執行緒與多執行緒數據庫性能
- 可以讓 MySQL 使用多個核心嗎？
- 插入繁重的 InnoDB 表不會使用我所有的 CPU
- MySQL innodb_flush_method 變數的說明
- 如何安全地更改 MySQL innodb 變數“innodb_log_file_size”？
如果您是 MySQL 5.1 或更早版本，則應升級到 MySQL 5.5 或 Percona Server 5.5。