web-dev-qa-db-ja.com

Amazon RDSインスタンスで空きディスク領域が徐々に失われる

しばらく前、私のインスタンスを実行しているサーバーには20GBのEBSストレージがありました。その後、ディスクストレージエラーが発生し始めたので、40 GBに増やしました。次に、ストレージ不足エラーが発生したため、再び60GBに増やしました。 （つまり、これは60GB RDSインスタンスです）

Free Storage Space（MB）チャートをご覧ください。撃つたびに、ストレージスペースを追加します。

enter image description here

このクエリを実行すると...

SELECT CONCAT(table_schema, '.', table_name),
       CONCAT(ROUND(table_rows / 1000000, 2), 'M')                                    rows,
       CONCAT(ROUND(data_length / ( 1024 * 1024 * 1024 ), 2), 'G')                    DATA,
       CONCAT(ROUND(index_length / ( 1024 * 1024 * 1024 ), 2), 'G')                   idx,
       CONCAT(ROUND(( data_length + index_length ) / ( 1024 * 1024 * 1024 ), 2), 'G') total_size,
       ROUND(index_length / data_length, 2)                                           idxfrac
FROM   information_schema.TABLES
ORDER  BY data_length + index_length DESC
LIMIT  10;

次の応答を受け取ります...

enter image description here

大量のスペースを占めることで目立つものはありません。

私が実行した場合

select table_schema, CONCAT(ROUND( sum((data_length+index_length)/1024/1024)/1024, 2), 'G') AS MB from information_schema.tables group by 1;

最大のテーブルには約10GBあることがわかります。 （これにはdata_lengthおよびindex_lengthが含まれます）

enter image description here

私の次の考えは、ストレージが遅いのは、general_logまたはディスクへの書き込みが遅いクエリログだと思います...

RDSインスタンスのパラメーターグループを確認すると、ログが無効になっていることがわかります。

enter image description here

私のRDSサーバーがゆっくりとストレージをリークしている理由を誰かが知っていますか？

更新：

#mysqlの親切な人から助けをもらいました

実行した後

show global variables like 'log_bin';

バイナリログが有効になっていることは明らかでした。

次に走った

show binary logsと41674以上のログがありました。

ログを下にスクロールすると、ファイルサイズの1つが2064636であることがわかりました

enter image description here

次に、そのchangelogファイルまでのすべてのバイナリログを削除しようとしました。

purge binary logs to "mysql-bin-changelog.152193"

ただし、RDSはFile_privまたはSuper_privをマスターユーザーに送信します。

これがディスク領域がなくなったところだと思いたいのですが、2064636は約2Mbしかありません。

mysqlamazon-web-servicesstorageamazon-rds
7
Laykes

MySQLで次のコマンドを実行すると、バイナリログの保持期間を確認できます。

mysql> call mysql.rds_show_configuration;

保存期間を1日に設定するには、次のコマンドを使用します。

mysql> call mysql.rds_set_configuration('binlog retention hours', 24);

つまり、MySQL servceは毎日バイナリログを削除します。

その上、バイナリログ、innodb_file_per_tableの設定を確認できると思います。「0」が割り当てられている場合、すべてのデータはibdataファイルに保存されます。

オプションを「1」に割り当てて、テーブルが個別に保存され、使用済みスペースを再利用できるようにすることをお勧めします。

mysql> OPTIMIZE TABLE <table_name>

以下の参照リンクをチェックして、問題が反映されているかどうかを確認してください。
innodb_file_per_tableがONのときにInnoDBでスペースを再利用する方法

MySQLでibdata1ファイルが増え続けるのはなぜですか？

もう1つ、Webサイトによると、トランザクションの実行時間が長いため、ibdata1ファイルが急成長します。できるだけ早くコミットして、システムの復元を実行してスペースを取り戻さないようにしてください。

1
Simon MC. Cheng

失われた空き領域はInnoDBストレージエンジンのテーブルスペースファイルにあると思います。 AWSサポートと話し合った後、すべてのデータをダンプして新しいインスタンスをセットアップし、この新しいインスタンスにインポートすることで新しいインスタンスをセットアップしてから切り替えることを提案しました。この場合、リードレプリカの作成は機能しません。リードレプリカの作成時に、マスターインスタンスと同じストレージが使用されるためです。

このプロセスでは、レプリケーションを手動でセットアップする必要がありました。私はここのガイド（ http://www.ruempler.eu/2014/06/15/external-non-mysql-slaves-with-rds-reloaded/ ）に従い、自動化するスクリプトを作成しましたこのプロセス。あなたはそれを見つけることができます：

https://github.com/cenk/darbe

0
Cenk Alti