Home » Posts tagged "recovery"

MySQL 的 XA Transaction

Percona 的「How to Deal with XA Transactions Recovery」這篇提到 MySQLXA Transaction 的復原問題。

XA Transaction 主要拿來做分散式上的事物交易,在官方文件上就有提到對應的標準:

The MySQL XA implementation is based on the X/Open CAE document Distributed Transaction Processing: The XA Specification. This document is published by The Open Group and available at http://www.opengroup.org/public/pubs/catalog/c193.htm.

不過我覺得比較有趣的是這點,Percona 直接建議不要用 5.6 的 XA:

But there is a limitation in 5.6: you can only XA commit/rollback transactions that belong to your session. That means after a crash you are out of luck. To get rid of these you need to promote a slave or perform a logical dump and restore. The best plan is to avoid the use of XA transactions with 5.6.

不過翻了 bug report,Oracle 官方的 5.7 還是沒解決,看起來是 Percona 自己 patch 掉 XDDD

在 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;

然後把檔案 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> 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 裡測試),等不幸遇到的時候手腳比較不會慌亂...

OpenSSL 的 DSA 被 Side-channel attack 打爆

在「Make Sure DSA Signing Exponentiations Really are Constant-Time」這篇文章裡面,直接透過 end-to-end 的 timing attack 打爆 (也就是透過 internet 觀察攻擊),而不需要在同一台機器上對 cache 之類的區域攻擊:

A unique feature of our work is that we target common cryptographic protocols. Previous works that demonstrate cache-timing key-recovery attack only target the cryptographic primitives, ignoring potential cache noise from the protocol implementation. In contrast, we present end-to-end attacks on two common cryptographic protocols: SSH and TLS. We are, therefore, the first to demonstrate that cache-timing attacks are a threat not only when executing the cryptographic primitives but also in the presence of the cache activity of the whole protocol suite.

而且次數相當的少,就可以 key recovery:

260 SSH-2 handshakes to extract a 1024/160-bit DSA host key from an OpenSSH server, and 580 TLS 1.2 handshakes to extract a 2048/256-bit DSA key from an stunnel server.

CVE 編號為 CVE-2016-2178OpenSSL 全系列 (包括 fork 出去的版本) 與 OpenSSH 只要是 DSA 的實作都中獎...

Amazon 之前放出的 s2n 的安全性問題

Amazon 之前放 s2n 出來當作 TLS protocol 的方案,於是就有人摸出東西來:「Lucky Microseconds: A Timing Attack on Amazon's s2n Implementation of TLS」。

即使是經過外部資安檢證,仍然還是有找到問題。這次找到的問題是 timing attack 類在 CBC-mode 下的 plaintext recovery:

At the time of its release, Amazon announced that s2n had undergone three external security evaluations and penetration tests. We show that, despite this, s2n - as initially released - was vulnerable to a timing attack in the case of CBC-mode ciphersuites, which could be extended to complete plaintext recovery in some settings.


Our attack has two components. The first part is a novel variant of the Lucky 13 attack that works even though protections against Lucky 13 were implemented in s2n. The second part deals with the randomised delays that were put in place in s2n as an additional countermeasure to Lucky 13. Our work highlights the challenges of protecting implementations against sophisticated timing attacks.

最後還是酸了一下 Amazon:

It also illustrates that standard code audits are insufficient to uncover all cryptographic attack vectors.

Amazon 的官方說明則在「s2n and Lucky 13」這邊可以看到。

Amazon EC2 的 Auto Recovery

2015/01/12 先前在「Amazon EC2 Auto Recovery now available in the US East (N. Virginia) Region」這邊發表了,不過剛剛在「New – Auto Recovery for Amazon EC2」這邊看到消息。

重點在於偵測到問題時會重開機,並且保持原來的 instance id、IP address、Elastic IP address、EBS 以及其他外部設定:

The instance will be rebooted (on new hardware if necessary) but will retain its Instance Id, IP Address, Elastic IP Addresses, EBS Volume attachments, and other configuration details.

而被限制在比較新的硬體上,並且目前只有 us-east-1 有:

This feature is currently available for the C3, C4, M3, R3, and T2 instance types running in the US East (Northern Virginia) region; we plan to make it available in other regions as quickly as possible.

當時看到就覺得很實用了,後來在建立一些底層的 infrastructure 時,覺得其他區沒這功能頗難處理。有在 us-east-1 放機器的人可以測試看看。