☰

如何從 MySQL 轉儲計算 AWS RDS 執行個體的大小？

tag-icon • tag-icon amazon-web-services mysql amazon-rds
如何從 MySQL 轉儲計算 AWS RDS 執行個體的大小？

我們正在將一個大型歷史資料庫從 mysqldump 匯入到 RDS 中

gziped sql 檔案為 3GB，未壓縮的 sql 檔案為 18GB。

我們建立了一個 30GB AWS RDS 實例並匯入了檔案...RDS 實例空間不足。

我們建立了一個 50GB AWS RDS 實例，匯入了檔案...RDS 實例空間不足。

如何計算導入此轉儲所需的 AWS RDS 實例的大小？

嘗試預先回答任何問題...

  • 我們無法存取轉儲來源的機器來嘗試以這種方式確定其大小。
  • 我認為可能是 RDS 二進制日誌或慢速日誌佔用了空間，但之前查看實際資料庫大小表明它實際上全部在資料庫中... 
    mysql>  SELECT table_schema "Database Name", sum( data_length + index_length ) / 1024 / 1024 "Database Size in MB"  FROM information_schema.TABLES GROUP BY table_schema ; 
+--------------------+----------------------+
| Database Name      | Database Size in MB  |
+--------------------+----------------------+
| xxxxxxxxxx         |       41658.15374756 |
| information_schema |           0.00976563 |
| mysql              |           5.96341228 |
| performance_schema |           0.00000000 |
+--------------------+----------------------+
4 rows in set (28.39 sec)

答案1

如果不了解正在使用的索引，則無法估計即時資料庫所需的儲存空間。每個索引本質上都是一個映射，映射的「鍵」越多，該映射所需的儲存空間就越多。

如果索引列的資料類型大於 bigint，則索引的基數（資料“形狀”，本質上是唯一“鍵”的數量以及它們如何對應到包含該鍵的行）也變得很重要。對於相同大小的表，具有大量唯一組合（高基數）的varchar(60) 索引列將比具有低基數的索引列佔用更多的存儲空間，因為映射中的鍵比映射中的資料指針佔用更多的儲存空間。

更新：感謝下面的邁克爾，我當然應該說我關於基數和存儲大小的斷言取決於存儲引擎。

例如，一個資料庫有兩個 InnoDB 表，兩個表都有 2176 行 3 列，並且在 VARCHAR(32) 欄位上有一個索引。這兩個表的資料的唯一差異是 tt1 的 VARCHAR 資料列有 2176 個唯一值，而 tt2 的 VARCHAR 資料列有相同的值。

您將看到索引大小僅相差 16kb 左右：

mysql> select TABLE_NAME, TABLE_ROWS, DATA_LENGTH, INDEX_LENGTH from TABLES where TABLE_SCHEMA='t_idb1';
+------------+------------+-------------+--------------+
| TABLE_NAME | TABLE_ROWS | DATA_LENGTH | INDEX_LENGTH |
+------------+------------+-------------+--------------+
| tt1        |       2031 |      180224 |       147456 |
| tt2        |       2031 |      180224 |       131072 |
+------------+------------+-------------+--------------+

請注意，InnoDB 資料儲存有 2 個元件：預設儲存在 mysql 資料目錄中的全域表空間檔案 ibdata1 中的資料字典，以及儲存在資料目錄子目錄中的 .frm 檔案中的資料表資料。

這就是為什麼，Michael，您發現 .frm 檔案的儲存大小沒有差異。如果您使用 innodb_file_per_table=1 指令重新啟動 MySQL，您將看到表格空間檔案中反映了這種差異：

drwx------. 2 mysql mysql   4096 Dec 19 10:52 .
drwxr-xr-x. 4 mysql mysql   4096 Dec 19 10:52 ..
-rw-rw----. 1 mysql mysql     65 Dec 19 10:52 db.opt
-rw-rw----. 1 mysql mysql   8610 Dec 19 10:52 tt1.frm
-rw-rw----. 1 mysql mysql 393216 Dec 19 10:52 tt1.ibd
-rw-rw----. 1 mysql mysql   8610 Dec 19 10:52 tt2.frm
-rw-rw----. 1 mysql mysql 376832 Dec 19 10:52 tt2.ibd

InnoDB儲存的獨特之處在於表格資料實際上是資料字典的索引，為某些操作帶來了一些效能優勢。因此，基數對儲存需求的影響（在本例中約為 10%）與 MyISAM 有很大不同：

mysql> select TABLE_NAME, TABLE_ROWS, DATA_LENGTH, INDEX_LENGTH from TABLES where TABLE_SCHEMA='t_msm';
+------------+------------+-------------+--------------+
| TABLE_NAME | TABLE_ROWS | DATA_LENGTH | INDEX_LENGTH |
+------------+------------+-------------+--------------+
| tt1        |       2126 |       85040 |        87040 |
| tt2        |       2126 |       85040 |         7168 |
+------------+------------+-------------+--------------+

drwx------.  2 mysql mysql  4096 Dec 19 09:50 .
drwxr-xr-x. 13 mysql mysql  4096 Dec 19 10:29 ..
-rw-rw----.  1 mysql mysql    65 Dec 19 09:28 db.opt
-rw-rw----.  1 mysql mysql  8610 Dec 19 09:31 tt1.frm
-rw-rw----.  1 mysql mysql 85040 Dec 19 09:48 tt1.MYD
-rw-rw----.  1 mysql mysql 87040 Dec 19 09:48 tt1.MYI
-rw-rw----.  1 mysql mysql  8610 Dec 19 09:50 tt2.frm
-rw-rw----.  1 mysql mysql 85040 Dec 19 09:51 tt2.MYD
-rw-rw----.  1 mysql mysql  7168 Dec 19 09:51 tt2.MYI

希望這能多解釋一點。

相關內容