著者: 徐文亮
Kesheng DBA メンバーは、テクノロジーに夢中なデータベース エンジニアであり、データベースの日常的な運用と保守を主に担当しています。MySQL、redis、およびその他の一般的なデータベースが得意で、釣り、本を読むこと、風景を見ること、新しい友達を作ることが好きです。
この記事の出典: 元の寄稿
* Aikesheng オープン ソース コミュニティによって作成されたオリジナル コンテンツは、許可なく使用することはできません。編集者に連絡し、転載のソースを示してください。
問題の背景:
しばらく前に、Zabbix インスタンスの history_str テーブルに大量のデータがあり、その結果、ディスク容量の使用率が高くなったという報告がありました.彼は、テーブルをクリーンアップしたいと考え、何か良い提案があるかどうか尋ねました. 最近、関連する知識ポイントを学んだばかりで、学習結果をテストできると思っていましたが、実際のテストの後、最終的に試験に合格し、顧客は非常に満足していたので、この記事を思いつきました.
問題通信:
実際に環境を見て、お客様とコミュニケーションをとることで、以下の情報が得られます。
1. サイトは双方向のマスター/スレーブ レプリケーション アーキテクチャであり、スレーブ ライブラリ read_only は設定されていません。
2. history_str テーブルの ibd データ ファイルが 460G を超えています。
3. history_str テーブルの株式データは直接クリーンアップできます。
4. オンサイト インスタンスが配置されているサーバーは、低構成の仮想マシンです。
したがって、総合的に検討した上で、同じテーブル構造の新しいテーブルを作成し、元のテーブルに対してドロップ操作を実行することをお勧めします.ただし、テーブルのデータ量は比較的大きく、次のリスクを考慮する必要があります.考慮：
1. 大きなテーブルを削除すると、インスタンスがハングし、データベースの通常の使用に影響を与える可能性があります。
2. 大きなテーブルを削除する操作により、マスターとスレーブの遅延が発生します。
3. 大きなファイルを削除すると、ディスク IO の負荷が高くなります。
最終提案:
上記の考察に基づいて、次のスキームが最終的に与えられます。
1. メイン ライブラリで次のコマンドを実行して、同じテーブル構造テーブルを作成し、名前変更操作を実行します。
create table history_str_new like history_str;
rename table history_str to history_str_old, history_str_new to
history_str;
2. マスター ライブラリとスレーブ ライブラリで次の操作を実行して、ハード リンク ファイルを作成します。
ln history_str_old.ibd history_str_old.ibd.hdlk
3. 2 番目のステップが完了したら、1 日または 2 日の間隔で操作を実行し、history_str_old テーブル データを innodb バッファー プールからクールダウンさせてから、マスター データベースとスレーブ データベースでそれぞれ次の操作を実行することをお勧めします。業務の閑散期にまずスレーブデータベースを運用することをお勧めし、メインライブラリで運用する前にスレーブデータベースに問題がないことを確認します。
set sql log bin=0; //临时关闭写操作记录binlog
drop table history_str_old;//执行drop操作
set sql log bin=l; //恢复写操作记录binlog
4. history_old.ibd.hdlk ファイルを削除して空き容量を確保します.これは Linux の truncate コマンドで実現できます. 参照スクリプトは次のとおりです.
#!/bin/bash
##############################################################################
## 第一个参数为需要执行操作的文件的文件名称 ##
## 第二个参数为每次执行操作的缩减值，单位为MB ##
## 第三个参数为每次执行后的睡眠时间，单位为S ##
##############################################################################
fileSize=`du $1|awk -F" " '{print $1}'`
fileName=$1
chunk=$2
sleepTime=$3
chunkSize=$(( chunk * 1024 ))
rotateTime=$(( fileSize / chunkSize ))
declare -a currentSize
echo $rotateTime
function truncate_action()
{
for (( i=0; i<=${rotateTime}; i++ ))
do
if [ $i -eq 0 ];then
echo "开始进行truncate操作，操作文件名为:"$fileName
fi
if [ $i -eq ${rotateTime} ];then
echo "执行truncate操作结束！！！"
fi
truncate -s -${chunk}M $fileName
currentSize=`du -sh $fileName|awk -F" " '{print $1}'`
echo "当前文件大小为: "$currentSize
sleep $sleepTime
done
}
truncate_action
例: sh truncateFile.sh history_str_old.ibd.hdlk 256 1 は、切り捨てサイズが 256M になるたびに history_str_old.ibd.hdlk ファイルを削除することを意味し、スリープ間隔は 1 秒です。
5. この時点で、静かに待ちます。退屈しているなら、人生についても考えることができます。
チップ：
操作方法の問題は以前に解決されていますが、有能な DBA として、操作方法だけでなく、なぜそれを行うのかを理解していないと、Enter キーを押すのは簡単ですが、難しいです。後悔する. 乾いたものが来る、一緒に見つけよう. 次に同様の問題が発生したときにパニックにならないでください。
ヒント1：
MySQL删除表的流程:
1.持有buffer pool mutex。
2.持有buffer pool中的flush list mutex。
3.扫描flush list列表，如果脏页属于drop掉的table，则直接将其从flush list列表中移除。如果开启了AHI,还会遍历LRU,删除innodb表的自适应散列索引项，如果mysql版本在5.5.23之前，则直接删除，对于5.5.23及以后版本，如果占用cpu和mutex时间过长，则释放cpu资源，flush list mutex和buffer pool mutex一段时间，并进行context switch。一段时间后重新持有buffer pool mutex,flush list mutex。
4.释放flush list mutex。
5.释放buffer pool mutex。
ヒント2:
对于linux系统，一个磁盘上的文件可以由多个文件系统的文件引用，且这多个文件完全相同，并指向同一个磁盘上的文件，当删除其中任一一个文件时，并不会删除真实的文件，而是将其被引用的数目减1，只有当被引用数目为0时，才会真正删除文件。
ヒント3:
大表drop或者truncate相关的一些bug:
这两个指出drop table 会做两次 LRU 扫描：一次是从 LRU list 中删除表的数据页，一次是删除表的 AHI 条目。
https://bugs.mysql.com/bug.php?id=51325
https://bugs.mysql.com/bug.php?id=64284
对于分区表，删除多个分区时，删除每个分区都会扫描LRU两次。
https://bugs.mysql.com/bug.php?id=61188
truncate table 会扫描 LRU 来删除 AHI，导致性能下降；8.0 已修复，方法是将 truncate 映射成 drop table + create table
https://bugs.mysql.com/bug.php?id=68184
drop table 扫描 LRU 删除 AHI 导致信号量等待，造成长时间的阻塞
https://bugs.mysql.com/bug.php?id=91977
8.0依旧修复了 truncate table 的问题，但是对于一些查询产生的磁盘临时表（innodb 表），在临时表被删除时，还是会有同样的问题。这个bug在8.0.23中得到修复。
https://bugs.mysql.com/bug.php?id=98869