在 MySQL InnoDB 下單表復原的方式

在「How to Restore a Single InnoDB Table from a Full Backup After Accidentally Dropping It」這篇提到了 MySQL InnoDB 單表復原的事情。

文章裡先提到了 2012 年的文章「How to recover a single InnoDB table from a Full Backup」,講更特定的情況。

這邊兩篇的大前提都是使用 innodb_file_per_table

2012 的文章裡講的是誤刪 (DELETE) 後的處理,如果是 DROP TABLETRUNCATE 或是因為 ALTER TABLE 而造成資料遺失的話,就不能用這篇文章的方式處理:

You must not drop, truncate or alter the schema of the table after the backup has been taken.

如果很幸運是因為 DELETE 而遺失的話,在文章裡有提到 innobackupex 這個工具,透過 innobackupex 備份的資料才有辦法依照文章裡的方法做到單表復原。

先 discard tablespace:

mysql> set FOREIGN_KEY_CHECKS=0;
mysql> ALTER TABLE salaries DISCARD TABLESPACE;

然後把檔案 cp 進去:

cp /tmp/2012-01-22_14-13-20/employees/salaries.ibd /var/lib/mysql/data/employees/

最後再 import tablespace 回去:

mysql> set FOREIGN_KEY_CHECKS=0;
mysql> ALTER TABLE salaries IMPORT TABLESPACE;
mysql> set FOREIGN_KEY_CHECKS=1;

而 2017 講的誤刪則是補充了 2012 文章裡另外的情況,用途也比較廣,但動作比較複雜。

本來的四個步驟:

  • Prepare the backup
  • Discard the tablespace of the original table
  • Copy .ibd from the backup to the original table path
  • Import the tablespace

變成了七個步驟:

  • Prepare the backup
  • Extract the original table structure from the backup (i.e., extract the create statement from the backup .frm file)
  • Create a new empty table
  • Apply some locks
  • Discard the newly created tablespace
  • Copy back .ibd from the backup
  • Import the tablespace

粗體的部份就是不一樣的部份,多出來的步驟產生出同樣的環境配合 .ibd,然後讓 .ibd 檔匯進 MySQL。

實際練過一次會比較有感覺 (應該可以在 Docker 裡測試),等不幸遇到的時候手腳比較不會慌亂...

VaultPress 的新方案

VaultPressWordPress 的付費服務,可以備份自己架設的 WordPress 站台。

剛剛看到新的方案出爐了:「Announcing Streamlined Plans — at Lower Prices」,Jetpack Personal 將本來的 VaultPress Lite 包在內,但是價錢更低了:

At $3.50 per month, the Jetpack Personal plan includes everything the old VaultPress Lite plan used to — at a price that’s 30% lower.

有在用的人記得進去更改方案,另外要注意生效時間,等原來 Lite 快到期再改。

Facebook 備份 MySQL 資料並且確認正確性的方法

Facebook 再多花了一些篇幅數對於 MySQL 資料備份以及確認正確性的方法:「Continuous MySQL backup validation: Restoring backups」。

首先是 Continuous Restore Tier (CRT) 這塊,可以看到他們在這塊很仰賴 HDFS 當作備份的第一層基地,包括了 Full logical backups (用 mysqldump)、Differential (diff) backups 以及 Binary log (binlog) backups (stream 進 HDFS)。

另外上了 GTID,對於後續的處理會比較方便:

All of our database servers also use global transaction IDs (GTIDs), which gives us another layer of control when replaying transactions from binlog backups.

在 CRT 這塊可以看到其實是拿現成的工具堆起來,不同單位會因為規模而有不同的作法。真正的重點反而在 ORC Restore Coordinator (ORC) 這塊,可以看到 Facebook 開發了大量的程式將回復這件事情自動化處理:

在收到回復的需求後,可以看到 Peon 會從 HDFS 拉資料出來,並且用 binlog replay 回去:

Peons contain all relevant logic for retrieving backups from HDFS, loading them into their local MySQL instance, and rolling them forward to a certain point in time by replaying binlogs. Each restore job a peon works on goes through these five stages[.]

也是因為 Facebook 對 MySQL 的用量大到需要自動化這些事情,才有這些東西...

在 Mac 上把資料備份到 Amazon Glacier 的軟體

Hacker News Daily 上看到「Freeze - the ultimate Amazon Glacier file transfer client for Mac」這個軟體,需要 Mac OS X 10.10 以上的版本才能用...

拿來丟東西應該還不錯 (方便的 client),建一個對應權限 IAM 帳號,然後把 key 丟給他用吧...

MySQL 5.7 將會有新的備份工具 mysqlpump

在「Introducing mysqlpump」這邊提到了 MySQL 5.7 將會有 mysqlpump 這個新工具,主要是避免影響 mysqldump,但又可以產生容易平行處理的 dump data:

The goal of mysqlpump is to have a modern utility that is extendable and has native support for parallelization.

看了一下範例還蠻簡單的 (目標也很明確),應該是之後的參考工具...

Percona 的 MySQL 備份服務

Percona 前幾天發表的新服務,Percona Backup Service:「MySQL Backup Service from Percona」。

只提供人力服務,而非雲端服務:

You provide the backup servers – on premise, in the cloud, or any combination. We implement the tools and processes to run your backups.

你還是要自己準備備份的設備,所以資料都還是可以控制在自己的手上。這個服務是借重 Percona 的人對 MySQL 的專長所發展的服務。

不過目前官網上沒有列出價錢,要寫信去問。

另外文章裡有提到「MySQL Backup and Recovery Best Practices」這份投影片,可以看一看 Percona 對備份的規劃,主要是從技術的方面討論 (尤其是備份時產生的 LOCK 問題)。

Percona XtraBackup 2.1.1

Percona 宣佈 Percona XtraBackup 2.1.1 (第一個 2.1 GA 的版本):「Announcing Percona XtraBackup 2.1.1 GA」。

這次的版本提供了 compact backup,備份的時候不要備份 secondary index (因為這可以再建出來),在很多 index 的表格會省下大量的空間 (以及備份的時間),不過還原的時候就得 rebuild,而非直接拿來用,算是讓操作者自己取捨...