不再怕數據丟失！阿里雲RDS MySQL 8.0上線回收站功能

RDS MySQL 8.0 Recycle Bin

背景

MySQL 在生產環境使用過程當中，會伴隨着開發和運維人員的誤操做，好比 DROP TABLE / DATABASE，這類 DDL 語句不具備可操做的回滾特性，而致使數據丟失，AliSQL 8.0 新特性支持回收站功能（Recycle Bin），臨時把刪除清理的錶轉移到回收站，並保留可設置的時間，方便用戶找回數據。爲了方便，提供了 DBMS_RECYCLE package 做爲管理接口。

Recycle Bin 管理接口

Recycle Bin 提供了兩個管理接口，分別是：

DBMS_RECYCLE.show_tables()
展現回收站中全部臨時保存的表：

mysql> call dbms_recycle.show_tables();
+-----------------+---------------+---------------+--------------+---------------------+---------------------+
| SCHEMA          | TABLE         | ORIGIN_SCHEMA | ORIGIN_TABLE | RECYCLED_TIME       | PURGE_TIME          |
+-----------------+---------------+---------------+--------------+---------------------+---------------------+
| __recycle_bin__ | __innodb_1063 | product_db    | t1           | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
| __recycle_bin__ | __innodb_1064 | product_db    | t2           | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
| __recycle_bin__ | __innodb_1065 | product_db    | parent       | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
| __recycle_bin__ | __innodb_1066 | product_db    | child        | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
+-----------------+---------------+---------------+--------------+---------------------+---------------------+
4 rows in set (0.00 sec)

-- Columns 解釋:

SCHEMA 
回收站的 schema
TABLE 
進入回收站後的表名
ORIGIN_SCHEMA 
原始表的 schema
ORIGIN_TABLE 
原始表的表名
RECYCLED_TIME 
回收時間
PURGE_TIME 
將來被清理掉的時間

1，
DBMS_RECYCLE.purge_table(table_name=>)
手動清理回收站中的某張表

mysql> call dbms_recycle.purge_table("__innodb_1063");
Query OK, 0 rows affected (0.01 sec)


清理掉回收站中的"__innodb_1063" 表

Recycle Bin 參數
Recycle Bin 一共設計了 5 個參數，分別是：

1，recycle_bin

recycle_bin

-- 是否打開回收功能， session + global 級別。

2，recycle_bin_retention

recycle_bin_retention


    -- 回收站保留最長時間是多少，單位是seconds，默認是一週。

3，recycle_scheduler

recycle_scheduler
    -- 是否打開回收站的異步清理任務線程

4，recycle_scheduler_interval

recycle_scheduler_interval
    -- 回收站異步清理線程的輪詢間隔，單位是seconds, 默認是30s。

5，recycle_scheduler_purge_table_print

recycle_scheduler_purge_table_print
    -- 是否打印異步清理現場工做的詳細日誌

Recycle Bin 設計
Recycle Bin 總覽

1. 回收機制

當操做 DROP TABLE / DATABASE 語句的時候， 只保留相關的表對象，並移動到專門的 recycle bin 目錄中，
其它對象的刪除策略是：

1. 與表無關的對象，好比 procedure，根據操做語句決定是否保留，不作回收。
2. 表的附屬對象，好比 trigger，Foreign key，column statistics等，只要存在可能修改表數據的，作刪除，
   好比 trigger，Foreign key。 但columns statistics不作清理，隨表進入回收站。

2. 清理機制

回收站會啓動一個background 線程，來異步清理超過 recycle_bin_retention 時間的表對象, 在清理回收站表的時候，若是遇到是大表的清理，會再啓動一個background 來作異步大文件刪除。

Recycle schema 和權限控制

1. recycle schema 
MySQL 系統啓動的時候，會初始化一個 recycle bin 的schema， 命名爲 "__recycle_bin__"， 做爲回收站使用的專有 database。

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| __recycle_bin__    |
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
6 rows in set (0.00 sec)

2. 權限控制

Database 權限：
recycle_bin 做爲回收站的 schema，是系統級 database，沒有權限作修改和刪除。
用戶沒法使用drop table / database 來操做回收站。
好比：

mysql> drop table __recycle_bin__.__innodb_1064;
ERROR 1044 (42000): Access denied for user 'b1'@'%' to database '__recycle_bin__'

recycled table 權限：

-- recycle scheduler 後臺線程具備全部權限，能夠作清理工做；
-- 用戶雖然沒法直接 drop table，可使用 dbms_recycle.purge_table()，

但仍然須要原表和回收站表都具備 DROP_ACL 權限：

好比：

mysql> call dbms_recycle.purge_table("__innodb_1064");
ERROR 1142 (42000): DROP command denied to user 'b1'@'localhost' for table '__innodb_1064'

-- Grant 回收站權限
mysql> grant drop on __recycle_bin__.__innodb_1064 to b1@'%';
Query OK, 0 rows affected (0.00 sec)
-- Grant 原表權限
mysql> grant drop on product_db.t2 to b1@'%';
Query OK, 0 rows affected (0.00 sec)

mysql> call dbms_recycle.purge_table("__innodb_1064");
Query OK, 0 rows affected (0.01 sec)

Recycled table 命名規則
Recycled table 會從不一樣的 schema，回收到統一的 recycle bin 回收站中，因此須要保證目標表表名惟一，因此
這裏定義了一個命名格式：

"__" + Storge Engine + SE private id

Storge Engine：表明存儲引擎名稱，好比 innodb。

SE private id：是存儲引擎爲每個表生成的惟一值，好比 InnoDB 中，就是 table id，
以此來惟一表示一個表名稱。

Recycled table 關聯對象
在回收表的過程當中，須要處理表的相關對象，其處理的原則是：

1. 若是是表附屬對象，可能會存在修改表數據的可能性，就作刪除，好比 trigger 和 FK。
2. 若是是表相關對象，不會修改數據，就不作清理，好比相關的 view，統計信息等。
   下面經過一個例子來看下：

原始結構

CREATE TABLE parent (
    id INT NOT NULL,
    PRIMARY KEY (id)
) ENGINE=INNODB;

CREATE TABLE child (
    id INT,
    parent_id INT,
    self_id INT,
    INDEX id_ind (id),
    INDEX par_ind (parent_id),
    INDEX sel_ind (self_id),
    FOREIGN KEY (self_id) REFERENCES child(id),
    FOREIGN KEY (parent_id) REFERENCES parent(id) ON DELETE CASCADE
) ENGINE=INNODB;

CREATE TABLE log(id INT);

delimiter //
CREATE TRIGGER trigger_child
  before INSERT ON child FOR EACH ROW
BEGIN
  INSERT INTO log value(1);
END//
delimiter ;

CREATE VIEW view_child AS SELECT * FROM child;

Drop 並回收（相關關聯對象刪除或失效）

1. 刪除表 child；
mysql> drop table child;
Query OK, 0 rows affected (0.01 sec)

2. 查看回收站，及 child 表在回收站的結構
mysql> call dbms_recycle.show_tables();
+-----------------+---------------+---------------+--------------+---------------------+---------------------+
| SCHEMA          | TABLE         | ORIGIN_SCHEMA | ORIGIN_TABLE | RECYCLED_TIME       | PURGE_TIME          |
+-----------------+---------------+---------------+--------------+---------------------+---------------------+
| __recycle_bin__ | __innodb_1068 | test          | child        | 2019-08-08 12:32:48 | 2019-08-15 12:32:48 |
+-----------------+---------------+---------------+--------------+---------------------+---------------------+

mysql> show create table __recycle_bin__.__innodb_1068\G
*************************** 1. row ***************************
       Table: __innodb_1068
Create Table: CREATE TABLE `__innodb_1068` (
  `id` int(11) DEFAULT NULL,
  `parent_id` int(11) DEFAULT NULL,
  `self_id` int(11) DEFAULT NULL,
  KEY `id_ind` (`id`),
  KEY `par_ind` (`parent_id`),
  KEY `sel_ind` (`self_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

-- 相關的 Foreign key 已經所有刪除。

3. 查看相關trigger。
mysql> show create trigger trigger_child;
ERROR 1360 (HY000): Trigger does not exist

-- 相關的trigger已經所有刪除。

4. 查看相關view。
mysql> show create view view_child\G
*************************** 1. row ***************************
                View: view_child
         Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `view_child` AS select `child`.`id` AS `id`,`child`.`parent_id` AS `parent_id`,`child`.`self_id` AS `self_id` from `child`
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
1 row in set, 1 warning (0.01 sec)

mysql> show warnings;
+---------+------+-----------------------------------------------------------------------------------------------------------------------------------+
| Level   | Code | Message                                                                                                                           |
+---------+------+-----------------------------------------------------------------------------------------------------------------------------------+
| Warning | 1356 | View 'test.view_child' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them |
+---------+------+-----------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

-- 相關的view 已經失效。

Master-slave 獨立回收

在 master - slave 結構中， 是否回收，或回收站保留的週期，都是實例自己的設置，不會影響到 binlog 複製到的節點上，因此，咱們能夠在 master 節點上設置回收，保留 7 天週期，在slave 節點上，設置回收，保留14天週期。
好比
master：

--recycle_bin = on
--recycle_bin_retention = 7 * 24 * 60 * 60

master節點上，回收站保留 7 天

slave：

--recycle_bin = on
--recycle_bin_retention = 14 * 24 * 60 * 60

slave 節點上，回收站保留 14 天

要注意的點就是，回收站保留週期不一樣，將致使 master - slave 節點之間的空間佔用差異比較大。

異步表清理和大文件刪除

當 recycle scheduler 異步線程 purge 回收站的表時候，若是遇到大表，那麼將會啓動大表異步刪除邏輯，相關參數以下：

INNODB_DATA_FILE_PURGE: Whether enable the async purge strategy
INNODB_DATA_FILE_PURGE_IMMEDIATE: Unlink data file rather than truncate
INNODB_DATA_FILE_PURGE_ALL_AT_SHUTDOWN: Cleanup all when normal shutdown
INNODB_DATA_FILE_PURGE_DIR: Temporary file directory
INNODB_DATA_FILE_PURGE_INTERVAL: Purge time interval (by milliseconds)
INNODB_DATA_FILE_PURGE_MAX_SIZE: Purge max size every time (by MB)
INNODB_PRINT_DATA_FILE_PURGE_PROCESS: Print the process of file purge worker

好比設置：

set global INNODB_DATA_FILE_PURGE = on;
set global INNODB_DATA_FILE_PURGE_INTERVAL = 100;
set global INNODB_DATA_FILE_PURGE_MAX_SIZE = 128;

每 100ms，刪除 128MB 大小。

能夠經過以下視圖，查看大表異步刪除的進展狀況：

mysql> select * from information_schema.innodb_purge_files;
   +--------+---------------------+--------------------------------------+---------------+------------------------+--------------+
   | log_id | start_time          |          original_path               | original_size | temporary_path         | current_size |
   +--------+---------------------+--------------------------------------+---------------+------------------------+--------------+
   |     36 | 2019-08-08 12:06:38 | ./__recycle_bin__/__innodb_1064.ibd  |      37748736 | purge/#FP_1557846107_1 |     20971520 |
   +--------+---------------------+--------------------------------------+---------------+------------------------+--------------+

注意事項

1,回收站跨文件系統
若是你的回收站目錄 "__recycle__bin_"_ 和回收的表跨了文件系統，那麼drop table，將會搬遷表空間文件，耗時較長。

2,General tablespace
general tablespace 會存在多個表共享同一個表空間的狀況， 當回收其中一張表的時候，不會搬遷相關的表空間文件，若是master 和 slave 設置的回收保留時間不一樣，那麼就會存在在某一個時間點，主備間的這個general tablespace中的表數量不相等的狀況。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。