在MySQL中,移动分区目录后仍然可以访问数据

In MySQL, data is still accessible after moving the partition directory

我的分区方案类似于:

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'
);

正如预期的那样,数据被正确地存储到分区和正确的目录中。

问题:

现在,当我 remove/move 来自该位置的目录时,如 mv /my_location/partitions/p0 /some_other_location/ ,目录已成功移动,但数据仍可从 MySQL shell 查询,即使在重新启动 shell.

之后

我的解决方案:

为了让它按预期工作,在移动包含 .ibd 文件的目录后,我必须明确删除分区:

ALTER TABLE my_table DROP PARTITION p0;

这根据需要从方案中删除了分区并清除了数据,通过再次查询相同的数据来验证它。

假设/理解:

我认为 MySQL 正在缓存数据,但不确定确切的位置和原因,这使得即使在分区目录移走后也可以查询。当我关闭并重新打开 shell.

时,肯定缓存不在连接级别

问题:

我预计一旦目录 p0 被移走,数据就会消失。每次移动目录时真的有必要运行删除分区语句吗?

约束:

肯定是p0目录只有在p0分区不再使用时才会被移走。因此将不再需要输入现有 p0 分区

的任何数据

MySQL: 8.0.19

Windows要不要?

你重启mysqld了吗?

mv对Linux(及近亲)真是“改名”。而且,假设目标在同一个文件系统上,重命名甚至可以涉及不同的目录。

当一个程序(例如,mysqld)有一个文件(例如,table分区)“打开”mysqld时,它可以控制它——即使你运行关闭一个shell和rm的文件!

我怀疑当你重新启动 mysqld 时(出于任何原因,包括重新启动),“数据目录”会变得混乱。

除了文件系统的分区之外,您必须在“归档”分区时告诉 MySQL。阅读“transportable tablespaces”你正在使用的版本。这是 5.6 的一篇文章; 5.7 有一些改进。

我看不出使用 文件系统 分区有什么好处。使用“transportable tablespaces”,您可以断开 MySQL 分区与 PARTITIONed table 的连接。这会将分区变成 table。然后 table 可以被删除、重命名、复制等,而不会影响分区的 table。在 http://mysql.rjweb.org/doc.php/partitionmaint 中搜索“transportable”;有一些链接。

正如@Rick James 和@Solarflare 所指出的那样,在 ibd 文件仍处于打开状态时 MySQL 的移动确实表现得很奇怪,并且 table 空格搞砸了。按照他们的指导和 MySQL 文档,这是对我成功的最终方法(可能是正确的方法):

  1. 锁定table

    FLUSH TABLES my_table FOR EXPORT;
    

    这会阻止对所需 table 的任何 update/write 操作,并使 ibd 文件可以安全复制。此外,这会创建一个 .cfg 文件。这些步骤在 MySQL Docs

    中有很好的解释
  2. 一旦 table 被“锁定”,将 .ibd 文件复制到所需位置进行存档。 PS: 暂时不要移动/删除源文件。

    cp -r /my_location/partitions/p0  /some_other_location/
    
  3. 解锁 tables 以便能够更改分区

    UNLOCK TABLES;
    
  4. 安全地删除所需的分区。这也会通知 table 空格。

    ALTER TABLE my_table DROP PARTITION p0;
    

    请注意,此语句会导致删除分区以及与该分区对应的数据。