在MySQL中，移動分區目錄后數據仍然可以訪問

Question

我的分區方案類似於：

ALTER TABLE my_table
    PARTITION BY RANGE (integer_field) (
    PARTITION p0 VALUES LESS THAN (100) DATA DIRECTORY = '/my_location/partitions/p0'  ,
    PARTITION p1 VALUES LESS THAN (200) DATA DIRECTORY = '/my_location/partitions/p1' ,
    PARTITION p_other VALUES LESS THAN (MAXVALUE) DATA DIRECTORY = '/my_location/partitions/p_other'
);

正如預期的那樣，數據被正確地存儲到分區和正確的目錄中。

問題：

現在，當我從該位置刪除/移動目錄時，例如mv /my_location/partitions/p0 /some_other_location/ ，該目錄已成功移動，但數據仍然可以從 MySQL shell 查詢，即使在重新啟動 shell 之后也是如此。

我的解決方案：

為了讓它按預期工作，在移動包含.ibd文件的目錄后，我必須明確刪除分區：

ALTER TABLE my_table DROP PARTITION p0;

這根據需要從方案中刪除了分區，並清除了數據，通過再次查詢相同的數據來驗證它。

假設/理解：

我認為 MySQL 正在緩存數據，不確定確切的位置和原因，這使其即使在分區目錄移開后也可以查詢。 當我關閉並重新打開外殼時，緩存肯定不在連接級別。

問題：

我預計一旦目錄p0被移開，數據就會消失。 每次移動目錄時真的需要運行drop partition語句嗎？

約束：

只有在不再使用p0分區時，才能確保將p0目錄移走。 所以將不再需要任何數據進入現有的p0分區

MySQL：8.0.19

Answer 1

窗戶與否？

你重啟mysqld了嗎？

Linux（和近親）上的mv確實是“重命名”。 而且，假設目標在同一個文件系統上，重命名甚至可能涉及不同的目錄。

當一個程序（例如， mysqld ）有一個文件（例如，表分區）“打開” mysqld ，它可以控制它——即使你跑到一個 shell 並rm文件！

我懷疑當您重新啟動 mysqld（出於任何原因，包括重新啟動）時，“數據目錄”將變得一團糟。

除了文件系統的分區之外，您必須在“歸檔”分區時告訴 MySQL。 閱讀您正在使用的版本的“可傳輸表空間”。 這是 5.6 的一篇文章； 5.7 有一些改進。

我沒有看到使用文件系統分區的優勢。 使用“可傳輸表空間”，您可以斷開MySQL分區與PARTITIONed表的連接。 這會將分區變成一個表。 然后可以刪除、重命名、復制該表等，而不會影響分區表。 在http://mysql.rjweb.org/doc.php/partitionmaint 中搜索“transportable”； 有一些鏈接。

Answer 2

正如@Rick James 和@Solarflare 所指出的那樣，在ibd文件仍處於打開狀態時移動 MySQL 的行為確實很奇怪，並且表空間被弄亂了。 按照他們的指導和 MySQL 文檔，這是對我成功的最終方法（可能是正確的方法）：

1. 鎖上桌子

   FLUSH TABLES my_table FOR EXPORT;

   這可以防止對所需表進行任何更新/寫入操作，並使ibd文件可以安全地復制。 此外，這會創建一個.cfg文件。 這些步驟在MySQL Docs中有很好的解釋

2. 一旦表被“鎖定”，將.ibd文件復制到所需的存檔位置。 PS：先不要移動/刪除源文件。

    cp -r /my_location/partitions/p0 /some_other_location/

3. 解鎖表以更改分區

   UNLOCK TABLES;

4. 安全地刪除所需的分區。 這也會通知表空間。

    ALTER TABLE my_table DROP PARTITION p0;

   請注意，此語句導致刪除分區，以及與該分區對應的數據。