mysql 라이브러리에서 1TB 양식을 삭제하는 방법

1. 버퍼 풀 버퍼 지우기

테이블 삭제 시 innodb 엔진은 각 버퍼 풀 인스턴스 데이터에 해당하는 테이블을 정리합니다. 페이지 차단, 시스템에 영향을 주지 않기 위해 여기서 지우는 작업은 실제로 flush가 아니라 flush 대기열에서 관련 페이지를 제거합니다. 그러나 제거 프로세스 중에 삭제 프로세스는 각 버퍼 풀의 전역 잠금을 유지한 다음 이 버퍼 풀에서 해당 페이지를 검색하여 플러시 목록 삭제합니다. 버퍼풀에서 검색하고 삭제해야 할 페이지가 너무 많으면 순회 시간이 늘어나 다른 트랜잭션 작업이 차단될 수 있으며, 심한 경우 데이터베이스가 다운될 수 있습니다. 잠겼습니다. drop table时，innodb引擎会清理该表在每个buffer pool实例中中对应的数据块页面，为了避免对系统的影响，这里的清除操作并不是真正的flush，而是将涉及到的页面从flush队列中摘除。但在摘除过程中，删除进程会持有每个buffer pool的全局锁，然后搜索这个buffer pool里对应的页面以便从flush list中删除。如果在buffer pool中需要被搜索并删除的页面过多，那么遍历时间就会增大，这就导致了其他事务操作被阻塞，严重时可导致数据库锁住。

(推荐课程：MySQL教程)

在这里还需要注意一件事情，如果数据库的buffer poolbuffer pool时，还包含清理AHI包含此表的数据，AHI的功能在这里就不多说了，主要是当b+tree的层级变高时，为避免b+tree逐层搜索，AHI能根据某个检索条件，直接查询到对应的数据页，跳过逐层定位的步骤。其次AHI会占用 1/16 的buffer pool的大小，如果线上表数据不是特别大，不是超高并发，不建议将开启AHI，可以考虑关闭AHI功能

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_adaptive_hash_index';
+----------------------------+-------+
| Variable_name                   | Value |
+----------------------------+-------+
| innodb_adaptive_hash_index | ON    |
+----------------------------+-------+
1 row in set (0.01 sec)


mysql> SET GLOBAL innodb_adaptive_hash_index=OFF;
Query OK, 0 rows affected (0.00 sec)


mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_adaptive_hash_index';
+----------------------------+-------+
| Variable_name                   | Value |
+----------------------------+-------+
| innodb_adaptive_hash_index | OFF   |
+----------------------------+-------+
1 row in set (0.01 sec)

2、删除对应的磁盘数据文件ibd

在删除数据文件时，如果数据文件过大，删除过程会产生大量的IO并耗费更多的时间，造成磁盘IO开销飙升,CPU负载过高，影响其他程序运行。我的一个好伙伴，就曾在线上库删除了一张 1TB 大小的表，结果20分钟，数据库无响应，最后库崩溃，重启了。

既然知道drop table做了2件事情，那就针对以上 2 个事情进行优化

在清除Buffer Pool缓冲上，为减少当个buffer pool的大小，可以合理设置innodb_buffer_pool_instances参数，减少buffer pool数据块列表扫描时间，同时关闭AHI功能

在步骤2上，可以巧妙的利用linux的硬连接特性，延迟删除真正的物理文件。

当多个文件名同时指向同一个INODE时,这个INODE的引用数 N>1, 删除其中任何一个文件名都会很快.因为其直接的物理文件块没有被删除.只是删除了一个指针而已;当INODE的引用数 N=1 时, 删除文件需要去把这个文件相关的所有数据块清除,所以会比较耗时;

如果给数据库表的.ibd文件创建一个硬链接，当删除表时，删除物理文件时，其实删除的就是物理文件的一个指针，所以删除操作响应速度会非常快，大约不到1秒左右

下面就来演示一下具体的操作

先创建表文件的硬链接
ln t_test.ibd t_test.ibd.bak
删除表
drop table t_test;

最后就是要真正删除掉物理文件，释放文件所占用的磁盘空间，那么问题来了，如果优雅的删除物理文件呢，在这里推荐大家coreutils工具集中的truncate命令

当然需要你先安装相关的软件包

wget http://ftp.gnu.org/gnu/coreutils/coreutils-8.29.tar.xz


使用非root进行解压
tar -xvJf coreutils-8.29.tar.xz
cd coreutils-8.29
./configure
make
使用root进行make install

安装好之后，就可以写一个脚本，非常优雅的分布删除大文件，${i}G(추천 강좌: MySQL 튜토리얼)

🎜여기서 주의할 점이 하나 더 있습니다. 데이터베이스의 버퍼 풀을 큰 크기로 설정하면 순회가 발생합니다. 길어지는 시간. 버퍼 풀을 정리할 때 이 테이블이 포함된 AHI 데이터도 정리합니다. AHI 기능은 여기서는 주로 사용되지 않습니다. b+tree의 레벨이 높아질 때, b+tree에 대한 레이어별 검색을 피하기 위해 AHI를 직접 쿼리할 수 있습니다. 특정 검색 조건에 따라 해당 데이터 페이지의 경우 레이어별 위치 지정 단계를 건너뜁니다. 둘째, AHI는 버퍼 풀 크기의 1/16을 차지합니다. 온라인 테이블 데이터가 특별히 크지 않고 동시성이 매우 높지 않은 경우 AHI를 활성화하지 않는 것이 좋습니다. AHIFunction🎜

#!/bin/bash


TRUNCATE=/usr/local/bin/truncate
for i in `seq 2194 -10 10 `; 
do 
  sleep 2
  $TRUNCATE -s ${i}G /data/mysql/t_test.ibd.hdlk 
done
rm -rf /data/mysql/t_test.ibd.hdlk ;

🎜2. 해당 디스크 데이터 파일 ibd 삭제🎜🎜데이터 파일 삭제 시 데이터 파일이 너무 크면 삭제 프로세스가 진행됩니다. 많은 양의 IO가 생성되고 시간이 더 많이 소요되어 디스크 IO 오버헤드가 급증하고 CPU 로드가 너무 높아집니다. , 다른 프로그램의 작동에 영향을 미칩니다. 내 좋은 친구가 온라인 데이터베이스에서 1TB 테이블을 삭제한 적이 있습니다. 그 결과 데이터베이스가 20분 동안 응답하지 않게 되었고, 마침내 데이터베이스가 충돌하고 다시 시작되었습니다. 🎜🎜이제 드롭 테이블이 두 가지 일을 한다는 것을 알았으니 위의 두 가지를 최적화해야 합니다🎜🎜버퍼 풀 버퍼를 지울 때 를 줄이기 위해 , >버퍼 풀 크기를 사용하려면 innodb_buffer_pool_instances 매개변수를 합리적으로 설정하여 버퍼 풀 데이터 블록 목록 검색 시간을 줄이고 AHIlinux의 하드 연결 기능을 교묘하게 사용하여 실제 물리적 파일의 삭제를 지연시킬 수 있습니다. 🎜🎜여러 파일 이름이 동시에 동일한 INODE를 가리키는 경우 이 INODE의 참조 번호는 N>1이며 파일 이름 중 하나를 삭제하면 물리적인 파일 블록이 삭제되지 않았기 때문에 매우 빠릅니다. 단지 포인터만 삭제된 것입니다. INODE의 참조 번호가 N=1인 경우 파일을 삭제하려면 모든 데이터를 지워야 합니다. ;🎜🎜데이터베이스 테이블의 .ibd 파일에 하드링크를 생성하면 테이블을 삭제하거나 물리적인 파일을 삭제할 때 파일에서 실제로 삭제되는 것은 실제 파일에 대한 포인터이므로 삭제 작업의 응답 속도는 약 1초 미만으로 매우 빠릅니다🎜🎜구체적인 작업을 시연해 보겠습니다🎜rrreee🎜마지막 단계는 실제로 파일을 삭제하는 것입니다. 문제는 물리적 파일을 정상적으로 삭제하는 경우입니다. 여기서는 coreutils 도구의 truncate 명령을 사용하는 것이 좋습니다. set🎜🎜물론 관련 소프트웨어 패키지를 먼저 설치해야 합니다🎜rrreee🎜설치 후 스크립트를 작성할 수 있습니다. 대용량 파일의 매우 우아한 분산 삭제, ${i}G는 10G가 매번 삭제됨🎜rrreee

위 내용은 mysql 라이브러리에서 1TB 양식을 삭제하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!