AWS re:Postを使用することにより、以下に同意したことになります AWS re:Post 利用規約

Aurora PostgreSQL と互換性のあるインスタンスのローカルストレージに関する問題を解決するにはどうすればよいですか?

所要時間2分
0

Amazon Aurora PostgreSQL 互換エディション DB インスタンスのローカルストレージで問題が発生しています。

簡単な説明

Amazon Aurora のクラスターにある DB インスタンスには、2 種類のストレージがあります。

  • 永続的データに使用されるストレージ (共有クラスターボリューム)。詳細については、クラスターボリュームの内容を参照してください。
  • インスタンスクラスに基づく、クラスター内の各 Aurora インスタンスのローカルストレージ。このストレージサイズはインスタンスクラスにバインドされており、より大きな DB インスタンスクラスに移動することによってのみ変更できます。Aurora PostgreSQL 互換は、エラーログと一時ファイルの保存にローカルストレージを使用します。詳細については、「Aurora PostgreSQL の一時ストレージの制限」を参照してください。

解決方法

FreeLocalStorage の Amazon CloudWatch メトリクスを使用して、Aurora DB インスタンスに関連付けられているローカルストレージスペースをモニタリングできます。このメトリクスは、一時テーブルとログ用に各 DB インスタンスで利用可能なストレージの容量を報告します。詳細については、「Amazon CloudWatch を使用した Amazon Aurora メトリクスのモニタリング」を参照してください 。

Aurora ローカルストレージがいっぱいの場合は、表示されたエラーに応じて以下のトラブルシューティング手順を実行してください。

ローカルストレージの容量が一時テーブルまたは一時ファイルでいっぱいになる

「ERROR: could not write block XXXXXXXX of temporary file: No space left on device.」 (エラー: 一時ファイル XXXXXXXX のブロックを書き込めませんでした: デバイスにスペースが残っていません。)

このエラーは、DB インスタンスの一時ストレージが使い果たされたときに発生します。これには、次のような操作などのさまざまな原因が考えられます。

  • 容量の大きなテーブルを変更する
  • 大きなテーブルにインデックスを追加する
  • 複雑な JOIN、GROUP BY、または ORDER BY 句を含む大規模な SELECT クエリを実行する。

一時テーブルと一時ファイルのサイズを確認する場合には、次の方法を使用します。

1.    一時ファイルの場合は、Aurora PostgreSQL 互換 DB インスタンスの log_temp_files パラメータを有効にします。このパラメータは、指定されたキロバイト数より大きい一時ファイルの使用をログに記録します。このパラメータを有効にすると、ファイルが削除されたときに各一時ファイルのログエントリが作成されます。値 0 を指定すると、すべてのテンポラリファイル情報が記録されます。正の値は指定されたキロバイト数以上のファイルのみをログに記録します。デフォルト値は -1 で、一時ファイルのログ記録を無効にします。このパラメータを使用して一時ファイルの詳細を特定してから、これらの一時ファイルを FreeLocalStorage メトリクスと関連付けます。

注: log_temp_files パラメータを有効にすると、Aurora PostgreSQL 互換 DB インスタンスに過度のログ記録が発生する可能性があります。このため、log_temp_files を有効にする前に Aurora PostgreSQL 互換ログファイルのサイズを確認することがベストプラクティスです。ログファイルがローカルストレージの最大容量を消費している場合は、rds.log_retention の値を減らして容量を解放してください。rds.log_retention のデフォルト値は 3 日です。

次のコマンドの後に実行した差分を使用して、一時ファイルを確認することもできます。

maxiops=> select datname, temp_files , pg_size_pretty(temp_bytes) as temp_file_size  FROM   pg_stat_database order by temp_bytes desc;

注意: temp_files 列では、(並べ替えやハッシュによって) 一時ファイルの作成日時に関係なく、すべての一時ファイルがカウントされます。pg_stat_database のビューの temp_files の列と temp_bytes の列は、累積値の統計を収集しています。この値は pg_stat_reset() 関数を使うか DB インスタンスを再起動することでリセットできます。詳細については、「追加の統計関数」に関する PostgreSQL ドキュメントを参照してください。

Aurora PostgreSQL 互換 10 以降を使用している場合は、Performance Insights を使用して temp_bytes および temp_files をモニタリングできます。これは、PostgreSQL 用の Amazon Relational Database Service (Amazon RDS) にも適用されます。Performance Insights は、待機イベントに加えて、DB エンジンの内部メトリクスの ネイティブカウンターを提供します。詳細については、「Amazon RDS for PostgreSQL のネイティブカウンター」を参照してください。

また、操作を実行しているプロセスにより多くのメモリを割り当てるために、maintenance_work_memwork_mem を増やすこともできます。これにより、操作に使用されるメモリが多くなり、一時的にディスク容量を少なくすることができます。これらのパラメータの詳細については、「maintenance_work_mem およびwork_mem に関する PostgreSQL のドキュメント」を参照してください。メモリ不足にならないように、クエリまたはセッションレベルで maintenance_work_mem および work_mem の値を設定することをお勧めします。詳細については「Amazon Aurora PostgreSQL リファレンス」を参照してください。

2.    一時テーブルの場合は、次のようなクエリを実行します。

maxiops=> SELECT
n.nspname as SchemaName
,c.relname as RelationName
,CASE c.relkind
WHEN 'r' THEN 'table'
WHEN 'v' THEN 'view'
WHEN 'i' THEN 'index'
WHEN 'S' THEN 'sequence'
WHEN 's' THEN 'special'
END as RelationType
,pg_catalog.pg_get_userbyid(c.relowner) as RelationOwner
,pg_size_pretty(pg_relation_size(n.nspname ||'.'|| c.relname)) as RelationSize
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n
    ON n.oid = c.relnamespace
WHERE  c.relkind IN ('r','s')
AND  (n.nspname !~ '^pg_toast' and nspname like 'pg_temp%')
ORDER BY pg_relation_size(n.nspname ||'.'|| c.relname) DESC;

ベストプラクティスは、アプリケーションを注意深くモニタリングし、どのトランザクションが一時テーブルを作成するかを確認することです。これにより、使用可能なローカルストレージ容量の使用状況を管理できます。また、Aurora インスタンスの上位のインスタンスクラスに移行して、インスタンスで利用できるローカルストレージを増やすこともできます。

ログファイルが使用されるローカルストレージ

過度のログ記録は、DB インスタンスのローカルストレージが不足する原因にもなります。ローカルストレージの容量を消費する可能性があるログ記録パラメータのいくつかの例があります。消費は、過剰なログまたはエラーログを長期間保持することが原因である可能性があります。

rds.log_retention_period
auto_explain.log_min_duration
log_connections
log_disconnections
log_lock_waits
log_min_duration_statement
log_statement
log_statement_stats

どのパラメータが過度のログ記録を引き起こしているかを特定するには、PostgreSQL のログを分析して最も大きいログを見つけます。次に、それらのログエントリの大部分に対して責任を負うパラメータがどれかを識別します。その後、過度のログを記録しているパラメータを変更できます。

エラーで失敗するクエリを繰り返し実行している場合、PostgreSQL はデフォルトで PostgreSQL エラーログにエラーを記録します。記録されたエラーを確認してから、失敗したクエリを修正して、ログが過度にストレージを消費しないようにします。また、rds.log_retention (3 日間) のデフォルト値を減らしてエラーログが消費した容量を解放することもできます。

大量のログが必要で、ログファイルが原因で利用可能なローカルストレージをスロットリングしている場合は、上位のインスタンスクラスへの移行を検討してください。つまり、Aurora DB インスタンスには利用可能なローカルストレージの容量が多いということです。


関連情報

Amazon Aurora PostgreSQL を使用したベストプラクティス

AWS公式
AWS公式更新しました 2年前
コメントはありません

関連するコンテンツ