Wannabe Engineer's Journey

innodb_flush_log_at_trx_commitとinnodb_doublewriteについて

wannabe — Sun, 08 Dec 2024 00:00:00 +0000

MySQLのInnoDBの書き込み速度向上について、innodb_flush_log_at_trx_commitやinnodb_doublewriteの設定を変更する方法が紹介されていることも多いです。

紹介とともに設定変更による危険性について触れられているケースが大半ではありますが、先日、危険性を把握しないまま設定されているケースに遭遇しました。
危険性を説明しようと思った時に、実は自分でもそこまでよく理解していないことに気が付いたので、今回は改めてこれらの動作等についてまとめました。

結論

innodb_flush_log_at_trx_commit
- 本番環境では原則的に1にする
- クラッシュ時にデータが失われても問題がない場合(例えばやり直しがきくデータ移行のインポート時等)は0または2にしても問題ない
innodb_doublewrite
- クラッシュ時にデータが失われても問題がない場合(例えばやり直しがきくデータ移行のインポート時等)は0にしても問題ない
- ファイルシステム側でページのアトミックな更新に対応しているのであれば0にしても問題ない
  - 例えば、ZFSやFusion-io NVMFS
- RDS Optimized Writesを利用しているのであれば0であっても問題ない

データ更新の流れ

パラメータの役割に入る前に、どのような流れでデータが更新されているのかを、データの持ち方から確認していきます。

バッファプール

まず、InnoDBにおいては、データ操作はデータファイルを直接参照するのではなく、必ずデータファイルのデータをメモリ上に持ってきた上で行われます。これは、SELECT、UPDATE、DELETE等の既に存在するデータに対する操作はもちろんのこと、まだデータが存在しないINSERT処理も同様です。

InnoDBは行本体がB-treeインデックスの葉の部分に格納されていますので、INSERT処理の場合、その処理によって書き込まれる予定のページをB-treeインデックスをたどり、そのページ自体をメモリ上に展開し、それに対して書き込みます。

このように、データを保存・操作する際に利用するのが、メモリ上のバッファプールと呼ばれる領域です。

バッファプールとファイルデータの差異

さて、全ての操作がバッファプール上で行われるということは、バッファプールのデータとデータファイルのデータで必ず差異が発生してしまうということです。この、まだデータファイルに永続化が完了しておらず、差異が発生しているページのことをダーティページと呼びます。

ダーティページは、定期的にページクリーナと呼ばれるバックグラウンドプロセスによりデータファイルにフラッシュ(書き込み)されます。フラッシュは、バッファプール上のダーティページの割合がinnodb_max_dirty_pages_pct_lwmで設定したパーセンテージを超えた後に開始されます。

したがって、ダーティページが存在する状況というのは決して珍しいわけではありませんが、この状況でMySQLのプロセスが強制的に停止してしまうと、更新内容が消えてしまうということになります。これでは、コミットされたデータが失われないという「永続性」が担保できません。

この対策として、コミットされたデータが失われないようにする、REDOログという仕組みがInnoDBには存在します。

REDOログとログバッファ

REDOログとは、「どのような更新が行われたか」を保存しておくファイルのことです。ただし、これもバッファプールと同じく、まずはメモリ上にあるログバッファという領域で管理されます。

それではバッファプールと同じで意味がないのではないかと思われますが、ログバッファの内容については、「通常」、トランザクションがコミットされた段階でREDOログにフラッシュされます。したがって、「コミットされたが永続化されていない」というケースは「通常」避けられているということです。

これにより、万が一、ダーティページがある状態で意図せぬプロセス停止が発生したとしても、次回の起動時にREDOログからデータを復元することができます。このデータのリカバリ(クラッシュリカバリ)はMySQL側で自動的に行われます。

innodb_flush_log_at_trx_commit

さて、いよいよ1つ目のパラメータinnodb_flush_log_at_trx_commitについてです。上記でわざわざコミットされた段階でREDOログへフラッシュされる挙動を「通常」と記載したのは、これを設定でそのように動作させないこともできるためです。それがinnodb_flush_log_at_trx_commitです。

通常、この値は1であり、これは「コミット時にはログバッファの内容をフラッシュする」というものです。それでは、パフォーマンスを向上するという文脈で語られる、innodb_flush_log_at_trx_commitを0や2に設定するとどうなるのでしょうか。まとめると、次の通りです。

値	挙動
1	ログバッファはコミット時にフラッシュされる
0	ログバッファは1秒間に1回フラッシュされる
2	ログバッファはコミット後と1秒間に1回フラッシュされる

2は分かりにくいですが、1がコミットが成功した時点でフラッシュされているのに対し、2はコミット後にフラッシュを非同期で試みるため、ラグが発生し得るということです。

innodb_flush_log_at_trx_commit = 0 or 2 の使いどころ

前述の通り、innodb_flush_log_at_trx_commitが0だとIO自体が減り、2だとコミット時のIO待ちがなくなるため、パフォーマンス向上につながります。
これは、データ移行のインポート処理時等に有用です。ここで仮にクラッシュしたとしても、またやり直せばいいからです。例えば、レプリカを手動で作成する際の初期データ移行時に設定して時間を短縮する等が考えられます。

しかしながら、本番環境で1以外を選択する場合、クラッシュした時に「コミットしたのにデータがない」という状況が発生してしまう可能性があるため、本当にそういった挙動で問題ないのかをしっかり考えた上で選択する必要があります。

つまり、「処理が早くなるから」という理由だけで選択するのは極めて危険ということです。

ダブルライト

概要

上記のデータ更新時の流れには記載していないのですが、実は、バッファプールからデータファイルにフラッシュする際は、「通常」、2度に分けて書き込まれます。1回目はダブルライトバッファと呼ばれるファイル上の連続した領域で、その後、データファイルに書き込みます。非常に紛らわしいのですが、バッファと言いつつメモリ上ではなくファイル上の領域です。

では、なぜこのような仕組みがとられているのでしょうか。それは、InnoDBのページサイズがファイルシステム側でアトミックに扱えるサイズを超えていることが多いためです。

InnoDBのデフォルトのページサイズは16KBです。一方でext4やXFSのデフォルトは4KBです。例えば、最初の4KBを書き込んだ後にクラッシュした場合、残り12KBは書き込めていないので、データとして整合性がなく、かつ、リカバリもできません。
これを避け、正常にリカバリできるようにする仕組みがダブルライトです。

不整合を避けられる理由

次の2パターンに分けて不整合を避けられる理由を考えてみます。

ダブルライトバッファに書き込み中にクラッシュ
ダブルライトバッファからデータファイルに書き込み中にクラッシュ

ダブルライトバッファに書き込み中にクラッシュ

この場合、データファイルにはまだ実際に書き込みが行われていません。したがって、データファイルはダーティページをフラッシュする前の段階で整合性を保っており、ダブルライトを利用していたおかげで破損することが避けられました(本来であればこのタイミングで破損してしまうのをダブルライトバッファ側で吸収した)。

また、コミットされたデータはinnodb_flush_log_at_trx_commitが1なのであれば、前述の通り必ずREDOログに存在しています。なので、このREDOログを利用することにより、正常なデータファイルに対してコミット済みのデータを適用することができます。

ダブルライトバッファからデータファイルに書き込み中にクラッシュ

この場合、ダブルライトバッファ上のページは正常です。したがって、単純にダブルライトバッファの内容をデータファイルに改めて書き込めば正常な状態になります。

innodb_doublewrite

さて、ここで表題の2つ目のパラメータinnodb_doublewriteが出てきます。これを0に設定するか、--skip-innodb-doublewriteオプションを指定してMySQLを起動することで、ここまで説明してきたダブルライトを無効にすることができます。

ダブルライトにより2回書き込みが発生すると言っても、ダブルライトバッファはシーケンシャルな領域なので、データファイルへの書き込みより高速であり、2倍の時間がかかるわけではありませんが、2回書き込みが発生するのを1回に抑えることができるため、パフォーマンスは向上します。

しかしながら、ダーティページのフラッシュ中にクラッシュした場合、データファイルが破損してしまうという大きなリスクがあります。

innodb_doublewrite = 0 の使いどころ

まず、innodb_flush_log_at_trx_commitと同じく、データ移行のインポート時には有用です。クラッシュしても再度実行すればいいためです。
また、前述の通り、innodb_doublewriteが必要な理由はファイルシステム側にありました。したがって、ファイルシステム側でアトミックな書き込みが保証できるのであれば、ダブルライトを無効にしても問題ないということです。

例えば、ファイルシステムとしてFusion-io NVMFSやZFSを利用する場合、ダブルライトを無効にしてファイルシステム側にクラッシュ対策を任せてしまうというものです。なお、Fusion-io NVMFSの場合、自動で0になります。

二重書き込みバッファーがアトミック書き込みをサポートする Fusion-io デバイス上にある場合、二重書き込みバッファーは自動的に無効になり、代わりに Fusion-io アトミック書き込みを使用してデータファイル書き込みが実行されます。

innodb_doublewrite

あとは、RDS Optimized Writesを利用する場合です。これは、rds.optimized_writesパラメータを設定することで利用できる機能であり、利用中の場合はinnodb_doublewriteが0になります。

これらのデータベースは、AWS Nitro System を使用する DB インスタンスクラスで実行されます。これらのシステムのハードウェア構成により、データベースは 16 KiB ページを 1 ステップで確実かつ永続的にデータファイルに直接書き込むことができます。AWS Nitro System により RDS Optimized Writes が可能になります。

RDS Optimized Writes for MySQL による書き込みパフォーマンスの向上

REDOログとバイナリログ(binlog)の違い

InnoDBのREDOログと、MySQLのバイナリログは混同しやすいものですので、バイナリログについても記載しておきます。

項目	REDOログ	バイナリログ
スコープ	InnoDB	MySQL全体
用途	クラッシュリカバリ	レプリケーション、PITR
保持内容	物理的変更内容	論理的変更内容
ファイル上書き	される	されない

用途

REDOログは前述の通りクラッシュリカバリに利用することが目的ですが、バイナリログはレプリケーションやPITR(ポイント・イン・タイム・リカバリ)に利用することが目的です。

REDOログはあくまでInnoDB側で出力するInnoDB向けのログであり、MySQL全体の記録にはならないため、レプリケーション等には利用できません。一方で、バイナリログも後述のように論理的な記録に過ぎないので、クラッシュリカバリの観点だと利用できません。

物理的か論理的か

REDOログが「InnoDB」の変更を「物理的に」記録したものであるのに対して、バイナリログは、「MySQL全体」の変更を「論理的に」記録するものです。

物理的な記録というのは、「このページのこの位置はこういうデータからこういうデータになりました」というものです。一方で論理的な記録というのは、「このテーブルはこのデータからこういうデータになりました」というものです。バイナリログ側では物理的なデータファイルを意識しません。

また、バイナリログは出力形式をSTATEMENT、MIXED、ROWから選べますが、STATEMENTの場合は、「このテーブルにはこういうSQLが実行されました」という記録しか行われません。

ファイルが上書きされるかされないか

ファイルが上書きされるかされないかという点も違いがあります。

REDOログはクラッシュリカバリが主目的であるため、データファイルにダーティページが書き込まれた後は、その情報をずっと保持しておく必要はありません。したがって、不要になった情報は上書きしても問題ないため、REDOログファイルは再利用(以前保存した情報が上書き)されます。

一方でバイナリログは再利用されません。expire_logs_daysやbinlog_expire_logs_secondsで設定した期限を超過するか、手動で消されるまで情報が残り続けます。

最後に

パフォーマンス向上の観点で語られることもあるinnodb_flush_log_at_trx_commitやinnodb_doublewriteは特徴を理解した上で設定変更する場合は有用ですが、安易な設定変更はクラッシュ時のデータ損失のリスクがあります。

とりあえず「なんか早くなるらしい」ということで設定されているケースを見かけて改めて感じましたが、私自身も、気が付かないうちにそういうことをやっているのかもしれないなと思いました。

人の振り見て我が振り直せと言いますが、私自身、そういうことがないよう、パラメータを変更する場合は、しっかり変更の意味を考えた上で対応できるようにしたいです。

AWS Certified Data Engineer - Associate(DEA-C01)に合格しました

wannabe — Sun, 28 Apr 2024 00:00:00 +0000

先日、AWS Certified Data Engineer - Associate(AWS 認定データエンジニアアソシエイト)(DEA-C01)に合格しましたので、感想や対策について記載致します。

試験感想

アソシエイトレベルだと思って軽く見ていましたが、深い部分まで問われるような問題もあります。中途半端な知識や、キーワードを知っているだけだと引っ掛かる問題もあります。
また、本当の本当にごく一部ですが、AWS Certified Database - Specialty(AWS 認定データベース – 専門知識)向けに勉強したレベルのものが要求される部分もありました。

したがって、後述する、試験を受ける上で重要そうなサービス等について、しっかり勉強することが合格への近道かと存じます。

また、公式のガイドで下記のようにプログラミングについて言及されていますが、開発に関連する分野の問題(SQL等)も含まれると考えた方がいいかもしれません。

この試験では、コーディングの深い実務経験は必要ありませんが、基本的なプログラミングの概念に精通していると有利です。

なお、AWSの資格として、一番最初にDEAの取得を目指される方はあまりいらっしゃらないかもしれませんが、DEAとSAAならば、先にSAAを取得されることをお勧め致します。全体的なSAAレベルの知識は選択肢の絞り込みに役立ちますし、おそらく、SAAよりDEAの方が難しいです。

スコアとしては1000/1000で合格できましたが、おそらく、分からなかった問題は運よく当たったのと、採点対象外の問題があったのかと存じます。

試験対策

おおよそ、次のような流れで試験対策を実施しました。

インプット
- AWS サービス別資料(BlackBelt)
アウトプット
- Practice Exams | AWS Certified Data Engineer Associate
- AWS Certified Data Engineer Associate Practice Exams DEA-C01

インプット

AWSのサービス概要をインプットする際の資料としては、AWS サービス別資料(BlackBelt)がお勧めです。
やや古い資料もあるため、最近の機能には触れられていない部分もありますが(試験では最近の機能について出ることもあります)、概要を理解するには最適です。

下記に、あくまで執筆時点で個人的に重要そうだと感じた順番で、AWSサービスをリストします。
なお、下記のサービス以外も出題される可能性は十分あります。また、感想でも書きましたが、全体的にSAAレベルの内容は把握しておくと選択肢を絞り込む上で役に立ちます。

深い知識が必要
- Glue
- Redshift
- Athena
- Lake Formation
それなりの知識が必要
- S3
- Step Functions
- Lambda
- DynamoDB
- KMS(Key Management Service)
- Kinesis Data Streams
- Managed Service for Apache Flink(旧Kinesis Data Analytics)
- Data Firehose(旧Kinesis Data Firehose)
- RDS
周辺知識として必要
- SageMaker
- EventBridge
- CloudTrail
- API Gateway
- AppFlow
- Data Exchange
- DMS(Database Migration Service)
- IAM
- VPC
- ElastiCache
- EKS(Elastic Kubernetes Service)
- ECS(Elastic Container Service)
- EC2

アウトプット

試験対策のアウトプットとしてお勧めなのが、Udemyの次の2つの問題集です。解説も丁寧ですし、他の方のレビューもいいので、役立つ問題集かと存じます。

問題文は英語ですが、テキストとしてコピーすることが可能なため、翻訳サービスを利用することもできます。翻訳後の日本語も不自然すぎるようなものはありませんでした。

そっくりそのまま出題されるわけではありませんが、解説を読んで不正解の選択肢がなぜ不正解なのかも含めて理解し、ドキュメントのリンクから周辺知識もインプットすると、試験に非常に役立ちます。

2つの問題集で、各選択肢がなぜ不正解かの理由も含め、正解率95%以上を安定して出せるようになった段階で受験しました。

試験Tips

あまり深くは記載できませんが、受験にあたり、特に意識しておくと役に立つかもしれない項目について記載致します。

Glueは深く問われる覚悟をする
Redshiftの対策ついでにSQLも対策しておく
複数が正解に思える時は最も重視されていることを考える
迷ったらAWSが推してそうなものを選ぶ

Glueは深く問われる覚悟をする

私が甘く見ていただけですが、「アソシエイトなのにそんなことまで聞いてくるの？」とテスト中に画面の前で青ざめてました。
「Glue」と一言で表しても、そこには様々な機能(Data Catalog、Workflows、Studio等)が内包されています。捨て機能はないものと思って対策しておいた方が良いかもしれません。

Redshiftの対策ついでにSQLも対策しておく

Redshiftの対策を行うついでに、ドキュメントでSQLも見ておくと安定するかもしれません。
「基礎的なSQLは知ってるから大丈夫」という方も、ざっと見ておくと実は知らない機能や使い方があるかもしれませんので、確認されるのをお勧め致します。

複数が正解に思える時は最も重視されていることを考える

「技術的にはどちらも可能」という選択肢がある場合は、改めて何が重視されているのかを見ると絞れるケースがあるかもしれません。
特に実務をしていると「安い」「簡単」という選択肢に飛びつきがちですが、実は別のことが問われているかもしれません。

迷ったらAWSが推してそうなものを選ぶ

一種のメタ読みですが、試験対策の問題を解く過程、また、実際に試験を進めていく過程で、おおよそAWSが推したいサービスが見えてくるかと存じます。
したがって、どうしても絞れない時は、どちらのサービスが強く推されているかで選択すると、実は正解というケースもあるかもしれません。

Kinesisエージェントのアップデートについて

wannabe — Fri, 31 Dec 2021 00:00:00 +0000

Kinesisエージェントのアップデートについて、および、脆弱性にも関連するLog4jの利用について記載します。Kinesisエージェント自体に関する記事はKinesis AgentとFirehoseを利用してEC2からS3にログを転送するをご参照ください。

アップデート

次のコマンドにてアップデートを行うことができます。

Amazon Linux系

Amazon Linux系については、通常通りパッケージ名を指定してアップデートが可能です。

# yum update aws-kinesis-agent

その他RHEL系

その他、RHEL系のOSについては、更新先のKinesisエージェントのバージョンが1系か2系かで異なります。特別な事情等がない限り、2系にアップデートすることをお勧め致します。1系から2系にアップデートすることも可能です。

バージョン1系

# yum update https://s3.amazonaws.com/streaming-data-agent/aws-kinesis-agent-latest.amzn1.noarch.rpm

バージョン2系

# yum update https://s3.amazonaws.com/streaming-data-agent/aws-kinesis-agent-latest.amzn2.noarch.rpm

バージョン確認

次のようなコマンドにてバージョン等を含むパッケージの情報を取得することができます。

# rpm -qi aws-kinesis-agent
Name        : aws-kinesis-agent
Version     : 2.0.4
Release     : 1.amzn2
Architecture: noarch
Install Date: Fri 31 Dec 2021 05:21:34 AM UTC
Group       : Applications/Communications
Size        : 25523949
License     : Amazon Software License and Apache 2.0 and MIT
Signature   : (none)
Source RPM  : aws-kinesis-agent-2.0.4-1.amzn2.src.rpm
Build Date  : Wed 15 Dec 2021 03:18:21 AM UTC
Build Host  : build.amazon.com
Relocations : (not relocatable)
Packager    : Amazon Linux
Vendor      : Amazon Linux
URL         : http://aws.amazon.com/
Summary     : Amazon Kinesis Streaming Data Agent
Description :
aws-kinesis-agent is a software service that runs on customer hosts and continuously monitors a set of log files
and sends new data to the Amazon Kinesis Stream service and Amazon Kinesis Firehose service in near-real-time.

アップデート後

基本的に特別な対応は必要ない想定です。私の環境では、Kinesisエージェントの設定内容や、サービスの自動起動設定等も引き継がれたことが確認できました。

念のため、事前に開発環境等にてアップデートが正常に実行できることと、アップデート後もKinesisにデータを転送できていることを確認する程度で問題ないかと存じます。

Log4jについて

KinesisエージェントはLog4jを利用しています。しかしながら、内部的なログ出力に利用しているだけで、外部からの入力値をログ出力するような仕組みではないため、世間を騒がせたApache Log4jの任意のコード実行の脆弱性（CVE-2021-44228）に関する注意喚起の影響は受けない想定です。

また、Amazon Kinesis Agent 1.1.5.1未満を利用している場合は、そもそもLog4jがバージョン1系のものであるため、上記の脆弱性の影響は受けない想定です。

Upgraded log4j dependency to 2.x.

Amazon Kinesis Agent 1.1.5.1

しかしながら、「とにかくアップデートする」という方針もあるかもしれませんので、その場合は上述の方法をご参考にアップデートいただければと存じます。

なお、下記のように、2系にアップデートしても、日本時間2021年12月31日時点では、エージェントは2.0.4で、Log4jは2.16でした。Log4jは2.17以降のバージョンでも脆弱性が見つかっているようなので、~~そちらには対応できていない状況です。~~おそらく、いずれ対応されてパッケージにもされるかとは存じます。
※追記: 日本時間2022年1月11日時点では、エージェントのバージョンが2.0.6で、Log4jについても2.17.1になっていました。

エージェント2.0.4

# ls -1 /usr/share/aws-kinesis-agent/lib
aws-java-sdk-cloudwatch-1.11.700.jar
aws-java-sdk-core-1.11.700.jar
aws-java-sdk-ec2-1.11.700.jar
aws-java-sdk-kinesis-1.11.700.jar
aws-java-sdk-sts-1.11.700.jar
AWSKinesisStreamingDataAgent-1.1.jar
commons-cli-1.2.jar
commons-codec-1.6.jar
commons-lang3-3.4.jar
commons-logging-adapters-1.1.jar
commons-logging-api-1.1.jar
guava-28.2-jre.jar
httpclient-4.5.1.jar
httpclient-cache-4.5.1.jar
httpcore-4.4.3.jar
httpcore-ab-4.4.3.jar
httpcore-nio-4.4.3.jar
httpmime-4.5.1.jar
jackson-annotations-2.10.3.jar
jackson-core-2.10.3.jar
jackson-databind-2.10.5.1.jar
jackson-dataformat-cbor-2.10.3.jar
jackson-dataformat-xml-2.10.3.jar
jcommander-1.48.jar
joda-time-2.8.2.jar
jsr305-3.0.1.jar
log4j-1.2-api-2.16.0.jar
log4j-api-2.16.0.jar
log4j-core-2.16.0.jar
log4j-slf4j-impl-2.16.0.jar
slf4j-api-1.7.12.jar
sqlite-jdbc-3.20.1.jar

エージェント2.0.6

# rpm -qi aws-kinesis-agent
Name        : aws-kinesis-agent
Version     : 2.0.6
Release     : 1.amzn2
Architecture: noarch
Install Date: Tue 11 Jan 2022 10:16:31 AM UTC
Group       : Applications/Communications
Size        : 25568570
License     : Amazon Software License and Apache 2.0 and MIT
Signature   : (none)
Source RPM  : aws-kinesis-agent-2.0.6-1.amzn2.src.rpm
Build Date  : Fri 07 Jan 2022 05:44:46 PM UTC
Build Host  : build.amazon.com
Relocations : (not relocatable)
Packager    : Amazon Linux
Vendor      : Amazon Linux
URL         : http://aws.amazon.com/
Summary     : Amazon Kinesis Streaming Data Agent
Description :
aws-kinesis-agent is a software service that runs on customer hosts and continuously monitors a set of log files
and sends new data to the Amazon Kinesis Stream service and Amazon Kinesis Firehose service in near-real-time.

# ls -1 /usr/share/aws-kinesis-agent/lib
aws-java-sdk-cloudwatch-1.11.700.jar
aws-java-sdk-core-1.11.700.jar
aws-java-sdk-ec2-1.11.700.jar
aws-java-sdk-kinesis-1.11.700.jar
aws-java-sdk-sts-1.11.700.jar
AWSKinesisStreamingDataAgent-1.1.jar
commons-cli-1.2.jar
commons-codec-1.6.jar
commons-lang3-3.4.jar
commons-logging-adapters-1.1.jar
commons-logging-api-1.1.jar
guava-29.0-jre.jar
httpclient-4.5.13.jar
httpclient-cache-4.5.1.jar
httpcore-4.4.3.jar
httpcore-ab-4.4.3.jar
httpcore-nio-4.4.3.jar
httpmime-4.5.1.jar
jackson-annotations-2.10.3.jar
jackson-core-2.10.3.jar
jackson-databind-2.10.5.1.jar
jackson-dataformat-cbor-2.10.3.jar
jackson-dataformat-xml-2.10.3.jar
jcommander-1.48.jar
joda-time-2.8.2.jar
jsr305-3.0.1.jar
log4j-1.2-api-2.17.1.jar
log4j-api-2.17.1.jar
log4j-core-2.17.1.jar
log4j-slf4j-impl-2.17.1.jar
slf4j-api-1.7.12.jar
sqlite-jdbc-3.20.1.jar

max_wal_sendersの調整に関するRDSイベントについて

wannabe — Sat, 27 Nov 2021 00:00:00 +0000

RDS for PostgreSQLを利用時にThe parameter max_wal_senders was set to a value incompatible with replication. It has been adjusted from xx to yy.というRDSイベントが発生する件についてです。

結論

結論としましては次のとおりです。

パラメータrds.logical_replicationを有効(1)に設定し、インスタンスの再起動を行った際に発生することがある
インスタンスの稼働に影響がなく無視しても良いRDSイベント(執筆時点)
- ※フォーラムレベル、AWSサポートレベルで確認
max_wal_sendersの値をadjusted from xx to yyの調整値yyに指定すれば出力されなくなる

rds.logical_replicationについて

当該パラメータはRDSでロジカルレプリケーションを行う際に指定するパラメータです。デフォルトは無効(0)です。

パラメータ名からも察しがつきますが、RDS独自のパラメータです。通常のPostgreSQLのwal_levelに相当するもので、有効(1)に設定するとwal_levelもlogicalに変更されます。
※RDSではwal_levelパラメータを変更することができないため、その代替のようなものです。

したがって、特にロジカルレプリケーションを実施されていない場合は、無効(0)にしてしまっても問題ございません。

検証

実際にRDS for PostgreSQL 13を利用して確認してみました。

rds.logical_replication = 0

rds.logical_replicationが0の時の再起動時のRDSイベントです。再起動が行われても特に何も出力されないことが確認できます。

November 26, 2021, 10:26:36 PM UTC DB instance shutdown
November 26, 2021, 10:26:51 PM UTC  DB instance restarted

rds.logical_replication = 1

rds.logical_replicationを1に変更して再起動を行った際のRDSイベントです。再起動に伴い、「The parameter max_wal_senders was set to a value incompatible with replication. It has been adjusted from 20 to 25.」というイベントが出力されていることが分かります。

November 26, 2021, 10:34:53 PM UTC Finished updating DB parameter group
November 26, 2021, 10:35:21 PM UTC  DB instance shutdown
November 26, 2021, 10:35:24 PM UTC  The parameter max_wal_senders was set to a value incompatible with replication. It has been adjusted from 20 to 25.
November 26, 2021, 10:35:37 PM UTC  DB instance restarted

rds.logical_replication = 1 and max_wal_senders = 調整値

rds.logical_replicationを1に設定している状態で、max_wal_sendersの値を調整後の25に変更した場合です。再起動時のメッセージが出力されていないことが確認できます。

November 26, 2021, 10:47:22 PM UTC Finished updating DB parameter group
November 26, 2021, 10:47:58 PM UTC  DB instance shutdown
November 26, 2021, 10:48:14 PM UTC  DB instance restarted

しかしながら、特に有害というわけでもございませんので、無理して値を変更する必要もないかと存じます。

フォーラム情報

なお、フォーラムにも本件に関連する情報がございましたので、ご参考までに共有致します。

原因についての言及はございませんが、既知の事象である点と、影響はない点の記載がございます。AWSサポートに確認した内容とも意味的な相違はございませんので、正しい情報かと存じます。

Message: "The parameter max_wal_senders was set to a value incompatible with replication. It has been adjusted from 10 to 15.","

Please be assured the above message is a known message when an RDS instance is restarted, this event is harmless and has no performance impact on the instance. Kindly note that the internal team is aware of this event occurrence and is working on rolling out a fix.

Hence, currently, there is no requirement of setting up the above parameter and you can safely ignore this Warning message until the internal team rolls out a fix at the backend.

Unfortunately, I do not have a valid ETA for when the fix will be rolled out by internal team, however please be assured that this message is harmless and it's level is "Warning" and no action is required from your end.

max_wal_senders invalid setting

Pythonでgzipファイルを解凍する

wannabe — Sun, 31 Oct 2021 00:00:00 +0000

Pythonでgzipファイルを解凍する方法について記載します。gzip圧縮されたログファイル等を扱う際に利用できるかもしれません。

はじめに

gzipファイルを扱う際は共通してgzipを利用しています。標準ライブラリです。
また、今回はPython 3.7を利用して動作確認を行っています。マイナーバージョンが違っても、3系なら動くとは思います。

ファイルに解凍する

gzipファイルを解凍した結果をファイルとして扱いたいケースです。例えば、ファイルのアップロードを行いたい場合や、他処理のインプットがファイル形式の場合等が考えられます。

shutil.copyfileobj()

shutil.copyfileobj()を利用して、読み込んだgzipのファイルオブジェクトを別ファイルとしてコピーする方法です。個人的には一番好きな手法です。

サンプル

import gzip
import shutil

source_file = "file.txt.gz"
target_file = "file.txt"

with gzip.open(source_file, mode="rb") as gzip_file:
    with open(target_file, mode="wb") as decompressed_file:
        shutil.copyfileobj(gzip_file, decompressed_file)

write()

write()を利用して、読み込んだファイルオブジェクトを別ファイルに書き込む方法です。別の情報も併せて書き込みたい時等には役立つかもしれません。

サンプル

import gzip

source_file = "file.txt.gz"
target_file = "file.txt"

with gzip.open(source_file, mode="rb") as gzip_file:
    content = gzip_file.read()
    with open(target_file, mode="wb") as decompressed_file:
        decompressed_file.write(content)

subprocess

subprocessを利用して、OSコマンドから解凍する方法です。自分で実装するより、OSコマンドを利用する方が安心できるという時には良いかもしれません。

サンプル

import subprocess

source_file = "file.txt.gz"

command = ["gunzip", source_file]
subprocess.run(
    command,
    stdout=subprocess.PIPE,
    stderr=subprocess.STDOUT
)

sh

shを利用して、OSコマンドから解凍する方法です。なお、shは標準ライブラリではないので、別途インストールする必要があります(pipで可能です)。全体の記述行を少しでも減らしたい場合には良いかもしれません。

サンプル

from sh import gunzip

source_file = "file.txt.gz"

gunzip(source_file)

中身を直接読み込む

gzipファイルの中身を直接読み込むケースです。単純にファイルの情報が必要なだけで、解凍されたファイルが欲しいわけではないといった状況が考えられます。

モードでtを指定することでテキストとして、bを指定することでバイナリとして読み込むことができます。

元ファイル

$ cat <<'_EOF_' > file.txt
春は花
夏ほととぎす
秋は月
冬雪さえて
すずしかりけり
_EOF_
$ gzip file.txt

テキストモード

str型で取得することができます。なお、open時にencodingのオプションを利用することで、エンコードモードを指定することもできます。

サンプル

>>> import gzip
>>> 
>>> source_file = "file.txt.gz"
>>> 
>>> with gzip.open(source_file, mode="rt") as gzip_file:
...     content = gzip_file.read()
...     type(content)
...     print(content)
... 
<class 'str'>
春は花
夏ほととぎす
秋は月
冬雪さえて
すずしかりけり

>>>

バイナリモード

bytes型で取得することができます。今回のサンプルでは文字列をデコードして再表示していますが、もちろん、そのままbytes型で扱うこともできます。

サンプル

>>> import gzip
>>> 
>>> source_file = "file.txt.gz"
>>> 
>>> with gzip.open(source_file, mode="rb") as gzip_file:
...     content = gzip_file.read()
...     type(content)
...     print(content)
...     print(content.decode())
... 
<class 'bytes'>
b'\xe6\x98\xa5\xe3\x81\xaf\xe8\x8a\xb1\n\xe5\xa4\x8f\xe3\x81\xbb\xe3\x81\xa8\xe3\x81\xa8\xe3\x81\x8e\xe3\x81\x99\n\xe7\xa7\x8b\xe3\x81\xaf\xe6\x9c\x88\n\xe5\x86\xac\xe9\x9b\xaa\xe3\x81\x95\xe3\x81\x88\xe3\x81\xa6\n\xe3\x81\x99\xe3\x81\x9a\xe3\x81\x97\xe3\x81\x8b\xe3\x82\x8a\xe3\x81\x91\xe3\x82\x8a\n'
春は花
夏ほととぎす
秋は月
冬雪さえて
すずしかりけり

>>>

RDSのリストア・マルチAZ化時にはパフォーマンス低下に注意する

wannabe — Sat, 25 Sep 2021 00:00:00 +0000

構成変更や障害対応で、RDSをスナップショットからリストアしたり、マルチAZ化したりすることもあるかもしれません。その際、パフォーマンスが低下することがあります。本記事では、その点について記載致します。

まとめ

RDSをスナップショットからリストアしたり、マルチAZ化してから、全ブロックにIOが発生するまでの間は、IOパフォーマンスが著しく低下する可能性があります。

これは、全てのストレージブロックがリストア時に物理的にロードされるわけではないためです。初回アクセス時には、S3からブロックをロードするというオーバーヘッドが発生する可能性があります。

パフォーマンスが元に戻らなければサービスが再開できないような場合は、テーブル全件走査等でブロックにIOを発生させ、S3からのロードを完了させるという手順を踏む必要があります。

また、本記事で詳細は記載しませんが、リストア後はキャッシュが空白となっているため、データがキャッシュの乗り切るまでパフォーマンスが低下することもあります。

なお、Auroraについては、その他のRDSと根本的にアーキテクチャが異なるものになっているため、本記事で記載しているような問題は発生しません。

RDSのスナップショットリストア

RDSのストレージ領域

まず、RDSは、各インスタンスがそれぞれストレージ領域として独立したEBSを利用する構成となっています(※)。これはマルチAZ構成にした場合のスタンバイ側も同じです。
※Auroraは、データのストレージについてはクラスタ内部のインスタンス間で共有しているため、個別に保有している領域としてはログや一時ファイルに利用する領域のみです。

したがって、RDSのスナップショットを取得する機能は、RDSが利用しているEBSのスナップショットを取得することと意味合い的には同じとなります。

MySQL、MariaDB、PostgreSQL、Oracle、および Microsoft SQL Server 用の Amazon RDS の DB インスタンスは、データベースおよびログのストレージに Amazon Elastic Block Store (Amazon EBS) ボリュームを使用します。

Amazon RDS DB インスタンスストレージ

EBSスナップショットのリストア

「EBSスナップショットのリストア」という文言になると思い当たる方もいらっしゃるかもしれませんが、リストアは全てのストレージブロックをロードするものではありません。実際には、ストレージブロックの初回アクセス時にS3から対象がロードされるような仕組みとなります。

当然、この初回アクセス時には、S3からのロードという比較的コストの高いオーバーヘッドが発生するため、通常のIOよりもパフォーマンスが低下します。

これが、RDSをスナップショットからリストアした際にパフォーマンスが低下する大きな原因の1つです(その他、キャッシュやAZ変更等の要因もあり得ますが)。

スナップショットから作成されたボリュームの場合、アクセスする前に、ストレージブロックが Amazon S3 からプルダウンされてボリュームに書き込こまれる必要があります。この事前処理には一定の時間がかかるため、各ブロックへの初回アクセス時には、I/O 操作のレイテンシーが著しく増加する可能性があります。ボリュームのパフォーマンスは、すべてのブロックがダウンロードされてボリュームに書き込まれると正常値に達します。

Amazon EBS ボリュームの初期化

マルチAZ構成

また、RDSのマルチAZ構成は、プライマリ側のスナップショットを作成し、そのスナップショットを別のAZにリストアすることで実現します。つまり、ここでも「EBSスナップショットのリストア」が発生します。

マルチAZ構成の場合、プライマリとスタンバイのレプリケーションは「同期」方式となるため、スタンバイ側のIOパフォーマンスが低下すると、プライマリ側のパフォーマンスもあわせて低下します。

これが、マルチAZ構成に変更した直後のパフォーマンス低下の大きな原因の1つです(もちろん、AZ間通信等のオーバーヘッドもあるため、一般的にシングルAZ構成よりもパフォーマンスは低下します)。

DB インスタンスでマルチ AZ を有効にするため、RDS はプライマリ DB インスタンスの EBS ボリュームのスナップショットを取得し、新しく作成されたスタンバイレプリカに復元してから、両方のボリュームを同期します。既存の EBS スナップショットを基に作成された新しいボリュームは、バックグラウンドで時間をかけて読み込まれます。この機能を使用すると、スナップショットから大量のボリュームをすばやく復元できますが、変更中および変更完了後にレイテンシーが高くなる可能性があります。

DB インスタンスをマルチ AZ 配置にする

スナップショットリストア後のパフォーマンス改善

通常インスタンス

スナップショットからリストアした通常のインスタンスの場合(マルチAZ構成のスタンバイインスタンスでない場合)、ユーザはデータベースにログインすることが可能です。

したがって、SELECT * FROM {table_name};等のSQLにより、全件走査を行うことで、ストレージブロックをS3からロードすることができます。

クイックアクセスが必要なテーブルに対する遅延ロードの影響を軽減するには、SELECT * など、テーブル全体をスキャンするようなオペレーションを実行します。これにより、Amazon RDS はバックアップされたテーブルデータをすべて S3 からダウンロードできます。

DB スナップショットからの復元

Oracleの場合は、DBMS_STATS.GATHER_SCHEMA_STATSやANALYZE(現在は非推奨)等を利用して統計情報を取得することでIOを発生させることもできます。
※経験則的に、なぜかDBMS_STATS.GATHER_SCHEMA_STATSだとパフォーマンスが改善しないこともありましたが、効率的なIOのため、全件走査に至らなかったのかもしれません。

PostgreSQLの場合は、VACUUM FREEZE ANALYZE等でIOを発生させることもできます。
※FREEZEを付けないと効率的なIOが選択され、全件走査に至らない可能性があります。

スタンバイインスタンス

通常インスタンスと異なりユーザはログインすることができません。したがって、考えられる対応としては次のようなものに限られます。

フェイルオーバーを伴う再起動を行い、プライマリに昇格させて、全件走査を行う
プライマリ側でデータを全件削除後、再度挿入を行う

対応自体に手間と時間を要するので、おとなしくパフォーマンスが改善するまで待つ方が現実的かもしれません。

最後に

知っていれば当たり前のことではありますが、スナップショットからのリストアやマルチAZ化は手軽であるがために、リストア後のパフォーマンス低下については考慮されていないケースも見かけます。

経験上、リストア直後の処理に通常の3倍以上の時間を要したこともありますので、リストアやマルチAZ化を行う際は、バッチ処理等の時間が延びることも考えた上で、計画を立てた方が良いかもしれません。

FargateからgsutilがCaught exception reading instance dataで実行できない事象について

wannabe — Sat, 28 Aug 2021 00:00:00 +0000

Fargateタスクからgsutilコマンドを実行し、S3にアクセスする際、Caught exception reading instance dataというエラーが出て、認証に失敗する事象についてです。

結論

gsutilコマンドの仕様です(執筆時点)
タスクロールではなく環境変数でAWSの認証情報を指定することで対応可能です
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY
- AWS_DEFAULT_REGION

以下、詳細です。

事象詳細

S3に対する適切な権限を付与しているIAMロールをFargateタスクのタスクロールに指定している状態にも関わらず、gsutilコマンドを利用してS3にアクセスすると、下記のようなエラーが発生するといった事象です。

権限設定、シンタックス等に間違いはないため、例えば、EC2上で同じことを行った場合は処理が正常に完了します。つまり、Fargateタスクで実行する際に特有の事象です。

エラー

ERROR 0904 05:23:14.152952 utils.py] Caught exception reading instance data
Traceback (most recent call last):
  File "/usr/lib/python3.7/urllib/request.py", line 1324, in do_open
    encode_chunked=req.has_header('Transfer-encoding'))
  File "/usr/lib/python3.7/http/client.py", line 1244, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.7/http/client.py", line 1290, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.7/http/client.py", line 1239, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.7/http/client.py", line 1026, in _send_output
    self.send(msg)
  File "/usr/lib/python3.7/http/client.py", line 966, in send
    self.connect()
  File "/usr/lib/python3.7/http/client.py", line 938, in connect
    (self.host,self.port), self.timeout, self.source_address)
  File "/usr/lib/python3.7/socket.py", line 727, in create_connection
    raise err
  File "/usr/lib/python3.7/socket.py", line 716, in create_connection
    sock.connect(sa)
OSError: [Errno 22] Invalid argument
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/usr/lib/google-cloud-sdk/platform/gsutil/gslib/vendored/boto/boto/utils.py", line 220, in retry_url
    r = opener.open(req, timeout=timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 525, in open
    response = self._open(req, data)
  File "/usr/lib/python3.7/urllib/request.py", line 543, in _open
    '_open', req)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 1352, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/usr/lib/python3.7/urllib/request.py", line 1326, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno 22] Invalid argument>
ERROR 0904 05:23:14.154281 utils.py] Unable to read instance data, giving up
Caught non-retryable exception while listing s3://XXXXX/YYYYY/ZZZZZ/: No handler was ready to authenticate. 1 handlers were checked. ['S3HmacAuthV4Handler'] Check your credentials
CommandException: Caught non-retryable exception - aborting rsync

原因

gsutilコマンドの仕様です(執筆時点)。

下記のように関連Issuesがあります。初回報告が2016年で、現在オープン中のものは2020年に報告されたものなので、対応としては優先順位が低いものと想定されます。したがって、修正されるまで待つというよりも、後述の対応を行った方がよろしいかと存じます。

対応

環境変数を利用する

AWS Fargate Task - Caught exception reading instance dataにも記載がありますが、AWSの認証情報をIAMロールではなく環境変数で指定することで対応可能です。

なお、上記Issueに記載された環境変数ではなく、AWS CLI を設定する環境変数に記載のある次の3つの環境変数を指定することでも動作することが確認できました。つまり、上記のIssueに記載のあるAWS_SECURITY_TOKENは明示的に指定していません。

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_DEFAULT_REGION

また、上記のIssueではFargateタスクのコンテナ内部でコマンドを実行することで対応を行っていますが、Fargateはパラメータストアに保存した機密情報を簡単に環境変数に指定する機能があります。

好みの問題かもしれませんが、自前で実装するよりも簡単なので、次のページを参照してパラメータストアから情報を渡す構成をお勧め致します。

参考
- Amazon ECS タスクで秘密情報や機密情報をコンテナに安全に渡す方法を教えてください。

ローカルストレージを利用する

gsutilコマンドでS3にアクセスするということは、GCSとS3間でファイルを連携するといった実装を行っているものと思われます。

セキュリティポリシー的にAWS側でキーの発行ができないといったような場合、一時的にローカルストレージにファイルをダウンロードするといった方式も考えられます。

例: GCS→ローカル→S3 or S3→ローカル→GCS

その場合、ファイルが200 GiB未満ならば、ローカルストレージ上で対応可能です。

デフォルトでは、プラットフォームバージョン 1.4.0 以降を使用して Fargate でホストされる Amazon ECS タスクは、後に最低 20 GiB のエフェメラルストレージを受け取ります。エフェメラルストレージの総量は、タスク定義で ephemeralStorage パラメータを指定することで、最大 200 GiB まで増やすことができます。

Fargate タスクストレージ

ファイルが200 GiB以上の場合は、次のようにEFSをFargateにマウントし、その領域を利用するといった方法が考えられます。

参考
- Fargate で実行されている Amazon ECS コンテナまたはタスクに Amazon EFS ファイルシステムをマウントする方法を教えてください。

GlueからS3のParquetに対してUpsertを行う

wannabe — Sun, 25 Jul 2021 00:00:00 +0000

GlueからS3のParquetファイルに対してUpsert(データが存在すればInsert、存在しなければUpdate)処理を行う方法について記載します。

ParquetファイルをGlueテーブルとしている場合、実質的にGlueテーブルのUpsert処理を行うことが可能です。

まとめ

大きく分けて次の3パターンでUpsertを実装することができます。

実際のデータを利用したパフォーマンステスト等を実施し、チューニングを経て実行時間の制約を満たすことが可能なパターンを利用するのがよろしいかと存じます。

なお、全て主キー相当の列が存在しないと実装できないことにご注意いただければと存じます。

【PySpark】更新ごとに増分する列を利用する(※1)
【PySpark】差分となる主キーを利用する
【AWS Data Wrangler】merge_upsert_tableを利用する(※2)

※1 例えば「最終更新日時」等の、更新ごとに増分するような列が存在しない場合は利用できない手法です。

※2 AWS Data Wranglerは内部的にPandasが利用されているため、Glue JobがCommand Failed with Exit Code 10.で失敗するで紹介した事象が発生する可能性があります。少量のデータに向いています。

以下、詳細です。

サンプルデータ

サンプルとして次のような「元データ」と「差分データ」を利用します。処理の結果、最終的に「想定データ」のようになることを目指します。

元データ

主キーはid列を想定しています。last_updated列には最終更新のタイムスタンプが付与される想定です。

+---+------------+-------------------+
| id|     message|       last_updated|
+---+------------+-------------------+
|  1|Not Updated.|2021-07-24 00:00:00|
|  2|Not Updated.|2021-07-24 00:00:00|
|  3|Not Updated.|2021-07-24 00:00:00|
|  4|Not Updated.|2021-07-24 00:00:00|
|  5|Not Updated.|2021-07-24 00:00:00|
+---+------------+-------------------+

差分データ

idが1および4のデータについては、last_updatedおよびmessageが更新されています。

また、元データに存在しない6および7のデータが存在しています。

+---+------------+-------------------+
| id|     message|       last_updated|
+---+------------+-------------------+
|  1|    Updated.|2021-07-25 00:00:00|
|  4|    Updated.|2021-07-25 00:00:00|
|  6|Not Updated.|2021-07-25 00:00:00|
|  7|Not Updated.|2021-07-25 00:00:00|
+---+------------+-------------------+

想定データ

元データに存在しているidの1と4については更新が行われ、存在していない6と7については挿入が行われることを想定します。

+---+------------+-------------------+
| id|     message|       last_updated|
+---+------------+-------------------+
|  1|    Updated.|2021-07-25 00:00:00|
|  2|Not Updated.|2021-07-24 00:00:00|
|  3|Not Updated.|2021-07-24 00:00:00|
|  4|    Updated.|2021-07-25 00:00:00|
|  5|Not Updated.|2021-07-24 00:00:00|
|  6|Not Updated.|2021-07-25 00:00:00|
|  7|Not Updated.|2021-07-25 00:00:00|
+---+------------+-------------------+

【PySpark】更新ごとに増分する列値を利用する

PySpark上で結合を行い、主キーが重複している行は、増分する列値を利用して古い方を削除するというものです。大きく次のような流れにて対応します。

S3から元データを読み込む
S3から差分データを読み込む
元データと差分データを結合する
結合したデータを主キーと値が増分する列でソートする
主キーが同じ行が存在する場合は古い行を削除する
S3に新規ファイルとして書き込む
新規で書き込んだファイルを読み取る
既存の元データに上書きする

なお、残念ながらoverwriteを利用し、直接既存の元データを上書きすることはできませんでした。

と言いますのも、当該メソッドを利用すると、まず、書き込み先に存在するファイルが削除され、その後、書き込み処理が行われるためです。書き込みデータは既存ファイルのデータから読み取りを行って作成されるものなので、書き込みタイミングで削除されていると処理に失敗してしまいます。

したがって、いったん別ファイルとして保存し、その内容から元のデータが存在する場所に上書きで書き込む形としています。

例

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from pyspark.sql import SQLContext
from awsglue.context import GlueContext
from awsglue.job import Job
from pyspark.sql.functions import row_number
from pyspark.sql.window import *
from pyspark.sql.functions import col
from pyspark.sql.functions import desc

args = getResolvedOptions(sys.argv, ["JOB_NAME"])

sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
sqlContext = SQLContext(spark.sparkContext, spark)
job = Job(glueContext)
job.init(args["JOB_NAME"], args)

# S3から元データを読み込む
base = spark.read.parquet("s3://xxxxx/base/")
## base.sort("id").show()
## +---+------------+-------------------+
## | id|     message|       last_updated|
## +---+------------+-------------------+
## |  1|Not Updated.|2021-07-24 00:00:00|
## |  2|Not Updated.|2021-07-24 00:00:00|
## |  3|Not Updated.|2021-07-24 00:00:00|
## |  4|Not Updated.|2021-07-24 00:00:00|
## |  5|Not Updated.|2021-07-24 00:00:00|
## +---+------------+-------------------+

# S3から差分データを読み込む
delta = spark.read.parquet("s3://xxxxx/delta/")
## delta.sort("id").show()
## +---+------------+-------------------+
## | id|     message|       last_updated|
## +---+------------+-------------------+
## |  1|    Updated.|2021-07-25 00:00:00|
## |  4|    Updated.|2021-07-25 00:00:00|
## |  6|Not Updated.|2021-07-25 00:00:00|
## |  7|Not Updated.|2021-07-25 00:00:00|
## +---+------------+-------------------+

# 元データと差分データを結合する
upsert = base.union(delta)
## upsert.sort("id").show()
## +---+------------+-------------------+
## | id|     message|       last_updated|
## +---+------------+-------------------+
## |  1|Not Updated.|2021-07-24 00:00:00|
## |  1|    Updated.|2021-07-25 00:00:00|
## |  2|Not Updated.|2021-07-24 00:00:00|
## |  3|Not Updated.|2021-07-24 00:00:00|
## |  4|    Updated.|2021-07-25 00:00:00|
## |  4|Not Updated.|2021-07-24 00:00:00|
## |  5|Not Updated.|2021-07-24 00:00:00|
## |  6|Not Updated.|2021-07-25 00:00:00|
## |  7|Not Updated.|2021-07-25 00:00:00|
## +---+------------+-------------------+

# 結合したデータを主キーと値が増分する列でソートする
upsert = upsert.withColumn("row_num", row_number().over(Window.partitionBy("id").orderBy(desc("last_updated"))))
## upsert.show()
## +---+------------+-------------------+-------+
## | id|     message|       last_updated|row_num|
## +---+------------+-------------------+-------+
## |  1|    Updated.|2021-07-25 00:00:00|      1|
## |  1|Not Updated.|2021-07-24 00:00:00|      2|
## |  6|Not Updated.|2021-07-25 00:00:00|      1|
## |  3|Not Updated.|2021-07-24 00:00:00|      1|
## |  5|Not Updated.|2021-07-24 00:00:00|      1|
## |  4|    Updated.|2021-07-25 00:00:00|      1|
## |  4|Not Updated.|2021-07-24 00:00:00|      2|
## |  7|Not Updated.|2021-07-25 00:00:00|      1|
## |  2|Not Updated.|2021-07-24 00:00:00|      1|
## +---+------------+-------------------+-------+

# 主キーが同じ行が存在する場合は古い行を削除する
upsert = upsert.filter(col("row_num") == 1).drop(col("row_num"))
## upsert.sort("id").show()
## +---+------------+-------------------+
## | id|     message|       last_updated|
## +---+------------+-------------------+
## |  1|    Updated.|2021-07-25 00:00:00|
## |  2|Not Updated.|2021-07-24 00:00:00|
## |  3|Not Updated.|2021-07-24 00:00:00|
## |  4|    Updated.|2021-07-25 00:00:00|
## |  5|Not Updated.|2021-07-24 00:00:00|
## |  6|Not Updated.|2021-07-25 00:00:00|
## |  7|Not Updated.|2021-07-25 00:00:00|
## +---+------------+-------------------+

# ※Upsertの一連の処理をまとめることも可能(下記のようになる)
# upsert = base.union(delta).withColumn("row_num", row_number().over(Window.partitionBy("id").orderBy(desc("last_updated")))).filter(col("row_num") == 1).drop(col("row_num"))

# S3に新規ファイルとして書き込む
upsert.write.mode("overwrite").parquet("s3://xxxxx/tmp/")

# 新規で書き込んだファイルを読み取る
upsert = spark.read.parquet("s3://xxxxx/tmp/")

# 既存の元データに上書きする
upsert.write.mode("overwrite").parquet("s3://xxxxx/base/")

job.commit()

【PySpark】差分となる主キーを利用する

PySpark上で差分対象の主キーを抽出し、既存データから当該主キーを持つ行を削除したDataFrameに、差分対象を結合するというものです。大きく次のような流れにて対応します。

S3から元データを読み込む
S3から差分データを読み込む
差分データから主キーを読み込む
元データから差分データに存在する主キーを削除した一時的なデータを作成する
一時的なデータと差分データを結合する
S3に新規ファイルとして書き込む
新規で書き込んだファイルを読み取る
既存の元データに上書きする

この手法は、更新ごとに増加するような列がない場合でも対応できる点がメリットです。

例

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from pyspark.sql import SQLContext
from awsglue.context import GlueContext
from awsglue.job import Job

args = getResolvedOptions(sys.argv, ["JOB_NAME"])

sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
sqlContext = SQLContext(spark.sparkContext, spark)
job = Job(glueContext)
job.init(args["JOB_NAME"], args)

# S3から元データを読み込む
base = spark.read.parquet("s3://xxxxx/base/")
## base.sort("id").show()
## +---+------------+-------------------+
## | id|     message|       last_updated|
## +---+------------+-------------------+
## |  1|Not Updated.|2021-07-24 00:00:00|
## |  2|Not Updated.|2021-07-24 00:00:00|
## |  3|Not Updated.|2021-07-24 00:00:00|
## |  4|Not Updated.|2021-07-24 00:00:00|
## |  5|Not Updated.|2021-07-24 00:00:00|
## +---+------------+-------------------+

# S3から差分データを読み込む
delta = spark.read.parquet("s3://xxxxx/delta/")
## delta.sort("id").show()
## +---+------------+-------------------+
## | id|     message|       last_updated|
## +---+------------+-------------------+
## |  1|    Updated.|2021-07-25 00:00:00|
## |  4|    Updated.|2021-07-25 00:00:00|
## |  6|Not Updated.|2021-07-25 00:00:00|
## |  7|Not Updated.|2021-07-25 00:00:00|
## +---+------------+-------------------+

# 差分データから主キーを読み込む
delta_primary_keys = delta.select("id").rdd.flatMap(lambda x: x).collect()
## delta_primary_keys
## [1, 4, 6, 7]

# 元データから差分データに存在する主キーを削除した一時的なデータを作成する
upsert = base.filter(~base["id"].isin(delta_primary_keys))
## upsert.show()
## +---+------------+-------------------+
## | id|     message|       last_updated|
## +---+------------+-------------------+
## |  2|Not Updated.|2021-07-24 00:00:00|
## |  3|Not Updated.|2021-07-24 00:00:00|
## |  5|Not Updated.|2021-07-24 00:00:00|
## +---+------------+-------------------+

# 一時的なデータと差分データを結合する
upsert = upsert.unionAll(delta)
## upsert.sort("id").show()
## +---+------------+-------------------+
## | id|     message|       last_updated|
## +---+------------+-------------------+
## |  1|    Updated.|2021-07-25 00:00:00|
## |  2|Not Updated.|2021-07-24 00:00:00|
## |  3|Not Updated.|2021-07-24 00:00:00|
## |  4|    Updated.|2021-07-25 00:00:00|
## |  5|Not Updated.|2021-07-24 00:00:00|
## |  6|Not Updated.|2021-07-25 00:00:00|
## |  7|Not Updated.|2021-07-25 00:00:00|
## +---+------------+-------------------+

# S3に新規ファイルとして書き込む
upsert.write.mode("overwrite").parquet("s3://xxxxx/tmp/")

# 新規で書き込んだファイルを読み取る
upsert = spark.read.parquet("s3://xxxxx/tmp/")

# 既存の元データに上書きする
upsert.write.mode("overwrite").parquet("s3://xxxxx/base/")

job.commit()

【AWS Data Wrangler】merge_upsert_tableを利用する

AWS Data Wranglerを利用し、Glueテーブルに紐づくS3ファイルを直接Upsertするというものです。

AWS Data Wranglerは、下記のようにGlueのジョブパラメータに値を入れるだけでGlueジョブから利用することが可能です。

Key: --additional-python-modules

Value: pyarrow==2,awswrangler

Install — AWS Data Wrangler 2.10.0 documentation

大きく次のような流れにて対応します。

S3から差分データを読み込む
PandasのDataFrameに変換する
merge_upsert_tableメソッドを呼び出す

なお、冒頭にも記載していますが、当該メソッドはPandasを利用するため、たとえ対象が分割可能なファイルであっても、1つのノードのメモリ上に全てのデータが乗り切らないと処理できません。

したがって、大きなデータでの当該機能の利用は向いていません。小さなデータであれば、非常に実装もシンプルで良いものかと存じます。

例

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from pyspark.sql import SQLContext
from awsglue.context import GlueContext
from awsglue.job import Job
import awswrangler as wr
import pandas as pd

args = getResolvedOptions(sys.argv, ["JOB_NAME"])

sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
sqlContext = SQLContext(spark.sparkContext, spark)
job = Job(glueContext)
job.init(args["JOB_NAME"], args)

# S3から差分データを読み込む
delta = spark.read.parquet("s3://xxxxx/delta/")
## delta.sort("id").show()
## +---+------------+-------------------+
## | id|     message|       last_updated|
## +---+------------+-------------------+
## |  1|    Updated.|2021-07-25 00:00:00|
## |  4|    Updated.|2021-07-25 00:00:00|
## |  6|Not Updated.|2021-07-25 00:00:00|
## |  7|Not Updated.|2021-07-25 00:00:00|
## +---+------------+-------------------+

# PandasのDataFrameに変換する
delta = delta.toPandas()

# merge_upsert_tableメソッドを呼び出す
wr.s3.merge_upsert_table(delta_df=delta, database="<database>", table="<table>", primary_key=["id"])

job.commit()

最後に

ParquetのUpsertを実施したいケースはそれなりにあると思うので、そういったメソッドが既に存在していると思いましたが、執筆時点では確認することができませんでした。

そのため、回りくどい実装方法となっていますが、少しでもご参考になれば幸いです。

読み取り専用のレプリカ側でロック待ちが発生する事象について

wannabe — Sun, 20 Jun 2021 00:00:00 +0000

PostgreSQLでレプリケーションを行っている際、読み取り専用トランザクションにも関わらず、レプリカ側でロック待ちが発生(still waiting for AccessShareLock)してしまう事象についてです。状況次第では、レプリカ側でデッドロックも発生(deadlock detected)します。

事象

レプリカ側で次のようなロック待ちが発生します。

2021-06-20 00:43:39 UTC:xx.xx.xx.xx(55558):postgres@dev:[10485]:LOG: process 10485 still waiting for AccessShareLock on relation 143563 of database 139288 after 1000.096 ms
2021-06-20 00:43:39 UTC:xx.xx.xx.xx(55558):postgres@dev:[10485]:DETAIL: Process holding the lock: 1550. Wait queue: 10485.

状況によっては、デッドロックも発生します。

2021-06-20 00:45:23 UTC:xx.xx.xx.xx(36128):postgres@dev:[22035]:LOG:  process 22035 detected deadlock while waiting for AccessShareLock on relation 143563 of database 139288 after 1000.048 ms at character 61
2021-06-20 00:45:23 UTC:xx.xx.xx.xx(36128):postgres@dev:[22035]:DETAIL:  Process holding the lock: 26223. Wait queue: 13967, 28211, 9113.
2021-06-20 00:45:23 UTC:xx.xx.xx.xx(36128):postgres@dev:[22035]:STATEMENT:  <SQL>
2021-06-20 00:45:23 UTC:xx.xx.xx.xx(36128):postgres@dev:[22035]:ERROR:  deadlock detected at character 61
2021-06-20 00:45:23 UTC:xx.xx.xx.xx(36128):postgres@dev:[22035]:DETAIL:  Process 22035 waits for AccessShareLock on relation 143563 of database 139288; blocked by process 26223.
        Process 26223 waits for AccessExclusiveLock on relation 143563 of database 139288; blocked by process 22035.
        Process 22035: <SQL>
        Process 26223: <backend information not available>
2021-06-20 00:45:23 UTC:xx.xx.xx.xx(36128):postgres@dev:[22035]:HINT:  See server log for query details.
2021-06-20 00:45:23 UTC:xx.xx.xx.xx(36128):postgres@dev:[22035]:STATEMENT:  <SQL>

レプリカ側は読み取り専用トランザクションであるため、本来、このようなロック待ちやデッドロックが発生する操作をユーザ側で行うことはできません。それにも関わらず、レプリカ側でロック関係の問題が発生してしまうという事象です。

まとめ

当該事象についてのまとめです。

ACCESS EXCLUSIVEロックがプライマリ側で取得されている可能性がある
PostgreSQLやアプリケーション側のログから事象発生時に実行されていた操作を特定する
自動バキュームが原因の場合は格納パラメータの変更や更新頻度の削減を検討する
自動バキュームが原因でない場合はアプリケーション設定やレプリカ側でのロックタイムアウト導入を検討する

以下、詳細です。

原因

SELECT文が取得するACCESS SHAREロックと競合し得るACCESS EXCLUSIVEロックを取得する操作がプライマリ側で発生している可能性が高いものと考えられます。

ACCESS EXCLUSIVEロックのみが、SELECT（FOR UPDATE/SHAREなし）文をブロックします。

13.3. 明示的ロック

ACCESS EXCLUSIVEロックは次のような操作で発生し得ます。

DDL(一部除く)
VACUUM FUL
VACUUM(特殊なケース)

ACCESS EXCLUSIVEロックについて

多くのDDLやVACUUM FULLがACCESS EXCLUSIVEロックを取得する件については、一般的にも知られているケースかと存じます。具体的には次のような種類のコマンドです。

DROP TABLE、TRUNCATE、REINDEX、CLUSTER、VACUUM FULL、（CONCURRENTLYなしの）REFRESH MATERIALIZED VIEWコマンドによって獲得されます。 ALTER INDEXとALTER TABLEの多くの形式もこのレベルでロックを獲得します。これはまた、明示的にモードを指定しないLOCK TABLE文のデフォルトのロックモードです。

13.3. 明示的ロック

しかしながら、通常のVACCUMも状況によっては取得するという部分につきましては、意外に感じられる方もいらっしゃるかもしれません。

次のように、VACUUM(VACUUM FULLを除く)はACCESS SHAREロックと競合しないSHARE UPDATE EXCLUSIVEロックを取得し、一般的に競合は発生しないというのが良く知られている挙動であるためです。

VACUUMの標準形式は実運用のデータベースに対する操作と同時に実行させることができます。（SELECT、INSERT、UPDATE、DELETEなどのコマンドは通常通りに動作し続けます。

24.1. 定常的なバキューム作業

また、自動バキュームを利用している場合、ロックが競合した際には相手に処理を譲る(自動VACUUM側が中断される)というのも、良く知られている挙動かと存じます。

自動バキュームワーカは通常は他のコマンドをブロックしません。自動バキュームが保持するSHARE UPDATE EXCLUSIVEロックと衝突するロックを、プロセスが獲得しようとした場合には、ロックの獲得により自動バキュームが中断されます。

24.1. 定常的なバキューム作業

しかしながら、実は「テーブルの末尾に空のページが存在している」状態で、なおかつ、「テーブルの排他ロックを容易に獲得可能」という特殊な場合においては、通常のバキューム(自動バキュームを含む)でも排他ロックが取得されることがあります。これは盲点となり得る部分かと存じます。

標準形式のVACUUMは、テーブルとインデックス内の不要な行を削除し、その領域を将来の再利用が可能であるものとして記録します。しかし、その領域をオペレーティングシステムに返却することはありません。例外として、テーブルの末尾に完全に空のページが存在し、かつそのテーブルの排他ロックが容易に獲得できるような特殊な場合には、その領域を返却します。

24.1. 定常的なバキューム作業

調査

レプリカ側

ロックを取得しているプロセスがバックグラウンドプロセスであることを確認します。ちなみに、Auroraだとaurora wal replay processが対象のプロセスです。
また、ロック待ちが発生している「時間帯」と「テーブル」も確認します。

具体的には、下記のようなロック待ちのログ出力から、ロックを要求しているプロセスを特定します。下記の例で言うところのProcess holding the lock: 1550の1550が、ACCESS EXCLUSIVEを保持しているプロセスIDです。

2021-06-20 00:43:39 UTC:xx.xx.xx.xx(55558):postgres@dev:[10485]:DETAIL: Process holding the lock: 1550. Wait queue: 10485.

プロセスIDが確認できましたら、OSコマンド、RDSやAuroraの場合は拡張メトリクス、あるいは、pg_stat_activity等から該当のプロセスがバックグラウンドプロセスであることを確認します。

プライマリ側

レプリカ側で事象が確認できた「時間帯」「テーブル」の情報をベースに、「プライマリ側でACCESS EXCLUSIVEロックを取得した操作を特定すること」が第一方針となるかと存じます。

PostgreSQLログ

ログに出力されたSQL文や自動バキュームから、当該時間帯にプライマリ側でACCESS EXCLUSIVEロックを取得する操作が実行されていないかを確認します。

log_statementを有効にしている場合、設定レベルに応じてユーザによる操作が記録されているため、当該時間帯のSQLを確認することができます。

また、log_autovacuum_min_durationを指定している場合、この値よりも長い時間を要した自動バキュームについてはログ出力されます。0にすることで全ての自動バキュームが出力されます。

RDSやAuroraの場合、rds.force_autovacuum_logging_levelもdisabled以外の値に設定する必要があります。

なお、上記に挙げたパラメータは動的パラメータです。事象発生時点で有益な情報を取得可能な設定になっていなくとも、事象再現時に備えて再起動なしで設定を反映することができます。

その他

アプリケーション側の実行ログ等から、当該時間帯にプライマリ側でACCESS EXCLUSIVEロックを取得する操作が実行されていないかを確認します。

また、関係者に当該時間帯の操作について確認するのも手段の一つです。

対応

プライマリ側でACCESS EXCLUSIVEロックを取得した操作を特定できたら、次のように対応します。

自動バキュームだった場合

原因がテーブルに対する自動バキュームだった場合、次のような対応が考えられます。

【PostgreSQL 12以降】テーブルの格納パラメータvacuum_truncateをfalseにする
テーブルの格納パラメータautovacuum_enabledをfalseにする
テーブルに対する更新処理量を減らす

【PostgreSQL 12以降】当該テーブルの格納パラメータvacuum_truncateをfalseにする

残念ながらPostgreSQL 12以降にしか対応していませんが、vacuum_truncateをfalseにすることで、VACUUMによりACCESS EXCLUSIVEロックが取得されるページ末尾の空ページ切り捨て操作を無効にできます。

これによりACCESS EXCLUSIVEロックは取得されないようになりますが、OSにページ末尾の空ページ領域を返さなくなるため、基本的にストレージ容量に余裕がある場合の設定となります。

バキュームがテーブル末尾の空ページの切り捨てを試みることを、有効または無効にします。デフォルト値はtrueです。 trueの場合、VACUUMと自動バキュームは切り捨てを行い切り捨てられたページのディスク領域はオペレーティングシステムに返されます。切り捨てにはテーブルにACCESS EXCLUSIVEロックが必要であることに注意してください。

vacuum_truncate

alter table <schema>.<table> set (vacuum_truncate = false, toast.vacuum_truncate = false);

テーブルの格納パラメータautovacuum_enabledをfalseにする

autovacuum_enabledをfaseにすることで、対象のテーブルに対する自動バキュームを無効にすることができます。

ただし、自動バキュームを無効にすることで、テーブルが肥大化し、結果として大幅なパフォーマンス低下に繋がる可能性があるため、定期的に手動でVACUUMを実行されることをお勧め致します。

また、MaximumUsedTransactionIDsについてにも記載がありますが、自動バキュームを無効にしていても、autovacuum_freeze_max_ageに達した場合は強制的にバキュームされます。不要域が多い程、強制バキューム時の負荷が高くなる可能性があるため、注意が必要です。

alter table <schema>.<table> set (autovacuum_enabled = false, toast.autovacuum_enabled = false);

テーブルに対する更新処理量を減らす

当該テーブルに対する更新処理を減らすことで自動バキュームの発生頻度も減らすことができるため、結果として事象発生の頻度も下がります。

例えば、毎回、全件DELETE→INSERTを行っていたり、全件UPDATE→INSERTを行っていたりするような場合、ロジックを変更することで自動バキュームの頻度を下げることができます。

ただし、あくまでも頻度を減らせるだけなので、タイミング次第ではロック待ちの事象は再現します。

自動バキュームでなかった場合

原因が自動バキュームではなく、その他の操作(アプリケーション側の処理等)だった場合、目的の処理を行う際に、ACCESS EXCLUSIVEロックを取得する操作が必要なのかを確認します。

ACCESS EXCLUSIVEロックを伴う操作が必要ない場合(余分にロックをかけていた場合)は、それを改めることでロック待ちの事象を改善することができます。

ACCESS EXCLUSIVEロックを伴う操作が必要な場合は、レプリカ側に接続するクライアントでlock_timeoutを設定することで、延々とロックを待ち続けるような挙動を避けることができます。結果として、全体のスループットが上昇することが予測されます。

テーブル、インデックス、行、またはその他のデータベースオブジェクトに対してロック獲得を試みている最中、指定された時間を超えて待機するいかなる命令も停止されます。時間制限はそれぞれのロック取得の試みに対し個別に適用されます。制限は明示的ロック要求（例えばLOCK TABLE、またはSELECT FOR UPDATE without NOWAITなど）および暗黙的に取得されるロックに適用されます。この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。値ゼロ（デフォルト）はこの機能を無効にします。

lock_timeout

Glue Jobが`Command Failed with Exit Code 10.`で失敗する

wannabe — Sun, 02 May 2021 00:00:00 +0000

扱うデータ量を増やすとGlue JobがCommand Failed with Exit Code 10.で失敗する事象に遭遇したため内容を記載致します。

まとめ

Glue Jobワーカー1つのメモリ上に乗り切らないデータを処理している可能性がある
データをメモリに読み込む部分の実装をSparkに変更することで改善される可能性がある

以下、詳細です。

原因

Glue Jobワーカー1つのメモリ上に乗り切らないデータを処理している可能性があります。

特に、次のような事象に合致している場合は、メモリに乗り切らないデータを処理している可能性が高いです。

扱うデータ量を減らすと改善する
Sparkイベントログ(※1)が出力されていない
glue.XX.jvm.heap.usage(※2)が上昇していない

※1 モニタリングオプションのSpark UIを有効化するとS3に出力されるファイルのことを指します。

Spark UI を有効にすると、 AWS Glue ETL ジョブと、 AWS Glue 開発エンドポイントの Spark アプリケーションの Spark イベントログを Amazon Simple Storage Service (Amazon S3) の指定個所に保持できます。

AWS Glue ジョブ用の Apache Spark ウェブ UI の有効化

※2 GlueのCloudWatchメトリクスのことを指します。

Amazon CloudWatch を使用して AWS Glue をモニタリングすることで、AWS Glue から raw データを収集し、リアルタイムに近い読み取り可能なメトリクスに加工することができます。これらの統計は 2 週間記録されるため、履歴情報にアクセスしてウェブアプリケーションまたはサービスの動作をより的確に把握することができます。デフォルトでは、AWS Glue メトリクスデータは CloudWatch に自動的に送信されます。

Amazon CloudWatch によるモニタリング

対応

メモリにデータを読み込んでいる処理の具体的な実装を確認し、それがSparkでの実装でない場合は、Sparkに書き換えることで改善する可能性があります。

1つのワーカーのメモリに乗り切らない場合でも、Sparkはデータを分割して複数のワーカー扱うことができるためです。

私が当該の問題に直面したケースではAWS Data Wrangler(Pandasの拡張ライブラリ)を利用していました。ライブラリのメソッドが内部的にPandasでS3のParquetファイルを全て読み込むような実装をしていたため、1つのワーカーに乗り切らずに失敗していた形です。

AWS Data Wrangler(Pandas)での実装をやめて、当該処理をSparkによる処理に変更したところ、改善しました。

なお、Glueのワーカー1つに乗り切らないことで発生していたため、単純にワーカー数を倍々で増やしていっても解決しませんでした。

備考

恐らく、本記事と同じ原因のため、つまり、1つのワーカーのメモリ上にデータが乗り切らないため失敗しているケースがフォーラムで報告されています。

Hello,

I have a .sql.gz file (~50gb) on S3 - I'm attempting to download it, unzip it, and upload the decompressed contents back to S3 (as .sql).

The Glue job is able to successfully decompress/upload smaller files (largest I've tested is ~1gb).

However, whenever I attempt to process the larger ~50gb file I get back the following error:

"Command failed with exit code 10"

Glue job failing with exit code 10 (unable to decompress ~50gb file on S3)

執筆時点で明確な答えは出ていませんが、フォーラム投稿者の下記コードを見る限り、BytesIO部分でインメモリの実装をしているため発生しているものと推察致します。

import boto3
from io import BytesIO
import gzip
 
s3_bucket_name = 'some-bucket'
stage_s3_key_prefix = 'prefix/to/stage'
source_s3_key = f'{stage_s3_key_prefix}/somefile.sql.gz'
target_s3_key = f'{stage_s3_key_prefix}/somefile.sql'
 
s3_client = boto3.client('s3')
s3_client.upload_fileobj(
    Fileobj=gzip.GzipFile( 
        None,
        'rb',
        fileobj=BytesIO(
            s3_client.get_object(
                Bucket=s3_bucket_name,
                Key=source_s3_key
             // line below should be: body.read()
             // I cant index Body b/c this markdown will display a URL instead
            ).read()
        )
    ),
    Bucket=s3_bucket_name, 
    Key=target_s3_key 
)

BytesIO はインメモリーのバイナリストリームです

io --- ストリームを扱うコアツール

また、今回の記事とは別の原因とはなりますが、同じPythonライブラリを2回インポートした結果、同じようなエラーとなると言ったような報告もあります。

On my Glue job, I got this error when I imported the same external python library twice. Removing the duplicate library from the job parameter 'Python lib path' worked for me and the job runs now.

Glue job failing with exit code 10 (unable to decompress ~50gb file on S3)

こういった事象を鑑みると、データがメモリに乗り切らない場合や、何らかの理由でGlue Jobを開始できなかった際に、当該エラーが出るのかもしれません。

メッセージから原因の推察を行うのが難しいエラーですが、少しでもご参考になれば幸いです。

AWS 認定データベース – 専門知識(DBS-C01)に合格しました

wannabe — Sat, 03 Apr 2021 00:00:00 +0000

先日、AWS 認定データベース – 専門知識(AWS Certified Database - Specialty)(DBS-C01)に合格しましたので、感想や試験対策について記載致します。

試験感想

思っていたよりも深い部分まで問われるような問題が多かったように感じます。後述する「深い知識が必要」なサービス等について、曖昧な部分を少なくすることが合格への近道かと考えられます。
スコアとしましては900/1000点にて合格致しましたが、体感としましても、1割程度は「決め手になる知識が曖昧なため選択肢を絞り込めない」ような問題が出ました。
なお、下記のように「データベーステクノロジー分野における最低 5 年間の経験」が推奨されていますが、現時点では、一般的なデータベースに関する知識を直接問われるというよりも、それをベースにしたAWSサービスの利用が主軸となっている印象でした。

認定によって検証される能力

AWS データベースサービスの各主要機能と、それぞれの違いを理解する

AWS のサービスを使うデータベースソリューションを、適切に提案および設計するための、必要事項と要件を分析する

推奨される知識と経験

データベーステクノロジー分野における最低 5 年間の経験

AWS を使う実践的な業務における、最低 2 年間の経験

オンプレミスと AWS クラウドベースでの、リレーショナルおよび非リレーショナルデータベース業務に関する経験と専門知識

AWS 認定データベース – 専門知識

試験対策

おおよそ、次のような流れで試験対策を実施しました。

サービスの概要をつかむ
- AWS サービス別資料(BlackBelt)
試験対策(インプット)
- ~~Ultimate AWS Certified Database Specialty~~ (資格廃止につきUdemy削除)
試験対策(アウトプット)
- ~~Practice Exam | AWS Certified Database Specialty~~ (資格廃止につきUdemy削除)
- ~~AWS Certified Database Specialty Practice Exams~~ (資格廃止につきUdemy削除)

サービスの概要をつかむ

AWSのサービス概要を把握する際に非常に有益なのがAWS サービス別資料(BlackBelt)です。
実際の試験対策に進む前に、主として次のようなサービスの概要を、まずは、ざっくりとでも把握された方が分かりやすくなるかと存じます(※あくまで執筆時点で個人的に重要そうだと感じた順番です)。
なお、下記サービス以外にも出題される可能性がありますし、記載がなくとも、全体的にSAAレベルの基本的な内容は把握しておいた方が、問題文を把握する上で役立つと思われます。

深い知識が必要
- Aurora
- RDS
- DynamoDB
- DMS(Database Migration Service)
ある程度の知識が必要
- ElastiCache
- Redshift
- KMS(Key Management Service)
- CloudFormation
- DocumentDB
- Neptune
周辺知識として必要
- IAM(Identity and Access Management)
- Direct Connect
- Site-to-Site VPN
- Systems Manager
- CloudWatch
- VPC
- S3
- Snowball
- Lambda
- Timestream

試験対策(インプット)

※資格廃止に伴いUdemy講座は削除されました。

試験対策のインプットとして非常にお勧めなのが、Udemyの[Ultimate AWS Certified Database Specialty]です。AWS ヒーローの一人であるStephane Maarekさんも講師として登場します。
~~試験対策としての要点が非常に良くまとまっており、このコースで扱われる内容を把握していれば、高得点での合格に繋がるものと存じます。~~
~~なお、章ごとのクイズは実際の試験よりも非常に易しいため、あくまでも知識の整理という観点で解いた方がよろしいかと存じます。~~
コンテンツは英語ですが、動画に自動生成字幕(英語)を表示することもできるため、リスニングが苦手な場合でも視聴は可能です。字幕は自動生成なので少し誤りもありますが、意味は掴めるレベルです。
実際に試験を受けてみて、コースの内容として、ほぼ試験に関係のないものは扱われていないとの印象を受けたため、全て試験に出る可能性があるものとして視聴いただいても問題ないものと個人的に思います。

試験対策(アウトプット)

※資格廃止に伴いUdemy講座は削除されました。

~~試験対策のアウトプットとしてお勧めなのが、次の2つの問題集です。~~

~~Practice Exam | AWS Certified Database Specialty~~
~~AWS Certified Database Specialty Practice Exams~~

~~問題文は英語ですが、英語が読めなくとも、テキストとしてコピーすることが可能なため、容易に翻訳サービスを利用することもできます。~~
~~そっくりそのまま出題されるわけではありませんが、不正解の選択肢がなぜ不正解なのかも含めて理解することで、試験に非常に役立ちます。~~
~~私は2つの問題集で正解率96%～100%程度を安定して出せるようになった段階で受験しました。~~

試験Tips

あまり深くは言及できませんが、受験にあたり、特に意識しておくと役に立つかもしれない項目について記載致します。

AuroraとRDSの違いを意識する
Auroraの機能ごとの制約を意識する
データベースエンジンごとの違いを意識する
冗長化機能の違いを意識する
グローバル展開機能の違いを意識する
複数が正解に見える時は最も重視されていることを考える

AuroraとRDSの違いを意識する

「AuroraにできてRDSにできない」「この機能はAuroraだとこうなるがRDSだとこうなる」等のパターンを把握しておくと良いかもしれません。例えば前者はバックトラックやレプリカの自動フェイルオーバー、後者はマルチAZ構成時の同期方式等です。

Auroraの機能ごとの制約を意識する

Auroraは色々な機能を利用できますが、それぞれで細かな制約があります。例えば、サーバレス、グローバルデータベース、バックトラック等がありますが、それぞれの制約も意識しておくと良いかもしれません。

データベースエンジンごとの違いを意識する

採用されているデータベースエンジンごとの差異についても把握しておくと良いかもしれません。例えば、リードレプリカの多段階生成可否、TDEの利用可否、IAM認証の利用可否等です。

冗長化機能の違いを意識する

マルチAZ構成できるのか、できないのか、できる場合は同期なのか、非同期なのか等も把握しておくと良いかもしれません。例えば、AuroraとRDSの違いにも関係しますが、それぞれでどういった冗長化機能の実現方式となっているか等です。

グローバル展開機能の差異を意識する

Aurora、RDS、DynamoDB、ElastiCache、Redshift等はグローバルに展開する機能を保持しています。DRとして他リージョンを利用する機能もあります。それぞれの特徴(例えば書き込み可否やデータコピーの方法)について把握しておくと良いかもしれません。

複数が正解に見える時は最も重視されていることを考える

正直、複数の選択肢が正解に見えることもありますが、そういった時は、問題文で「何が最も重視されているか」を意識するようにしました。料金なのか、変更量なのか、ダウンタイムなのか、メンテナンス性なのか等、改めて見てみると正解が絞れることもあるかもしれません。

Aurora PostgreSQLでキャッシュをクリアする方法について

wannabe — Sun, 07 Mar 2021 00:00:00 +0000

データベース開発作業の一環として、パフォーマンスのテストを実施することもあるかと存じます。ただし、複数回のパフォーマンステストを実施する際には、実施前にキャッシュをクリアし、その影響を抑える必要があります。ここでは、Aurora PostgreSQLでキャッシュをクリアする際の手法について記載します。

結論

結論としては次の通りです。残念ながら、執筆時点ではSQL等によりキャッシュをクリアすることはできません。

Aurora PostgreSQLクラスターは停止・起動することでキャッシュをクリアできる(再起動ではクリアできない)
バーストパフォーマンスインスタンス(t系のインスタンス)は再起動でもキャッシュをクリアできる(db.t3.mediumで確認)
キャッシュがクリアされたことはpg_buffercacheを利用することで確認することができる

以下、詳細です。

Aurora PostgreSQLは再起動でキャッシュがクリアされない

キャッシュはメモリ上の存在するため、揮発性を持ち、したがって、再起動によりキャッシュはクリアされるというのが一般的な感覚であるかと存じます。

しかしながら、Auroraはクラウドに適したアーキテクチャとなっているからか、障害発生時の再起動を想定し、再起動後はキャッシュを自動的にウォームアップします。

Aurora では、データベースがシャットダウン後に起動したとき、または障害発生後に再起動したときに、バッファープールキャッシュを "ウォームアップ" します。つまり、Aurora では、メモリ内ページキャッシュに保存された既知の一般的なクエリのページを使用してバッファープールを事前にロードします。これにより、通常のデータベースの使用からバッファープールを "ウォームアップ" する必要性をバイパスすることでパフォーマンスが向上します。

Aurora ページキャッシュはデータベースとは別のプロセスで管理されるため、ページキャッシュはデータベースとは無関係に存続できます。データベースに障害が発生した場合でも、ページキャッシュはメモリに残るため、バッファプールはデータベースの起動時に最新の状態にウォームアップされます。

Amazon Aurora ストレージと信頼性

ただし、執筆時点のAurora PostgreSQLで最も安価なdb.t3.mediumインスタンスでは、再起動によりキャッシュがクリアされてしまいました。
Auroraでt系インスタンスを利用する場合は、多くのケースにおいては開発環境が想定されますので、キャッシュについての実装内容が異なるのかもしれません。

Aurora PostgreSQLでキャッシュをクリアする方法

上記のキャッシュのウォームアップは、執筆時点では「再起動」にのみ適用され、停止→起動には適用されません。したがって、停止→起動することで、Aurora PostgreSQLもキャッシュをクリアすることができます。

パフォーマンステストを複数回実施する際には、事前にクラスターを停止→起動することでキャッシュをクリアし、キャッシュの内容による結果のブレを抑えるといった対応を行うことができます。

Aurora PostgreSQLでキャッシュを確認する方法

通常のPostgreSQLと同じく、pg_buffercacheを利用することでキャッシュの中身を確認することができます。キャッシュがクリアされたかという点については、キャッシュ上にユーザテーブルが存在するかという観点で確認できます。

Aurora PostgreSQLにおいても、マスターユーザにてcreate extension pg_buffercache;を実施することで、pg_buffercacheの拡張機能を利用することができるようになります。

以下に、停止→起動によりキャッシュがクリアされたことを確認する例を記載します。

postgres=> -- キャッシュ状態の事前確認
postgres=> SELECT c.relname, count(*) AS buffers
postgres->              FROM public.pg_buffercache b INNER JOIN pg_class c
postgres->              ON b.relfilenode = pg_relation_filenode(c.oid) AND
postgres->                 b.reldatabase IN (0, (SELECT oid FROM pg_database
postgres(>                                       WHERE datname = current_database()))
postgres->              GROUP BY c.relname
postgres->              ORDER BY 2 DESC
postgres->              LIMIT 5;
                 relname                 | buffers
-----------------------------------------+---------
 pg_attribute                            |      42
 pg_class                                |      12
 pg_proc                                 |       8
 pg_attribute_relid_attnum_index         |       7
 pg_proc_oid_index                       |       6
(5 rows)

postgres=> -- `stats_test_table`を参照することでキャッシュに載せる
postgres=> select * from public.stats_test_table;
 col1 | col2
------+------
    1 | test
    2 | test
    3 | test
---省略---

postgres=> -- `stats_test_table`がキャッシュに存在することを確認する
postgres=> SELECT c.relname, count(*) AS buffers
postgres->              FROM public.pg_buffercache b INNER JOIN pg_class c
postgres->              ON b.relfilenode = pg_relation_filenode(c.oid) AND
postgres->                 b.reldatabase IN (0, (SELECT oid FROM pg_database
postgres(>                                       WHERE datname = current_database()))
postgres->              GROUP BY c.relname
postgres->              ORDER BY 2 DESC
postgres->              LIMIT 5;
                 relname                 | buffers
-----------------------------------------+---------
 pg_attribute                            |      42
 pg_class                                |      12
 stats_test_table                        |      11
 pg_proc                                 |       8
 pg_attribute_relid_attnum_index         |       7
(5 rows)

postgres=> -- Aurora PostgreSQLクラスターを停止→起動する
postgres=> -- 再接続しキャッシュ状況を確認する(`stats_test_table`が存在しない)
postgres=> SELECT c.relname, count(*) AS buffers
postgres->              FROM public.pg_buffercache b INNER JOIN pg_class c
postgres->              ON b.relfilenode = pg_relation_filenode(c.oid) AND
postgres->                 b.reldatabase IN (0, (SELECT oid FROM pg_database
postgres(>                                       WHERE datname = current_database()))
postgres->              GROUP BY c.relname
postgres->              ORDER BY 2 DESC
postgres->              LIMIT 5;
                 relname                 | buffers
-----------------------------------------+---------
 pg_attribute                            |      42
 pg_class                                |      12
 pg_proc                                 |       8
 pg_attribute_relid_attnum_index         |       7
 pg_proc_oid_index                       |       6
(5 rows)

Aurora PostgreSQLはクラウド環境に最適化されたエンジンで、優れた機能を多く持っていますが、結果として既存の感覚が通用しない挙動となることもあります。

便利な分、ドキュメントを精読したり、動作確認をしたり、挙動の把握は大切ですね。なかなか事前に全ての挙動を把握するのは難しいですが。

MaximumUsedTransactionIDsについて

wannabe — Fri, 12 Feb 2021 00:00:00 +0000

RDS for PostgreSQLやAurora PostgreSQLでCloudWatchメトリクスとして用意されているMaximumUsedTransactionIDsについて記載致します。

MaximumUsedTransactionIDsについてのまとめ

MaximumUsedTransactionIDsは、当該インスタンス上の全データベース中で、最も長くトランザクションIDが凍結されていないテーブルの経過トランザクション数を示します。

最も長くトランザクションIDが凍結されていないテーブルについて、下記のような条件が満たされると、当該メトリクスも低下します。

バキューム時に古いトランザクションIDを含むページが読み込まれた場合
最後にトランザクションIDが凍結されてからvacuum_freeze_table_ageの設定値を経過した後にバキュームされた場合
最後にトランザクションIDが凍結されてからautovacuum_freeze_max_ageの設定値に達して強制的にバキュームされた場合
手動でvacuum freezeを実行した場合

最後にトランザクションIDが凍結されてからの経過トランザクション数をデータベースごとに確認するには下記のようなSQLを実行します。

select
  datname,
  age(datfrozenxid) as age
from
  pg_database
order by
  2 desc,
  1
;

最後にトランザクションIDが凍結されてからの経過トランザクション数をテーブルごとに確認するには下記のようなSQLを実行します。

上記で経過トランザクション数が多かったデータベースに接続して実施します。

select
  relname,
  age(relfrozenxid) as age
from
  pg_class
where
  relkind = 'r'
order by
  2 desc,
  1
;

最終的にはMaximumUsedTransactionIDsがautovacuum_freeze_max_ageの設定値に達した段階で強制的なバキュームにより増加傾向が横ばいとなることが予測されますが、これは、必ずしも未対応で問題ないということは意味しません。

autovacuum_freeze_max_ageに達するまで、何らかの理由で長い期間バキュームされていなかったということを暗示するためです。また、このタイミングの強制的なバキュームの負荷が非常に高くなる可能性があります。

したがって、MaximumUsedTransactionIDsのメトリクスについて、少なくともvacuum_freeze_table_ageの設定値付近にアラームを設定しておき、autovacuum_freeze_max_ageに達する前にバキュームするのが望ましい対応です。

また、自動バキュームが適切に行われているか確認し、行われていない場合は、自動バキュームの閾値を再検討する形が望ましいです。

自動バキュームが行われているかは、rds.force_autovacuum_logging_levelおよびlog_autovacuum_min_durationを適切に設定することで、ログ上から確認することができます。例えば、前者をlogとし、後者を0とすることで、全ての自動バキュームに関する情報をログ出力させることができます。

主なログの確認観点としては、「自動バキュームが行われているか」という点と、「自動バキュームがスキップされていないか」という点になります。

rds.force_autovacuum_logging_level パラメータの値を log に設定し、log_autovacuum_min_duration パラメータを 1,000〜5,000 ミリ秒の値に設定することをお勧めします。この値を 5,000 に設定すると、Amazon RDS は、5 秒を超えるすべてのアクティビティをログに書き込みます。また、アプリケーションのロックによって autovacuum で意図的にテーブルがスキップされた場合は、「バキュームのスキップ」メッセージも表示されます。

PostgreSQL の一般的な DBA タスク

以下、MaximumUsedTransactionIDsに深く関連するトランザクションIDに関する説明です。

トランザクションIDとは

データのバージョン管理を行うための管理IDである
トランザクションIDを比較することでどの時点のデータを見せるかを管理している

PostgreSQLはデータ追記型のアーキテクチャです。データに対して更新を行っても、実際は最新版のデータが追記されます。つまり、更新前のデータは最新版として扱われなくなるだけで、バキュームで回収されるまでは物理的には存在しています。

データ追記型アーキテクチャにおいて問題となるのが、データのバージョン管理です。物理的には複数データが存在するため、どれが最新のデータなのか、実行中のトランザクションからはどのデータを見れば良いのかという点を管理する必要があります。

このバージョン管理を実施するために利用されているのがトランザクションIDです。

イメージとしては、各トランザクションに昇順の数値であるトランザクションIDを割り当て、そのトランザクション内でデータが更新(実際は追記)された場合は、当該データに対して、更新を行ったトランザクションIDもメタデータとして保持させるような形です。

各トランザクションに割り当てられたIDと、各データが保持するIDを比較することにより、トランザクションから参照可能なデータのバージョンの絞り込みが行えるようになります。

このトランザクションIDの比較作業により、たとえ物理的には古いデータが存在している場合でも、論理的には新しいデータを見ることができるようになります。

また、そのトランザクションから見えてはいけない時点のデータを見せないといったバージョン管理も実現することができます。

PostgreSQLのMVCCトランザクションのセマンティクスは、トランザクションID（XID）番号の比較が可能であることに依存しています。現在のトランザクションのXIDよりも新しい挿入時のXIDを持ったバージョンの行は、「未来のもの」であり、現在のトランザクションから可視であってはなりません。

24.1. 定常的なバキューム作業

トランザクションIDの周回とは

利用できるトランザクションIDを使い果たして最初から再利用し始める事象のこと
何も対策が取られないと再利用後のトランザクションからは全てのデータが論理的に見えなくなる

さて、上記でトランザクションIDについて記載しましたが、数値を扱う上で避けられないことがあります。それは扱える数値の上限です。

PostgreSQLではトランザクションIDを32ビットの符号付き整数で表しているため、-2,147,483,648から2,147,483,647まで扱えます。

つまり、トランザクションIDの最大値は2,147,483,647ですが、PostgreSQLはこの約20億以上のトランザクションを超えても継続的に動作できるような仕組みを持っています。

どのような仕組みかと言うと、トランザクションIDを最初からまた再利用するのです。これをトランザクションIDの周回と呼びます。

しかしながら、再利用されて割り当てられたトランザクションIDは直前のトランザクションIDと比べると、圧倒的に若い値となります(極端に表現すると2,147,483,647→0)。

そうなると、再利用されたトランザクションIDからは、全てのデータが未来のものとして扱われるようになります。

したがって、物理的にはデータが存在する状態にも関わらず、論理的にはデータは存在しないものとして扱われてしまいます。

トランザクションIDのサイズには制限（32ビット）があり、長時間（40億トランザクション）稼働しているクラスタはトランザクションの周回を経験します。 XIDのカウンタが一周して0に戻り、そして、突然に、過去になされたトランザクションが将来のものと見えるように、つまり、その出力が不可視になります。端的に言うと、破滅的なデータの損失です。（実際はデータは保持されていますが、それを入手することができなければ、慰めにならないでしょう。）

24.1. 定常的なバキューム作業

トランザクションIDの凍結とは

データをどのトランザクションIDから見ても過去のものとして見えるトランザクションIDに更新すること
これによりトランザクションIDの周回による論理的なデータ損失を避けることができる

論理的にデータが損失するということは、実質的に約20億トランザクションまでしかPostgreSQLを利用できないのかと言うと、そうではありません。

上記のトランザクションIDの周回に伴う論理的なデータの損失を避けるための仕組みも持っています。

どのような仕組みかと言うと、データを「どのトランザクションIDから見ても過去のものとして見えるトランザクションID」として更新するのです。この特殊な更新をトランザクションIDの凍結と呼びます。

この仕組みにより、たとえトランザクションIDの周回が発生し、急激に若いトランザクションIDが割り当てられ、単純なトランザクションIDの比較だとデータが論理的に損失するような場合でも、「どのトランザクションIDから見ても過去のものとして見えるトランザクションID」に凍結されたデータを見ることができるようになります。

PostgreSQLは特別なXID、FrozenTransactionIdを確保します。このXIDは通常のXIDの比較規則には従わず、常に全ての通常のXIDよりも古いものとみなされます。

～～中略～～

凍結された行バージョンは挿入XIDがFrozenTransactionIdであるかのように扱われ、それで、周回問題に関係なく、すべての通常のトランザクションから「過去のもの」として認識され、また、そのバージョンの行はどれだけ古いものであろうと、削除されるまで有効状態となります。

24.1. 定常的なバキューム作業

トランザクションIDの凍結タイミング

トランザクションIDの凍結は下記のタイミングにて実施されます。

バキューム時に古いトランザクションIDを含むページが読み込まれた場合
最後にトランザクションIDが凍結されてからvacuum_freeze_table_ageの設定値を経過した後にバキュームされた場合
最後にトランザクションIDが凍結されてからautovacuum_freeze_max_ageの設定値に達して強制的にバキュームされた場合
手動でvacuum freezeを実行した場合

バキューム時に古いトランザクションIDを含むページが読み込まれた場合

通常、バキューム処理はパフォーマンス向上のため、全てのページを読み込むわけではありません。この際、読み飛ばされたページに古いトランザクションIDがあった場合、それは凍結されません。

したがって、普通のバキューム時には、古いトランザクションIDを含むページが読み込まれない限り、凍結は実施されません(必ず凍結されることは保証されていない)。

通常は、不要な行バージョンを持っていないページを読み飛ばします。このとき、そのページに古いXID値の行バージョンがまだある可能性があったとしても読み飛ばします。したがって、通常のVACUUMでは必ずしもテーブル内のすべての古い行バージョンを凍結するわけではありません。

24.1. 定常的なバキューム作業

最後にトランザクションIDが凍結されてから`vacuum_freeze_table_age`の設定値を経過した後にバキュームされた場合

テーブルで凍結されているトランザクションIDと、現在のトランザクションIDの差がvacuum_freeze_table_ageの設定値を超えた後にバキュームされると(最後にトランザクションIDが凍結されてからvacuum_freeze_table_age経過すると)、そのテーブルに対しては積極的に凍結が試みられます。

しかしながら、vacuum_freeze_table_ageを超えても、そもそもバキューム自体が実行されない場合には、凍結も実施されません。

テーブルのpg_class.relfrozenxidフィールドがこの設定で指定した時期に達すると、VACUUMは積極的なテーブル全て走査を行います。積極的な全て走査は、無効タプルを含む可能性のあるページだけではなく、凍結されていないXIDあるいはMXIDを含むすべてのページを読む点で通常のVACUUMとは異なります。

vacuum_freeze_table_age

最後にトランザクションIDが凍結されてから`autovacuum_freeze_max_age`の設定値に達して強制的にバキュームされた場合

最後のトランザクションIDの凍結からvacuum_freeze_table_ageを超えてもバキュームされないままだと、最終的にautovacuum_freeze_max_ageの段階で強制的にバキュームされます。

これにより、トランザクションIDの周回によるデータ損失対策が強制的に実施されます。

トランザクションID周回を防ぐためにVACUUM操作が強制される前までにテーブルのpg_class.relfrozenxid フィールドが到達できる最大（トランザクションにおける）年代を指定します。自動バキュームが無効であった時でも、システムは周回を防ぐために自動バキューム子プロセスを起動することに注意してください。

autovacuum_freeze_max_age

手動で`vacuum freeze`を実行した場合

手動でバキューム時に凍結を実施した場合も、トランザクションIDが凍結されます。バキューム時にfreezeオプションをつけることで手動で実施することができます。

FREEZE

積極的なタプルの「凍結」を選択します。 FREEZE指定は、vacuum_freeze_min_ageおよびvacuum_freeze_table_ageパラメータをゼロとしてVACUUMを実行することと同じです。テーブルが書き換えられる時は、必ず積極的な凍結が行われるので、FULLが指定されているときは、このオプションは冗長です。

VACUUM

経過トランザクション数の確認

データベースごと

最後にトランザクションIDが凍結されてからの経過トランザクション数をデータベースごとに確認するには、例えば下記のようなSQLを実行します。

select
  datname,
  age(datfrozenxid) as age
from
  pg_database
order by
  2 desc,
  1
;

テーブルごと

最後にトランザクションIDが凍結されてからの経過トランザクション数をテーブルごとに確認するには、例えば下記のようなSQLを実行します。

select
  relname,
  age(relfrozenxid) as age
from
  pg_class
order by
  2 desc,
  1
;

RDS for Oracle作成後に行う基本的な設定について

wannabe — Fri, 01 Jan 2021 00:00:00 +0000

RDS for Oracleを作成後、対象インスタンスの内部で共通して実施することの多い、基本的な設定を記載致します。パラメータグループやオプショングループ等のAWSコンソール上で設定可能な項目につきましては、記載対象外となっておりますので、ご了承いただければと存じます。また、全て網羅しているわけではない点につきましても、ご了承いただければと存じます。

動作確認環境

今回はRDS for Oracle 12.1 SE2を利用して動作確認を実施致しました。

エディションやバージョンが異なる場合、内容も若干異なる可能性がある点につきましても、ご了承いただければと存じます。

REDOログ

RDS初期構築時の設定

RDS for Oracleでは、構築時に128MBのREDOログ・グループが4つ用意されています。各REDOログ・グループには1つのメンバが存在する状況です。

SQL> select group#, bytes/1024/1024 mb, status from v$log order by 1;

    GROUP#         MB STATUS
---------- ---------- --------------------------------
         1        128 ACTIVE
         2        128 CURRENT
         3        128 ACTIVE
         4        128 ACTIVE

オンプレミスに慣れ親しんだ方から見ると、REDOログ・メンバが1つという状況に違和感を覚えるかもしれませんが、RDS for Oracleではグループにメンバを追加することはできません。

したがって、RDS for OracleにおいてのREDOログ管理は、「REDOログファイルのサイズ」と「REDOログ・グループの数」の2つの観点となります。

更に、RDS for Oracleでは5分おきに強制的にログスイッチが発生するという内部仕様があります。これはRDSのPITR機能を実現するためのもので、変更することはできません。

DB インスタンスの復元可能な直近の時間は、通常、現在時刻の 5 分以内です。

Amazon RDS のバックアップと復元

つまり、どれだけREDOログを大きくしても、ログスイッチの発生間隔を5分より短くすることはできません。したがって、チェックポイントの発生間隔も5分より短くすることはできません。

この仕様により、RDS for Oracleでは次のようなメッセージがアラートログに出力されやすくなっています。5分間隔で定期的に出力されており、かつ、具体的なパフォーマンス影響がない場合、現状では無視せざるを得ないメッセージです。

Thread 1 cannot allocate new log, sequence 5154
Checkpoint not complete
  Current log# 5 seq# 5153 mem# 0: /rdsdbdata/db/ORCL_A/onlinelog/o1_mf_5_hq02flny_.log

5分間隔よりも短く、かつ、継続的に出力されているような場合は、REDOログのサイズを大きくしたり、REDOログのグループ数を増やしたりするといった対応の検討を行います。

チェックポイントの発生があまりにも多すぎるという印象を持たれる方もいらっしゃるかとは存じますが、マネージドサービスのため、現状では受け入れるしかない仕様です。

REDOログサイズ変更

RDSでは、具体的には次のような流れにてREDOログのサイズ変更を行います。流れ自体はオンプレミスと変わりありませんが、操作にはAWSが用意したプロシージャを利用する必要があります。

十分な空きストレージ容量があることを確認する
適切なサイズのREDOログを適切な数だけ追加する(rdsadmin.rdsadmin_util.add_logfile)
ログスイッチを行い追加したREDOログをCURRENTにする(rdsadmin.rdsadmin_util.switch_logfile)
既存のREDOログがINACTIVEでない場合はチェックポイントを手動で発生させる(rdsadmin.rdsadmin_util.checkpoint)
既存のREDOログを削除する(rdsadmin.rdsadmin_util.drop_logfile)

次の例では、REDOログのサイズを128MBから1GBに変更しています。REDOログの数は4つのままとしています。

-- 1GBのREDOログを4つ追加します(引数にはサイズを指定します)
SQL> exec rdsadmin.rdsadmin_util.add_logfile(p_size => '1024M');

PL/SQLプロシージャが正常に完了しました。

SQL> exec rdsadmin.rdsadmin_util.add_logfile(p_size => '1024M');

PL/SQLプロシージャが正常に完了しました。

SQL> exec rdsadmin.rdsadmin_util.add_logfile(p_size => '1024M');

PL/SQLプロシージャが正常に完了しました。

SQL> exec rdsadmin.rdsadmin_util.add_logfile(p_size => '1024M');

PL/SQLプロシージャが正常に完了しました。

-- 1GBのREDOログが4つ追加されたことを確認します
SQL> select group#, bytes/1024/1024 mb, status from v$log order by 1;

    GROUP#         MB STATUS
---------- ---------- --------------------------------
         1        128 ACTIVE
         2        128 CURRENT
         3        128 ACTIVE
         4        128 ACTIVE
         5       1024 UNUSED
         6       1024 UNUSED
         7       1024 UNUSED
         8       1024 UNUSED

8行が選択されました。

-- ログスイッチを行い追加したREDOログを`CURRENT`にします
SQL> exec rdsadmin.rdsadmin_util.switch_logfile;

PL/SQLプロシージャが正常に完了しました。

SQL> exec rdsadmin.rdsadmin_util.switch_logfile;

PL/SQLプロシージャが正常に完了しました。

SQL> exec rdsadmin.rdsadmin_util.switch_logfile;

PL/SQLプロシージャが正常に完了しました。

SQL> select group#, bytes/1024/1024 mb, status from v$log order by 1;

    GROUP#         MB STATUS
---------- ---------- --------------------------------
         1        128 ACTIVE
         2        128 ACTIVE
         3        128 ACTIVE
         4        128 ACTIVE
         5       1024 ACTIVE
         6       1024 ACTIVE
         7       1024 CURRENT
         8       1024 UNUSED

8行が選択されました。

-- チェックポイントにより既存のREDOログを`INACTIVE`にします
SQL> exec rdsadmin.rdsadmin_util.checkpoint;

PL/SQLプロシージャが正常に完了しました。

SQL> select group#, bytes/1024/1024 mb, status from v$log order by 1;

    GROUP#         MB STATUS
---------- ---------- --------------------------------
         1        128 INACTIVE
         2        128 INACTIVE
         3        128 INACTIVE
         4        128 INACTIVE
         5       1024 INACTIVE
         6       1024 INACTIVE
         7       1024 CURRENT
         8       1024 UNUSED

8行が選択されました。

-- 既存のREDOログを削除します(引数には削除するREDOログのグループ番号を指定します)
SQL> exec rdsadmin.rdsadmin_util.drop_logfile(grp => 1);

PL/SQLプロシージャが正常に完了しました。

SQL> exec rdsadmin.rdsadmin_util.drop_logfile(grp => 2);

PL/SQLプロシージャが正常に完了しました。

SQL> exec rdsadmin.rdsadmin_util.drop_logfile(grp => 3);

PL/SQLプロシージャが正常に完了しました。

SQL> exec rdsadmin.rdsadmin_util.drop_logfile(grp => 4);

PL/SQLプロシージャが正常に完了しました。

SQL> select group#, bytes/1024/1024 mb, status from v$log order by 1;

    GROUP#         MB STATUS
---------- ---------- --------------------------------
         5       1024 INACTIVE
         6       1024 INACTIVE
         7       1024 CURRENT
         8       1024 UNUSED

UNDO表領域

RDS初期構築時の設定

RDS for Oracleでは、構築時にUNDO_T1として自動拡張が有効になっているUNDO表領域(BIGFILE)が用意されます。私の環境だと320MBでした。自動拡張が有効で、かつ、BIGFILEという点が特徴的です。

SQL> select tablespace_name, bigfile, contents, segment_space_management, retention from dba_tablespaces where contents = 'UNDO' order by 1;

TABLESPACE_NAME                                              BIGFIL CONTENTS           SEGMENT_SPAC RETENTION
------------------------------------------------------------ ------ ------------------ ------------ ----------------------
UNDO_T1                                                      YES    UNDO               MANUAL       NOGUARANTEE

SQL> select tablespace_name, file_name, autoextensible, bytes/1024/1024 mb, maxbytes/1024/1024 maxmb from dba_data_files where tablespace_name like 'UNDO%' order by 1, 2;

TABLESPACE_NAME                                              FILE_NAME                                                 AUTOEX         MB      MAXMB
------------------------------------------------------------ ----------------------------------------------------------------- ------ ---------- ----------
UNDO_T1                                                      /rdsdbdata/db/ORCL_A/datafile/o1_mf_undo_t1_hv5s98qk_.dbf         YES           320     102400

しかしながら、定まった値を確保し、自動拡張させたくないという方もいらっしゃるかと存じます(個人的には、クラウドを利用するなら最大値を設けた上でUNDOもストレージも自動拡張させてしまいますが、予算都合等もありますので)。

UNDO表領域サイズ変更

ALTER TABLESPACE文のRESIZEを利用してUNDO表領域のサイズ変更を行います。なお、新しくUNDO表領域を作成し、UNDO_TABLESPACEパラメータで新規作成したUNDO表領域を指定する方法もあります。

UNDO表領域名はUNDOTBS1でないと落ち着かないという方は、表領域名を変更することも可能ですが、新規作成された方が確実かとは存じます。

SQL> alter tablespace undo_t1 resize 500m;

表領域が変更されました。

SQL> select tablespace_name, file_name, autoextensible, bytes/1024/1024 mb, maxbytes/1024/1024 maxmb from dba_data_files order by 1, 2;

TABLESPACE_NAME                                              FILE_NAME                                                 AUTOEX         MB      MAXMB
------------------------------------------------------------ ----------------------------------------------------------------- ------ ---------- ----------
UNDO_T1                                                      /rdsdbdata/db/ORCL_A/datafile/o1_mf_undo_t1_hv5s98qk_.dbf         YES           500     102400

UNDO表領域自動拡張変更

ALTER TABLESPACE文のAUTOEXTENDを利用してUNDO表領域のサイズ変更を行います。サイズと同様、新しくUNDO表領域を作成し、UNDO_TABLESPACEパラメータで新規作成したUNDO表領域を指定する方法もあります。

SQL> alter tablespace undo_t1 autoextend off;

表領域が変更されました。

SQL> select tablespace_name, file_name, autoextensible, bytes/1024/1024 mb, maxbytes/1024/1024 maxmb from dba_data_files order by 1, 2;

TABLESPACE_NAME                                              FILE_NAME                                                 AUTOEX         MB      MAXMB
------------------------------------------------------------ ----------------------------------------------------------------- ------ ---------- ----------
UNDO_T1                                                      /rdsdbdata/db/ORCL_A/datafile/o1_mf_undo_t1_hv5s98qk_.dbf         NO            500          0

その他

デフォルトのUNDO表領域において、UNDOの保証はNOGUARANTEEとなっています。したがって、UNDOを保証する場合は別途有効にする作業が必要です。また、自動拡張も有効にしておく必要がある点にも留意が必要です。

ちなみに、パラメータグループ上でUNDO_TABLESPACEにデフォルトのUNDO表領域名(UNDO_T1)以外の名前を指定し、その表領域が存在しない状況で起動した場合、RDS側でデフォルト設定のUNDO表領域を自動的に作成してくれます。なお、これは確認時点の挙動なので、確証はございません。

一時表領域

RDS初期構築時の設定

RDS for Oracleでは、構築時にTEMPとして自動拡張が有効になっている一時表領域(BIGFILE)が用意されます。私の環境だと100MBでした。UNDO表領域と同様、自動拡張が有効で、かつ、BIGFILEという点が特徴的です。

SQL> select tablespace_name, bigfile, contents, segment_space_management from dba_tablespaces where contents = 'TEMPORARY' order by 1;

TABLESPACE_NAME                                              BIGFIL CONTENTS           SEGMENT_SPAC
------------------------------------------------------------ ------ ------------------ ------------
TEMP                                                         YES    TEMPORARY          MANUAL

SQL> select tablespace_name, file_name, autoextensible, bytes/1024/1024 mb, maxbytes/1024/1024 maxmb from dba_temp_files order by 1, 2;

TABLESPACE_NAME                                              FILE_NAME                                                 AUTOEX         MB      MAXMB
------------------------------------------------------------ ----------------------------------------------------------------- ------ ---------- ----------
TEMP                                                         /rdsdbdata/db/ORCL_A/datafile/o1_mf_temp_hym2gnd6_.tmp            YES           100     102400

こちらも、UNDOと同様、一定サイズを指定し、自動拡張は無効にされたい方もいらっしゃるかと存じます。

一時表領域サイズ変更

ALTER TABLESPACE文のRESIZEを利用して一時表領域のサイズ変更を行います。UNDO表領域と同じです。

SQL> alter tablespace temp resize 200m;

表領域が変更されました。

SQL> select tablespace_name, file_name, autoextensible, bytes/1024/1024 mb, maxbytes/1024/1024 maxmb from dba_temp_files order by 1, 2;

TABLESPACE_NAME                                              FILE_NAME                                                 AUTOEX         MB      MAXMB
------------------------------------------------------------ ----------------------------------------------------------------- ------ ---------- ----------
TEMP                                                         /rdsdbdata/db/ORCL_A/datafile/o1_mf_temp_hym2gnd6_.tmp            YES           200     102400

一時表領域自動拡張変更

ALTER TABLESPACE文のAUTOEXTENDを利用してUNDO表領域のサイズ変更を行います。こちらもUNDO表領域と同じです。

SQL> alter tablespace temp autoextend off;

表領域が変更されました。

SQL> select tablespace_name, file_name, autoextensible, bytes/1024/1024 mb, maxbytes/1024/1024 maxmb from dba_temp_files order by 1, 2;

TABLESPACE_NAME                                              FILE_NAME                                                 AUTOEX         MB      MAXMB
------------------------------------------------------------ ----------------------------------------------------------------- ------ ---------- ----------
TEMP                                                         /rdsdbdata/db/ORCL_A/datafile/o1_mf_temp_hym2gnd6_.tmp            NO            200          0

自動メンテナンスタスク

RDS初期構築時の設定

ライセンス等の関係で、とりあえず無効にされることもある自動メンテナンスタスクですが、RDS for Oracleにおいても健在で、全て有効状態となっています。

また、バッチ時間帯と重複して統計情報を取得されたら困るということで、自動メンテナンスタスクの実行時間帯を変更することも多いかと存じますが、RDS for Oracleにおいては、時間だけでなくタイムゾーンも考慮する必要があります。

ウィンドウのタイムゾーン設定がETC/UTCであるためです。

SQL> select client_name, window_group, status from dba_autotask_client order by 1;

CLIENT_NAME                      WINDOW_GROUP     STATUS
-------------------------------- ---------------- ----------------
auto optimizer stats collection  ORA$AT_WGRP_OS   ENABLED
auto space advisor               ORA$AT_WGRP_SA   ENABLED
sql tuning advisor               ORA$AT_WGRP_SQ   ENABLED

SQL> select window_group_name, number_of_windows, enabled, next_start_date from dba_scheduler_window_groups order by 1;

WINDOW_GROUP_NAME         NUMBER_OF_WINDOWS ENABLED    NEXT_START_DATE
------------------------- ----------------- ---------- ------------------------------------------------------------------------------------------------------------------------
MAINTENANCE_WINDOW_GROUP                  7 TRUE       20-12-29 22:00:00.000000 ETC/UTC
ORA$AT_WGRP_OS                            7 TRUE       20-12-29 22:00:00.000000 ETC/UTC
ORA$AT_WGRP_SA                            7 TRUE       20-12-29 22:00:00.000000 ETC/UTC
ORA$AT_WGRP_SQ                            7 TRUE       20-12-29 22:00:00.000000 ETC/UTC

SQL> select * from dba_autotask_window_clients order by 1;

WINDOW_NAME          WINDOW_NEXT_TIME                                                            WINDOW_ACT AUTOTASK_STATUS  OPTIMIZER_STATS  SEGMENT_ADVISOR  SQL_TUNE_ADVISOR HEALTH_MONITOR
-------------------- --------------------------------------------------------------------------- ---------- ---------------- ---------------- ---------------- ---------------- ----------------
FRIDAY_WINDOW        21-01-01 22:00:00.000000 ETC/UTC                                            FALSE      ENABLED          ENABLED          ENABLED          ENABLED          DISABLED
MONDAY_WINDOW        21-01-04 22:00:00.000000 ETC/UTC                                            FALSE      ENABLED          ENABLED          ENABLED          ENABLED          DISABLED
SATURDAY_WINDOW      21-01-02 06:00:00.000000 ETC/UTC                                            FALSE      ENABLED          ENABLED          ENABLED          ENABLED          DISABLED
SUNDAY_WINDOW        21-01-03 06:00:00.000000 ETC/UTC                                            FALSE      ENABLED          ENABLED          ENABLED          ENABLED          DISABLED
THURSDAY_WINDOW      20-12-31 22:00:00.000000 ETC/UTC                                            FALSE      ENABLED          ENABLED          ENABLED          ENABLED          DISABLED
TUESDAY_WINDOW       20-12-29 22:00:00.000000 ETC/UTC                                            FALSE      ENABLED          ENABLED          ENABLED          ENABLED          DISABLED
WEDNESDAY_WINDOW     20-12-30 22:00:00.000000 ETC/UTC                                            FALSE      ENABLED          ENABLED          ENABLED          ENABLED          DISABLED

7行が選択されました。

SQL> select window_name, repeat_interval, duration, enabled from dba_scheduler_windows order by 1;

WINDOW_NAME          REPEAT_INTERVAL                                                        DURATION                                                            ENABLED
-------------------- ---------------------------------------------------------------------- --------------------------------------------------------------------------- ----------
FRIDAY_WINDOW        freq=daily;byday=FRI;byhour=22;byminute=0; bysecond=0                  +000 04:00:00                                                               TRUE
MONDAY_WINDOW        freq=daily;byday=MON;byhour=22;byminute=0; bysecond=0                  +000 04:00:00                                                               TRUE
SATURDAY_WINDOW      freq=daily;byday=SAT;byhour=6;byminute=0; bysecond=0                   +000 20:00:00                                                               TRUE
SUNDAY_WINDOW        freq=daily;byday=SUN;byhour=6;byminute=0; bysecond=0                   +000 20:00:00                                                               TRUE
THURSDAY_WINDOW      freq=daily;byday=THU;byhour=22;byminute=0; bysecond=0                  +000 04:00:00                                                               TRUE
TUESDAY_WINDOW       freq=daily;byday=TUE;byhour=22;byminute=0; bysecond=0                  +000 04:00:00                                                               TRUE
WEDNESDAY_WINDOW     freq=daily;byday=WED;byhour=22;byminute=0; bysecond=0                  +000 04:00:00                                                               TRUE
WEEKEND_WINDOW       freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0                    +002 00:00:00                                                               FALSE
WEEKNIGHT_WINDOW     freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=22;byminute=0; bysecond=0  +000 08:00:00                                                               FALSE

9行が選択されました。

自動メンテナンスタスク無効化

RDSでもDBMS_AUTO_TASK_ADMINを利用して無効化を行います。次の例ではSQLチューニング・アドバイザーを無効にしています。

SQL> begin
  2    dbms_auto_task_admin.disable(
  3        client_name => 'sql tuning advisor',
  4        operation   => null,
  5        window_name => null
  6    );
  7  end;
  8  /

PL/SQLプロシージャが正常に完了しました。

SQL> select client_name, window_group, status from dba_autotask_client order by 1;

CLIENT_NAME                      WINDOW_GROUP     STATUS
-------------------------------- ---------------- ----------------
auto optimizer stats collection  ORA$AT_WGRP_OS   ENABLED
auto space advisor               ORA$AT_WGRP_SA   ENABLED
sql tuning advisor               ORA$AT_WGRP_SQ   DISABLED

メンテナンスウィンドウ変更(タイムゾーン)

ウィンドウのタイムゾーンがETC/UTCになっているということは、JSTから見た場合9時間遅いということになります。そのままだと、夜間のつもりが日本時間だと昼間だったということも起こり得るため、タイムゾーンを変更します。

タイムゾーンの変更にはDBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTEを利用します。

次の例では、タイムゾーンをAsia/Tokyoに変更しています。なお、Asia/Tokyoの部分を+09:00としてもJSTを表します。

SQL> begin
  2    dbms_scheduler.set_scheduler_attribute(
  3      attribute => 'default_timezone',
  4      value     => 'Asia/Tokyo'
  5    );
  6  end;
  7  /

PL/SQLプロシージャが正常に完了しました。

SQL> select * from dba_autotask_window_clients order by 1;

WINDOW_NAME          WINDOW_NEXT_TIME                                                            WINDOW_ACT AUTOTASK_STATUS  OPTIMIZER_STATS  SEGMENT_ADVISOR  SQL_TUNE_ADVISOR HEALTH_MONITOR
-------------------- --------------------------------------------------------------------------- ---------- ---------------- ---------------- ---------------- ---------------- ----------------
FRIDAY_WINDOW        21-01-01 22:00:00.000000 ASIA/TOKYO                                         FALSE      ENABLED          ENABLED          ENABLED          DISABLED         DISABLED
MONDAY_WINDOW        21-01-04 22:00:00.000000 ASIA/TOKYO                                         FALSE      ENABLED          ENABLED          ENABLED          DISABLED         DISABLED
SATURDAY_WINDOW      21-01-02 06:00:00.000000 ASIA/TOKYO                                         FALSE      ENABLED          ENABLED          ENABLED          DISABLED         DISABLED
SUNDAY_WINDOW        21-01-03 06:00:00.000000 ASIA/TOKYO                                         FALSE      ENABLED          ENABLED          ENABLED          DISABLED         DISABLED
THURSDAY_WINDOW      20-12-31 22:00:00.000000 ASIA/TOKYO                                         FALSE      ENABLED          ENABLED          ENABLED          DISABLED         DISABLED
TUESDAY_WINDOW       20-12-29 22:00:00.000000 ASIA/TOKYO                                         FALSE      ENABLED          ENABLED          ENABLED          DISABLED         DISABLED
WEDNESDAY_WINDOW     20-12-30 22:00:00.000000 ASIA/TOKYO                                         FALSE      ENABLED          ENABLED          ENABLED          DISABLED         DISABLED

7行が選択されました。

SQL> select window_group_name, number_of_windows, enabled, next_start_date from dba_scheduler_window_groups order by 1;

WINDOW_GROUP_NAME         NUMBER_OF_WINDOWS ENABLED    NEXT_START_DATE
------------------------- ----------------- ---------- ------------------------------------------------------------------------------------------------------------------------
MAINTENANCE_WINDOW_GROUP                  7 TRUE       20-12-29 22:00:00.000000 ASIA/TOKYO
ORA$AT_WGRP_OS                            7 TRUE       20-12-29 22:00:00.000000 ASIA/TOKYO
ORA$AT_WGRP_SA                            7 TRUE       20-12-29 22:00:00.000000 ASIA/TOKYO
ORA$AT_WGRP_SQ                            7 TRUE       20-12-29 22:00:00.000000 ASIA/TOKYO

メンテナンスウィンドウ変更(時間帯)

メンテナンスウィンドウの時間帯を変更したいというケースもあるかと存じます。デフォルトですと、平日は22時から4時間、土日は6時から20時間が実行時間帯となっていますが、これがベストという場合は少ないものと存じます。

ウィンドウ時間の変更にはDBMS_SCHEDULER.SET_ATTRIBUTEを利用します。

次の例では、月火水木金のウィンドウを2時30分から4時間、土日のウィンドウを2時30分から8時間としています。

SQL> begin
  2    dbms_scheduler.set_attribute(
  3      name      => 'sys.monday_window',
  4      attribute => 'repeat_interval',
  5      value     => 'freq=daily;byday=mon;byhour=2;byminute=30; bysecond=0'
  6    );
  7    dbms_scheduler.set_attribute(
  8      name      => 'sys.tuesday_window',
  9      attribute => 'repeat_interval',
 10      value     => 'freq=daily;byday=tue;byhour=2;byminute=30; bysecond=0'
 11    );
 12    dbms_scheduler.set_attribute(
 13      name      => 'sys.wednesday_window',
 14      attribute => 'repeat_interval',
 15      value     => 'freq=daily;byday=wed;byhour=2;byminute=30; bysecond=0'
 16    );
 17    dbms_scheduler.set_attribute(
 18      name      => 'sys.thursday_window',
 19      attribute => 'repeat_interval',
 20      value     => 'freq=daily;byday=thu;byhour=2;byminute=30; bysecond=0'
 21    );
 22    dbms_scheduler.set_attribute(
 23      name      => 'sys.friday_window',
 24      attribute => 'repeat_interval',
 25      value     => 'freq=daily;byday=fri;byhour=2;byminute=30; bysecond=0'
 26    );
 27    dbms_scheduler.set_attribute(
 28      name      => 'sys.saturday_window',
 29      attribute => 'repeat_interval',
 30      value     => 'freq=daily;byday=sat;byhour=2;byminute=30; bysecond=0'
 31    );
 32    dbms_scheduler.set_attribute(
 33      name      => 'sys.saturday_window',
 34      attribute => 'duration',
 35      value     => numtodsinterval(8, 'hour')
 36    );
 37    dbms_scheduler.set_attribute(
 38      name      => 'sys.sunday_window',
 39      attribute => 'repeat_interval',
 40      value     => 'freq=daily;byday=sat;byhour=2;byminute=30; bysecond=0'
 41    );
 42    dbms_scheduler.set_attribute(
 43      name      => 'sys.sunday_window',
 44      attribute => 'duration',
 45      value     => numtodsinterval(8, 'hour')
 46    );
 47  end;
 48  /

PL/SQLプロシージャが正常に完了しました。

SQL> select window_name, repeat_interval, duration, enabled from dba_scheduler_windows order by 1;

WINDOW_NAME          REPEAT_INTERVAL                                                        DURATION                                                            ENABLED
-------------------- ---------------------------------------------------------------------- --------------------------------------------------------------------------- ----------
FRIDAY_WINDOW        freq=daily;byday=fri;byhour=2;byminute=30; bysecond=0                  +000 04:00:00                                                               TRUE
MONDAY_WINDOW        freq=daily;byday=mon;byhour=2;byminute=30; bysecond=0                  +000 04:00:00                                                               TRUE
SATURDAY_WINDOW      freq=daily;byday=sat;byhour=2;byminute=30; bysecond=0                  +000 08:00:00                                                               TRUE
SUNDAY_WINDOW        freq=daily;byday=sat;byhour=2;byminute=30; bysecond=0                  +000 08:00:00                                                               TRUE
THURSDAY_WINDOW      freq=daily;byday=thu;byhour=2;byminute=30; bysecond=0                  +000 04:00:00                                                               TRUE
TUESDAY_WINDOW       freq=daily;byday=tue;byhour=2;byminute=30; bysecond=0                  +000 04:00:00                                                               TRUE
WEDNESDAY_WINDOW     freq=daily;byday=wed;byhour=2;byminute=30; bysecond=0                  +000 04:00:00                                                               TRUE
WEEKEND_WINDOW       freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0                    +002 00:00:00                                                               FALSE
WEEKNIGHT_WINDOW     freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=22;byminute=0; bysecond=0  +000 08:00:00                                                               FALSE

9行が選択されました。

Statspack

Statspack導入

RDSではPerformance Insightsという非常に便利なパフォーマンス分析ツールを利用できますが、Web上にも情報量が多いStatspackを導入されたいという方もいらっしゃるかと存じます。

導入についての流れはOracle Statspack のセットアップに公式案内がございますので、そちらを参考に実施します。

なお、PERFSTATユーザのデフォルト表領域はSYSAUXで作成されます。つまり、SYSAUXにStatspack関連情報が格納されます。これについては、気持ち悪いと感じられる方もいらっしゃるかと存じます。

後々この格納先を変更することも可能とは推察しますが(表領域作成、クォータ設定、デフォルト表領域変更、既存テーブルの表領域変更)、手動で色々と変更するリスクを考えると、あくまで私個人の意見としては、このまま利用されるのもよろしいかと存じます。

※万が一、Statspack関係で何かあった際、サポートに共有する背景が減るため、結果として楽になるかもしれないというのが本音です。

SQL> select username, default_tablespace, temporary_tablespace, profile, authentication_type from dba_users where username = 'PERFSTAT';

USERNAME   DEFAULT_TABLESPACE                                           TEMPORARY_TABLESPACE                                 PROFILE    AUTHENTICATION_T
---------- ------------------------------------------------------------ ------------------------------------------------------------ ---------- ----------------
PERFSTAT   SYSAUX                                                       TEMP                                                 DEFAULT    PASSWORD

Statspackスナップショット作成ジョブ

公式情報としてStatspack レポートの生成でスナップショット作成ジョブのサンプルが提供されていますが、非推奨のDBMS_JOBを利用したものです。

したがって、DBMS_SCHEDULERを利用したサンプルを記載致します。また、スナップショット作成と併せて、スナップショット削除のジョブも実装することが多いと存じますため、そちらのサンプルも記載致します。

下記は、毎時0分にスナップショットを作成し(レベル7)、毎日0時に90日経過したスナップショットを削除するジョブのサンプルです。CREATE JOB権限を保有しているPERFSTATでログインして実行することを想定しています(grant create job to perfstat;)。

SQL> select job_name, job_action, next_run_date, enabled from dba_scheduler_jobs where owner = 'PERFSTAT';

レコードが選択されませんでした。

SQL> begin
  2    dbms_scheduler.create_job (
  3     job_name        => 'statspack_snapshot',
  4     job_type        => 'plsql_block',
  5     job_action      => 'begin statspack.snap(i_snap_level=>7); end;',
  6     start_date      => null,
  7     repeat_interval => 'freq=hourly; byminute=0; bysecond=0',
  8     auto_drop       => false,
  9     enabled         => true
 10    );
 11  end;
 12  /

PL/SQLプロシージャが正常に完了しました。

SQL> begin
  2    dbms_scheduler.create_job (
  3     job_name        => 'statspack_snapshot_purge',
  4     job_type        => 'plsql_block',
  5     job_action      => 'begin statspack.purge(i_num_days=>90); end;',
  6     start_date      => null,
  7     repeat_interval => 'freq=daily; byhour=0; byminute=0; bysecond=0',
  8     auto_drop       => false,
  9     enabled         => true
 10    );
 11  end;
 12  /

PL/SQLプロシージャが正常に完了しました。

SQL> select job_name, job_action, next_run_date, enabled from dba_scheduler_jobs where owner = 'PERFSTAT';

JOB_NAME                  JOB_ACTION                                    NEXT_RUN_DATE                                                       ENABLED
------------------------- --------------------------------------------- --------------------------------------------------------------------------- ----------
STATSPACK_SNAPSHOT        begin statspack.snap(i_snap_level=>7); end;   20-12-29 18:00:00.352110 ASIA/TOKYO                                         TRUE
STATSPACK_SNAPSHOT_PURGE  begin statspack.purge(i_num_days=>90); end;   20-12-30 00:00:00.737920 ASIA/TOKYO                                         TRUE

統計情報取得

おそらく、上記のような対応と共に、ユーザ表領域の作成、業務ユーザの作成、オブジェクトの作成やデータのロード等を、初期作業の一環として実施されるものと存じます。

オブジェクトを作成したスキーマの統計情報取得については意識的に実行されるケースも多いものと存じますが、スキーマの統計情報に加えて、個人的にディクショナリと固定オブジェクトの統計情報も気休めとして最後に取得するようにしています。

ディクショナリと固定オブジェクトを取得するため、具体的には、次のパッケージを利用します。RDSでもオンプレミスと変わりません。

DBMS_STATS.GATHER_DICTIONARY_STATS
DBMS_STATS.GATHER_FIXED_OBJECTS_STATS

次に、ディクショナリと固定オブジェクトの統計情報を取得する例を記載します。

SQL> -- ディクショナリ統計情報
SQL> begin
  2    dbms_stats.gather_dictionary_stats(
  3      options => 'GATHER'
  4    );
  5  end;
  6  /

PL/SQLプロシージャが正常に完了しました。

SQL> -- 固定オブジェクト統計情報
SQL> begin
  2    dbms_stats.gather_fixed_objects_stats;
  3  end;
  4  /

PL/SQLプロシージャが正常に完了しました。

なお、上記に加えてシステムの統計情報をDBMS_STATS.GATHER_SYSTEM_STATSを利用して取得することも可能ですが、下記のようにデフォルト値を推奨する記載があるため、システムの統計情報は取得していません。

Unless there is a good reason to gather manually, Oracle recommends using the defaults for system statistics.

---中略---

Oracle recommends using the defaults for system statistics in most cases.

13.4.2 Guidelines for Gathering System Statistics

まとめ

RDS for Oracleはマネージドサービスのため、作成したら即座に使えるという素晴らしさがあります。しかしながら、意図した通りに動作させるためには、追加での設定が必要になります。

同じような構成のRDS for Oracleを利用することが見込まれる場合、毎回、同じ作業を実施するのも手間となりますので、初期作業を実施した後のRDSから手動スナップショットを作成し、テンプレートとして保存しておくという運用も考えられるかもしれません。

work_memと一時ファイルの容量の関係性について

wannabe — Fri, 25 Dec 2020 00:00:00 +0000

PostgreSQLでのチューニングのアプローチとして、log_temp_filesを0に設定し、ログに記録された一時ファイルの容量を元にwork_memを調整するといったものがあるかと存じます。これで一時ファイルの作成が抑制され、パフォーマンスが向上するケースもございますが、今回、そのアプローチでは解決できない事象が確認できましたので、参考までに記録致します。

結論

ワークロードによる部分もあるかとは存じますが、今回の検証の結論としましては、log_temp_filesによりログ出力された一時ファイルの容量は、必ずしも「work_memで不足している容量」を意味するわけではないことが確認できました。

言い換えますと、log_temp_filesを0に設定することで、一時ファイルが作成されたということは分かりますが、容量はあくまでも参考値であるということを意味します。

したがって、work_memの最適値を探る場合、最終的には、何パターンかの設定値を試していくという原始的なアプローチが必要になるものと推察致します。

また、容量が参考値であるということは、一時ファイルの作成についてログ出力を行うのであれば(-1以外)、log_temp_filesの値を0以外にする意味も薄いのではないかと考えます。

work_memと一時ファイル容量の検証

検証の流れ

具体的には次のような流れにて検証を実施しました。なお、PostgreSQL 11.6を利用して検証を行っています。

log_temp_filesを0に設定する
サンプルテーブルを作成する(100万行)
work_memを1MBに設定する
サンプルテーブルを全件SELECT+ソートする
一時ファイルが作成されたことを確認する(約72MB)
work_memの値を作成された一時ファイルの容量より大きな100MBまで増やす
再度サンプルテーブルを全件SELECT+ソートする
一時ファイルが作成されたことを確認する(約72MB)
work_memの値を更に300MBまで増やす
再度サンプルテーブルを全件SELECT+ソートする
最終的に利用されたメモリ容量を確認する(約162MB)
work_memの値を必要なメモリ量に合わせて162MBにする
再度サンプルテーブルを全件SELECT+ソートする
一時ファイルが作成されないことを確認する
work_memの値を必要なメモリ量より若干少ない160MBにする
再度サンプルテーブルを全件SELECT+ソートする
一時ファイルが作成されたことを確認する(約72MB)

検証の事前準備

まずは、log_temp_filesの設定とサンプルテーブルの作成を行います。

postgres=> show log_temp_files;
 log_temp_files
----------------
 -1
(1 row)


postgres=> set log_temp_files to 0;
SET
postgres=> show log_temp_files;
 log_temp_files
----------------
 0
(1 row)


postgres=> create table sample_table as select seq_number as id, random() as random_number, md5(random()::text) as random_data from generate_series(1, 1000000) as seq_number;
SELECT 1000000

work_mem(1MB)での検証

まず、work_memを1MBに設定した際の挙動を確認します。external merge(一時ファイルでソートを行う処理)が選択されていますが、ソート処理を行う2つのワーカーが更に一時ファイルを作成している様子が見受けられます。つまり、合計3つの一時ファイルが作成されています。

最終的に、ログには合計で75218944(18743296+17203200+39272448)バイト、つまり、約72MBの一時ファイルが作成されている様子が記録されています。

SQL実行

postgres=> set work_mem to 1024;
SET
postgres=> show work_mem;
 work_mem
----------
 1MB
(1 row)


postgres=> explain analyze select 'work_mem: 1MB', * from sample_table order by random_number, random_data;
                                                                QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------
 Gather Merge  (cost=109914.50..207143.59 rows=833334 width=77) (actual time=891.912..1371.145 rows=1000000 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Sort  (cost=108914.48..109956.15 rows=416667 width=77) (actual time=748.924..852.871 rows=333333 loops=3)
         Sort Key: random_number, random_data
         Sort Method: external merge  Disk: 38352kB
         Worker 0:  Sort Method: external merge  Disk: 16800kB
         Worker 1:  Sort Method: external merge  Disk: 18304kB
         ->  Parallel Seq Scan on sample_table  (cost=0.00..14476.67 rows=416667 width=77) (actual time=0.014..98.434 rows=333333 loops=3)
 Planning Time: 0.123 ms
 Execution Time: 1431.612 ms
(11 rows)

PostgreSQLログ

2020-12-25 11:15:15 UTC::@:[5608]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp5608.0", size 18743296
2020-12-25 11:15:15 UTC::@:[5608]:STATEMENT: explain analyze select 'work_mem: 1MB', * from sample_table order by random_number, random_data;
2020-12-25 11:15:15 UTC::@:[5609]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp5609.0", size 17203200
2020-12-25 11:15:15 UTC::@:[5609]:STATEMENT: explain analyze select 'work_mem: 1MB', * from sample_table order by random_number, random_data;
2020-12-25 11:15:15 UTC:xx.xx.xx.xx(63725):postgres@postgres:[19529]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp19529.1", size 39272448
2020-12-25 11:15:15 UTC:xx.xx.xx.xx(63725):postgres@postgres:[19529]:STATEMENT: explain analyze select 'work_mem: 1MB', * from sample_table order by random_number, random_data;

work_mem(100MB)での検証

さて、前述の検証にて、作成された一時ファイルは合計約72MBであることが確認できました。現在のwork_memは1MBなので、バッファも含んでwork_memを100MBに設定して確認を行ってみます。

ログ出力される一時ファイルの容量が、単純に不足しているメモリ量を表しているのであれば、これで一時ファイルが作成されなくなることが予測されます。

しかし、ワーカーが更に一時ファイルを作成するようなことはなくなりましたが、依然として一時ファイルが作成されている様子が確認できます。容量は75153408バイト、つまり、約72MBであり、先程の結果と変わりません。

SQL実行

postgres=> set work_mem to 102400;
SET
postgres=> show work_mem;
 work_mem
----------
 100MB
(1 row)


postgres=> explain analyze select 'work_mem: 100MB', * from sample_table order by random_number, random_data;
                                                          QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=119967.84..122467.84 rows=1000000 width=77) (actual time=939.331..1066.320 rows=1000000 loops=1)
   Sort Key: random_number, random_data
   Sort Method: external merge  Disk: 73392kB
   ->  Seq Scan on sample_table  (cost=0.00..20310.00 rows=1000000 width=77) (actual time=0.012..126.879 rows=1000000 loops=1)
 Planning Time: 0.038 ms
 Execution Time: 1115.965 ms
(6 rows)

PostgreSQLログ

2020-12-25 11:20:40 UTC:xx.xx.xx.xx(63725):postgres@postgres:[19529]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp19529.2", size 75153408
2020-12-25 11:20:40 UTC:xx.xx.xx.xx(63725):postgres@postgres:[19529]:STATEMENT: explain analyze select 'work_mem: 100MB', * from sample_table order by random_number, random_data;

work_mem(300MB)での検証

直前の結果から、作成された一時ファイルは約72MBであることが確認できましたが、もはや信じられなくなりましたので、一気にwork_memを300MBに増やして確認を行ってみます。

結果として、無事、全てメモリ上で処理が実行されるようになりました。実行計画から、必要なメモリは165202kB、つまり、約162MBであったことが分かりました。

一時ファイルは作成されていませんので、ログ出力はありません。

SQL実行

postgres=> set work_mem to 307200;
SET
postgres=> show work_mem;
 work_mem
----------
 300MB
(1 row)


postgres=> explain analyze select 'work_mem: 300MB', * from sample_table order by random_number, random_data;
                                                          QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=119967.84..122467.84 rows=1000000 width=77) (actual time=797.481..949.152 rows=1000000 loops=1)
   Sort Key: random_number, random_data
   Sort Method: quicksort  Memory: 165202kB
   ->  Seq Scan on sample_table  (cost=0.00..20310.00 rows=1000000 width=77) (actual time=0.010..143.166 rows=1000000 loops=1)
 Planning Time: 0.037 ms
 Execution Time: 992.700 ms
(6 rows)

work_mem(162MB)での検証

必要なメモリ量が分かったので、work_memを162MBに設定して確認してみます。無事にメモリ上だけで完結していることが確認できました。したがって、当該SQLでは約162MBが適正値であろうということが分かりました。

SQL実行

postgres=> set work_mem to 165888;
SET
postgres=> show work_mem;
 work_mem
----------
 162MB
(1 row)


postgres=> explain analyze select 'work_mem: 162MB', * from sample_table order by random_number, random_data;
                                                          QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=119967.84..122467.84 rows=1000000 width=77) (actual time=798.385..948.632 rows=1000000 loops=1)
   Sort Key: random_number, random_data
   Sort Method: quicksort  Memory: 164324kB
   ->  Seq Scan on sample_table  (cost=0.00..20310.00 rows=1000000 width=77) (actual time=0.011..155.280 rows=1000000 loops=1)
 Planning Time: 0.038 ms
 Execution Time: 990.769 ms
(6 rows)

work_mem(160MB)での検証

最後に、work_memを必要量より若干少ない160MBに設定して確認を行ってみます。2MB程度足らないだけですが、一時ファイルが作成されてしまったことが確認できました。

当該一時ファイルは、ログ出力上、75153408バイトとなっています。これまで作成されてきた一時ファイルと同様、約72MBです。正直に受け止め、work_memから約72MBあふれているものと捉えてしまうと、work_memは162MBで済むにも関わらず、232MB(160MB+72MB)と設定してしまうことになります。

SQL実行

postgres=> set work_mem to 163840;
SET
postgres=> show work_mem;
 work_mem
----------
 160MB
(1 row)


postgres=> explain analyze select 'work_mem: 160MB', * from sample_table order by random_number, random_data;
                                                          QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=119967.84..122467.84 rows=1000000 width=77) (actual time=1055.562..1185.475 rows=1000000 loops=1)
   Sort Key: random_number, random_data
   Sort Method: external merge  Disk: 73392kB
   ->  Seq Scan on sample_table  (cost=0.00..20310.00 rows=1000000 width=77) (actual time=0.011..144.824 rows=1000000 loops=1)
 Planning Time: 0.038 ms
 Execution Time: 1236.575 ms
(6 rows)

PostgreSQLログ

2020-12-25 11:34:48 UTC:xx.xx.xx.xx(63725):postgres@postgres:[19529]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp19529.3", size 75153408
2020-12-25 11:34:48 UTC:xx.xx.xx.xx(63725):postgres@postgres:[19529]:STATEMENT: explain analyze select 'work_mem: 160MB', * from sample_table order by random_number, random_data;

まとめ

ワークロードによるかとは存じますが、今回のケースですと、次のことが確認できました。PostgreSQLは奥が深いですね。

log_temp_filesの設定で出力された一時ファイルの容量は、必ずしもwork_memで不足している容量を意味しない
work_memの最適値を探るには、何パターンかの設定値を試していくという原始的なアプローチが必要になる
一時ファイル作成についてログ出力するのであれば、log_temp_filesを0以外に設定する意味は薄い

Aurora PostgreSQLの統計情報についてのTips

wannabe — Wed, 02 Dec 2020 00:00:00 +0000

Aurora PostgreSQLは、クラスタにリードレプリカを追加することにより、容易に読み取り処理をスケールアウトすることができます。また、プライマリインスタンスに障害が発生した場合でも、リードレプリカがあればフェイルオーバーが実施され、ダウンタイムを常に短くすることができます。非常に便利なサービスではありますが、統計情報についての仕様に個人的に意外性を感じましたので、Tipsとしてまとめてみました。

まとめ

Aurora PostgreSQLの統計情報については、下記のような特徴があります。特にpg_stat_all_tablesの特徴を把握していなかったことで、プライマリとリードレプリカでpg_stat_all_tablesから取得できる差異が発生していることより、リードレプリカにおいては実行計画が適切に選ばれないのではないかと勘違いしていました。

実行計画に用いられる統計情報はpg_statisticに記録されている
pg_statisticの情報はプライマリとリードレプリカで同期されている
pg_statisticの情報は停止・再起動しても保持される
pg_stat_all_tablesの情報はプライマリとリードレプリカで同期されない
pg_stat_all_tablesの情報は停止・再起動等により削除される
手動で統計情報を更新できないシステムカタログが存在する

pg_stat_all_tablesについて

pg_stat_all_tablesは、下記の記載通り、テーブルごとの統計情報を表示するビューです。最後にバキューム処理や統計情報更新が行われた時刻等を確認する際に参照することが多いビューかと存じます。

pg_stat_all_tablesビューは現在のデータベース内のテーブル（TOASTテーブルを含む）毎に１行の形式で、特定のテーブルへのアクセスに関する統計情報を表示します。 pg_stat_user_tablesおよびpg_stat_sys_tablesビューにも同じ情報が含まれますが、それぞれユーザテーブルとシステムテーブルのみにフィルタされています。

28.2. 統計情報コレクタ

実際に、Aurora PostgreSQLのプライマリとリードレプリカで、当該ビューの中身を確認いただくと分かるかと存じますが、起動時間が長く、自動バキュームが行われた回数が多くなるにつれて、内容に大きな差異が生じてきます。これは、冒頭にも記載させていただいた下記の特徴のためです。

pg_stat_all_tablesの情報はプライマリとリードレプリカで同期されない
pg_stat_all_tablesの情報は停止・再起動等により削除される

ビューであるため、実情報が同期されていればユーザ側で取得する結果に差異は生じないのが普通ですが、これは、恐らく次の仕様によるものと推測致します。

統計情報コレクタは収集した情報を他のPostgreSQLプロセスに一時ファイルを介して送信します。これらのファイルはstats_temp_directoryで指名されたディレクトリ、デフォルトはpg_stat_tmp内に格納されます。性能を向上させるために、stats_temp_directoryをRAMベースのファイルシステムを指し示すようにして、物理的なI/O要求を減らすことができます。サーバが正しくシャットダウンした際は、統計情報がサーバの再起動を跨がって保持されるように、統計情報データの永続的なコピーがpg_statサブディレクトリに格納されます。サーバ起動時にリカバリが実施される場合(例えば、即時シャットダウンやサーバクラッシュ、ポイントインタイムリカバリ)、統計カウンタをすべてリセットします。

28.2. 統計情報コレクタ

Aurora PostgreSQLはクラスターボリュームというストレージをプライマリとリードレプリカで共有しています。しかし、次の記載通り、一時ファイルは別です。上述の通り、統計情報は他のPostgreSQLプロセスに一時ファイルを介して送信されるため、プライマリとリードレプリカで差異が生じているものと考えられます。

Aurora PostgreSQL は、非永続的な一時ファイル用に別の一時ストレージを使用します。

Aurora PostgreSQL 用の一時ストレージの制限

上記から、実運用においてpg_stat_all_tablesを確認する際には、次のような方針にした方が良いものと考えられます。

プライマリインスタンスの情報を確認する
フェイルオーバー直後のプライマリインスタンスの情報は実態とかけ離れている可能性があることを考慮する

pg_statisticについて

一方でpg_statisticですが、こちらは下記の記載通り、実際の統計データを保持している「テーブル」です。また、プランナに利用されるデータを保持しています。

pg_statisticカタログはデータベースの内容に関する統計データを保存します。項目はANALYZEで作成され、後に問い合わせプランナで使用されます。

52.50. pg_statistic

こちらも、実際にAurora PostgreSQLのプライマリとリードレプリカで、当該テーブルや当該テーブルを見やすくしたpg_statsビューの中身を確認いただくと分かるかと存じますが、プライマリ側で情報に変更があっても、きちんと同期されています。

また、実行計画も正常にプライマリとリードレプリカで同じものが選択されることが確認できます。そして、テーブルに保持されている情報ですので、インスタンスを停止したり再起動したりしても、情報がなくなるようなことはありません。

上記から、実運用において「本当に統計情報がプライマリとリードレプリカで同期されているのか」という点を確認する際には、次のような方針にした方が良いものと考えられます。

pg_statistic(またはpg_stats)の中身が同じことを確認する
explainを利用して実際に導かれる実行計画が同じことを確認する

手動の統計情報更新について

バッチ処理等でテーブルのデータを大量に更新後、手動でデータベース単位で統計情報を更新をするようなケースもあるものと存じます。この場合ですが、マスターユーザを利用している場合でも、次のように、特定のシステムカタログについては権限の問題から対象外となることが確認できました。

postgres=> analyze;
WARNING:  skipping "pg_authid" --- only superuser can analyze it
WARNING:  skipping "pg_subscription" --- only superuser can analyze it
WARNING:  skipping "pg_database" --- only superuser can analyze it
WARNING:  skipping "pg_db_role_setting" --- only superuser can analyze it
WARNING:  skipping "pg_tablespace" --- only superuser can analyze it
WARNING:  skipping "pg_pltemplate" --- only superuser can analyze it
WARNING:  skipping "pg_auth_members" --- only superuser can analyze it
WARNING:  skipping "pg_shdepend" --- only superuser can analyze it
WARNING:  skipping "pg_shdescription" --- only superuser can analyze it
WARNING:  skipping "pg_replication_origin" --- only superuser can analyze it
WARNING:  skipping "pg_shseclabel" --- only superuser can analyze it

したがって、上記システムカタログの統計情報については、自動バキュームワーカーによる自動更新を行う以外に更新手段がない形となります。自動バキュームを無効にするケースは少ないかとは存じますが、無効にして手動による更新のみを行う運用の場合、上記のシステムカタログが肥大化したり、実態と統計情報に乖離が生じたりする可能性について考慮する必要があります。

参考: 確認方法

pg_stat_all_tablesやpg_statisticの仕様について確認した際の方法について記載します(プライマリとリードレプリカの処理を時系列順に横並びで表示)。

-- プライマリ                                                                                                           -- リードレプリカ
postgres=> select inet_server_addr();                                                                                   postgres=> select inet_server_addr();
 inet_server_addr                                                                                                        inet_server_addr
------------------                                                                                                      ------------------
 192.168.xx.xx                                                                                                           192.168.yy.yy
(1 row)                                                                                                                 (1 row)


postgres=> \x                                                                                                           postgres=> \x
Expanded display is on.                                                                                                 Expanded display is on.

-- テーブル作成
postgres=> create table public.stats_test_table (col1 int primary key,col2 varchar(10));
CREATE TABLE
postgres=> \d public.stats_test_table                                                                                   postgres=> \d public.stats_test_table
                 Table "public.stats_test_table"                                                                                         Table "public.stats_test_table"
 Column |         Type          | Collation | Nullable | Default                                                         Column |         Type          | Collation | Nullable | Default
--------+-----------------------+-----------+----------+---------                                                       --------+-----------------------+-----------+----------+---------
 col1   | integer               |           | not null |                                                                 col1   | integer               |           | not null |
 col2   | character varying(10) |           |          |                                                                 col2   | character varying(10) |           |          |
Indexes:                                                                                                                Indexes:
    "stats_test_table_pkey" PRIMARY KEY, btree (col1)                                                                       "stats_test_table_pkey" PRIMARY KEY, btree (col1)


-- 作成時点で`seq_scan`に差異あり
postgres=> select * from pg_stat_all_tables where relname = 'stats_test_table';                                         postgres=> select * from pg_stat_all_tables where relname = 'stats_test_table';
-[ RECORD 1 ]-------+-----------------                                                                                  -[ RECORD 1 ]-------+-----------------
relid               | 90141                                                                                             relid               | 90141
schemaname          | public                                                                                            schemaname          | public
relname             | stats_test_table                                                                                  relname             | stats_test_table
seq_scan            | 1                                                                                                 seq_scan            | 0
seq_tup_read        | 0                                                                                                 seq_tup_read        | 0
idx_scan            | 0                                                                                                 idx_scan            | 0
idx_tup_fetch       | 0                                                                                                 idx_tup_fetch       | 0
n_tup_ins           | 0                                                                                                 n_tup_ins           | 0
n_tup_upd           | 0                                                                                                 n_tup_upd           | 0
n_tup_del           | 0                                                                                                 n_tup_del           | 0
n_tup_hot_upd       | 0                                                                                                 n_tup_hot_upd       | 0
n_live_tup          | 0                                                                                                 n_live_tup          | 0
n_dead_tup          | 0                                                                                                 n_dead_tup          | 0
n_mod_since_analyze | 0                                                                                                 n_mod_since_analyze | 0
last_vacuum         |                                                                                                   last_vacuum         |
last_autovacuum     |                                                                                                   last_autovacuum     |
last_analyze        |                                                                                                   last_analyze        |
last_autoanalyze    |                                                                                                   last_autoanalyze    |
vacuum_count        | 0                                                                                                 vacuum_count        | 0
autovacuum_count    | 0                                                                                                 autovacuum_count    | 0
analyze_count       | 0                                                                                                 analyze_count       | 0
autoanalyze_count   | 0                                                                                                 autoanalyze_count   | 0


postgres=> select * from pg_stats where tablename = 'stats_test_table';                                                 postgres=> select * from pg_stats where tablename = 'stats_test_table';
(0 rows)                                                                                                                (0 rows)

-- テスト用の行挿入ファンクション作成
postgres=> create function public.stats_test_insert() returns int as
postgres-> '
postgres'>   declare i int;
postgres'>   begin
postgres'>     for i in 1..10000 loop
postgres'>       insert into public.stats_test_table values(i,''test'');
postgres'>     end loop;
postgres'>     return 0;
postgres'>   end;
postgres'> '
postgres-> language 'plpgsql'
postgres-> ;
CREATE FUNCTION
postgres=> select public.stats_test_insert();
-[ RECORD 1 ]-----+--
stats_test_insert | 0


-- `pg_stat_all_tables`側は`n_tup_ins`、`n_live_tup`に差異が生じている
postgres=> select * from pg_stat_all_tables where relname = 'stats_test_table';                                         postgres=> select * from pg_stat_all_tables where relname = 'stats_test_table';
-[ RECORD 1 ]-------+-----------------                                                                                  -[ RECORD 1 ]-------+-----------------
relid               | 90141                                                                                             relid               | 90141
schemaname          | public                                                                                            schemaname          | public
relname             | stats_test_table                                                                                  relname             | stats_test_table
seq_scan            | 1                                                                                                 seq_scan            | 0
seq_tup_read        | 0                                                                                                 seq_tup_read        | 0
idx_scan            | 0                                                                                                 idx_scan            | 0
idx_tup_fetch       | 0                                                                                                 idx_tup_fetch       | 0
n_tup_ins           | 10000                                                                                             n_tup_ins           | 0
n_tup_upd           | 0                                                                                                 n_tup_upd           | 0
n_tup_del           | 0                                                                                                 n_tup_del           | 0
n_tup_hot_upd       | 0                                                                                                 n_tup_hot_upd       | 0
n_live_tup          | 10000                                                                                             n_live_tup          | 0
n_dead_tup          | 0                                                                                                 n_dead_tup          | 0
n_mod_since_analyze | 10000                                                                                             n_mod_since_analyze | 0
last_vacuum         |                                                                                                   last_vacuum         |
last_autovacuum     |                                                                                                   last_autovacuum     |
last_analyze        |                                                                                                   last_analyze        |
last_autoanalyze    |                                                                                                   last_autoanalyze    |
vacuum_count        | 0                                                                                                 vacuum_count        | 0
autovacuum_count    | 0                                                                                                 autovacuum_count    | 0
analyze_count       | 0                                                                                                 analyze_count       | 0
autoanalyze_count   | 0                                                                                                 autoanalyze_count   | 0


-- `pg_stats`側は差異なく同期されている
postgres=> select * from pg_stats where tablename = 'stats_test_table';                                                 postgres=> select * from pg_stats where tablename = 'stats_test_table';
-[ RECORD 1 ]----------+-------------------------------------------------                                               -[ RECORD 1 ]----------+-------------------------------------------------
schemaname             | public                                                                                         schemaname             | public
tablename              | stats_test_table                                                                               tablename              | stats_test_table
attname                | col1                                                                                           attname                | col1
inherited              | f                                                                                              inherited              | f
null_frac              | 0                                                                                              null_frac              | 0
avg_width              | 4                                                                                              avg_width              | 4
n_distinct             | -1                                                                                             n_distinct             | -1
most_common_vals       |                                                                                                most_common_vals       |
most_common_freqs      |                                                                                                most_common_freqs      |
histogram_bounds       | {1,100,200,～省略～,9800,9900,10000}                                                               histogram_bounds       | {1,100,200,～省略～,9800,9900,10000}
correlation            | 1                                                                                              correlation            | 1
most_common_elems      |                                                                                                most_common_elems      |
most_common_elem_freqs |                                                                                                most_common_elem_freqs |
elem_count_histogram   |                                                                                                elem_count_histogram   |
-[ RECORD 2 ]----------+-------------------------------------------------                                               -[ RECORD 2 ]----------+-------------------------------------------------
schemaname             | public                                                                                         schemaname             | public
tablename              | stats_test_table                                                                               tablename              | stats_test_table
attname                | col2                                                                                           attname                | col2
inherited              | f                                                                                              inherited              | f
null_frac              | 0                                                                                              null_frac              | 0
avg_width              | 5                                                                                              avg_width              | 5
n_distinct             | 1                                                                                              n_distinct             | 1
most_common_vals       | {test}                                                                                         most_common_vals       | {test}
most_common_freqs      | {1}                                                                                            most_common_freqs      | {1}
histogram_bounds       |                                                                                                histogram_bounds       |
correlation            | 1                                                                                              correlation            | 1
most_common_elems      |                                                                                                most_common_elems      |
most_common_elem_freqs |                                                                                                most_common_elem_freqs |
elem_count_histogram   |                                                                                                elem_count_histogram   |


-- 同じ実行計画が選択されている
postgres=> explain verbose select * from public.stats_test_table where col1 > 1000 and col1 <=2000;                     postgres=> explain verbose select * from public.stats_test_table where col1 > 1000 and col1 <=2000;
-[ RECORD 1 ]-------------------------------------------------------------------------------------------------------    -[ RECORD 1 ]-------------------------------------------------------------------------------------------------------
QUERY PLAN | Index Scan using stats_test_table_pkey on public.stats_test_table  (cost=0.29..41.28 rows=1000 width=9)    QUERY PLAN | Index Scan using stats_test_table_pkey on public.stats_test_table  (cost=0.29..41.28 rows=1000 width=9)
-[ RECORD 2 ]-------------------------------------------------------------------------------------------------------    -[ RECORD 2 ]-------------------------------------------------------------------------------------------------------
QUERY PLAN |   Output: col1, col2                                                                                       QUERY PLAN |   Output: col1, col2
-[ RECORD 3 ]-------------------------------------------------------------------------------------------------------    -[ RECORD 3 ]-------------------------------------------------------------------------------------------------------
QUERY PLAN |   Index Cond: ((stats_test_table.col1 > 1000) AND (stats_test_table.col1 <= 2000))                         QUERY PLAN |   Index Cond: ((stats_test_table.col1 > 1000) AND (stats_test_table.col1 <= 2000))


-- 実行計画を変えるために行を削除する
postgres=> delete from public.stats_test_table where col1 > 2000;
DELETE 8000
-- `pg_stat_all_tables`側での自動バキュームや統計情報更新情報も差異が生じている
postgres=> select * from pg_stat_all_tables where relname = 'stats_test_table';                                         postgres=> select * from pg_stat_all_tables where relname = 'stats_test_table';
-[ RECORD 1 ]-------+------------------------------                                                                     -[ RECORD 1 ]-------+-----------------
relid               | 90141                                                                                             relid               | 90141
schemaname          | public                                                                                            schemaname          | public
relname             | stats_test_table                                                                                  relname             | stats_test_table
seq_scan            | 2                                                                                                 seq_scan            | 0
seq_tup_read        | 10000                                                                                             seq_tup_read        | 0
idx_scan            | 0                                                                                                 idx_scan            | 0
idx_tup_fetch       | 0                                                                                                 idx_tup_fetch       | 0
n_tup_ins           | 10000                                                                                             n_tup_ins           | 0
n_tup_upd           | 0                                                                                                 n_tup_upd           | 0
n_tup_del           | 8000                                                                                              n_tup_del           | 0
n_tup_hot_upd       | 0                                                                                                 n_tup_hot_upd       | 0
n_live_tup          | 2000                                                                                              n_live_tup          | 0
n_dead_tup          | 0                                                                                                 n_dead_tup          | 0
n_mod_since_analyze | 0                                                                                                 n_mod_since_analyze | 0
last_vacuum         |                                                                                                   last_vacuum         |
last_autovacuum     | 2020-12-01 21:24:09.70559+09                                                                      last_autovacuum     |
last_analyze        |                                                                                                   last_analyze        |
last_autoanalyze    | 2020-12-01 21:24:09.730183+09                                                                     last_autoanalyze    |
vacuum_count        | 0                                                                                                 vacuum_count        | 0
autovacuum_count    | 1                                                                                                 autovacuum_count    | 0
analyze_count       | 0                                                                                                 analyze_count       | 0
autoanalyze_count   | 2                                                                                                 autoanalyze_count   | 0


-- `pg_stats`側は差異なく同期されている
postgres=> select * from pg_stats where tablename = 'stats_test_table';                                                 postgres=> select * from pg_stats where tablename = 'stats_test_table';
-[ RECORD 1 ]----------+-------------------------------------------------                                               -[ RECORD 1 ]----------+-------------------------------------------------
schemaname             | public                                                                                         schemaname             | public
tablename              | stats_test_table                                                                               tablename              | stats_test_table
attname                | col1                                                                                           attname                | col1
inherited              | f                                                                                              inherited              | f
null_frac              | 0                                                                                              null_frac              | 0
avg_width              | 4                                                                                              avg_width              | 4
n_distinct             | -1                                                                                             n_distinct             | -1
most_common_vals       |                                                                                                most_common_vals       |
most_common_freqs      |                                                                                                most_common_freqs      |
histogram_bounds       | {1,20,40,～省略～,1960,1980,2000}                                                                  histogram_bounds       | {1,20,40,～省略～,1960,1980,2000}
correlation            | 1                                                                                              correlation            | 1
most_common_elems      |                                                                                                most_common_elems      |
most_common_elem_freqs |                                                                                                most_common_elem_freqs |
elem_count_histogram   |                                                                                                elem_count_histogram   |
-[ RECORD 2 ]----------+-------------------------------------------------                                               -[ RECORD 2 ]----------+-------------------------------------------------
schemaname             | public                                                                                         schemaname             | public
tablename              | stats_test_table                                                                               tablename              | stats_test_table
attname                | col2                                                                                           attname                | col2
inherited              | f                                                                                              inherited              | f
null_frac              | 0                                                                                              null_frac              | 0
avg_width              | 5                                                                                              avg_width              | 5
n_distinct             | 1                                                                                              n_distinct             | 1
most_common_vals       | {test}                                                                                         most_common_vals       | {test}
most_common_freqs      | {1}                                                                                            most_common_freqs      | {1}
histogram_bounds       |                                                                                                histogram_bounds       |
correlation            | 1                                                                                              correlation            | 1
most_common_elems      |                                                                                                most_common_elems      |
most_common_elem_freqs |                                                                                                most_common_elem_freqs |
elem_count_histogram   |                                                                                                elem_count_histogram   |


-- 同じ実行計画が選択されている
postgres=> explain verbose select * from public.stats_test_table where col1 > 1000 and col1 <=2000;                     postgres=> explain verbose select * from public.stats_test_table where col1 > 1000 and col1 <=2000;
-[ RECORD 1 ]------------------------------------------------------------------------------                             -[ RECORD 1 ]------------------------------------------------------------------------------
QUERY PLAN | Seq Scan on public.stats_test_table  (cost=0.00..41.00 rows=1000 width=9)                                  QUERY PLAN | Seq Scan on public.stats_test_table  (cost=0.00..41.00 rows=1000 width=9)
-[ RECORD 2 ]------------------------------------------------------------------------------                             -[ RECORD 2 ]------------------------------------------------------------------------------
QUERY PLAN |   Output: col1, col2                                                                                       QUERY PLAN |   Output: col1, col2
-[ RECORD 3 ]------------------------------------------------------------------------------                             -[ RECORD 3 ]------------------------------------------------------------------------------
QUERY PLAN |   Filter: ((stats_test_table.col1 > 1000) AND (stats_test_table.col1 <= 2000))                             QUERY PLAN |   Filter: ((stats_test_table.col1 > 1000) AND (stats_test_table.col1 <= 2000))


postgres=>                                                                                                              postgres=>

OracleとPostgreSQLのデッドロックの比較

wannabe — Sat, 20 Jun 2020 00:00:00 +0000

本記事では、OracleとPostgreSQLのデッドロックを簡単に比較した内容について記載していきます。それぞれ、業務システムで良く使われている有償/無償のRDBMSの筆頭で、移行も盛んに行われていますが、デッドロック時の挙動に若干の違いがあります。実運用時にデッドロックが多発するようなことはないと思いますが、万が一発生した時に、頭の片隅に置いてあると、役に立つかもしれません。

OracleとPostgreSQLのデッドロックまとめ

項目	Oracle	PostgreSQL
デッドロック検知	自動	自動
デッドロックタイムアウト時間	設定できない(1～2秒程度)	設定できる(deadlock_timeout)(デフォルト1秒)
デッドロック後のトランザクション	ロールバックされない	中断される
デッドロックにより影響を受けるトランザクション	デッドロックを誘発させた方	いずれか
デッドロックのログ	アラートログ、トレースファイル	サーバログ

デッドロック検知

OracleもPostgreSQLも、デッドロックはデータベースにより自動的に検知されます。したがって、ユーザ側によるデッドロック確認機能の実装は必要ありません。

デッドロックタイムアウト時間

デッドロックのタイムアウト時間(デッドロックだとみなすまでの時間)ですが、データベース上、Oracleは明示的な設定ができませんが、PostgreSQLは明示的な設定ができます。

Oracleのデッドロックタイムアウト時間

Oracleはデッドロックを数秒(おおよそ1～2秒)以内で検知します。具体的な秒数について英語情報も含めて検索しましたが、下記のフォーラムレベルのもの(1～2秒)しか見当たりませんでした。個人的な体感としても、毎回1～2秒以内には検知されるように思います。

Usually, Oracle takes a second or two to detect a deadlock and throws the error.

Deadlocks in Oracle - Stack Overflow

PostgreSQLのデッドロックタイムアウト時間

PostgreSQLはdeadlock_timeoutパラメータを設定することにより、デッドロック検知までの時間を明示的に設定することができます。デフォルトは1秒です。

パラメータのコンテキストはsuperuserであるため、セッションごとに変更するといったようなことはできません。あくまで、データベース全体に統一的に設定されます。

デッドロック後のトランザクション

検知後のトランザクションの扱いについては、OracleとPostgreSQLで明確に相違があります。

Oracleはトランザクション自体はロールバックせず、あくまでデッドロックを検知したSQL文がロールバックされます。したがって、検知後もSQL文の発行は可能となります。しかし、デッドロックを検知したトランザクションを明示的にコミットかロールバックしない限り、もう片方のトランザクションはロックを待機し続けます。

PostgreSQLはトランザクション自体が強制的に中断されます。したがって、検知後はロールバック操作以外、一切のSQL文が受け付けられなくなります。しかし、もう片方のトランザクションはロックを取得できるため、そちらはほぼ影響なく操作を続けることができます。

Oracle上のデッドロック後のトランザクション

Oracle側の実際の動きを見てみましょう。次の例では、テーブルfooとbarについて、トランザクションAとBがたすき掛けで排他ロックを取得しようとしています。

-- トランザクションA                         -- トランザクションB
SQL> lock table foo in exclusive mode;

表がロックされました。
                                             SQL> lock table bar in exclusive mode;

                                             表がロックされました。
-- 先にロック
SQL> lock table bar in exclusive mode;
                                             -- 後にロック
                                             SQL> lock table foo in exclusive mode;
lock table bar in exclusive mode
*
行1でエラーが発生しました。:
ORA-00060: リソース待機の間にデッドロックが検出されました。

SQL> insert into foo values (1, null);

1行が作成されました。

SQL> rollback;

ロールバックが完了しました。
                                             -- トランザクションAロールバック後にロック取得
                                             表がロックされました。

デッドロックを検知したトランザクションA側は、トランザクション全体はロールバックされませんでした。したがって、トランザクションA側は既にロック取得済みのfooテーブルに行を挿入できましたし、トランザクションB側はfooテーブルに対するロック取得を待機し続け、トランザクションAが完了した後にロックを取得しています。

PostgreSQL上のデッドロック後のトランザクション

PostgreSQL側の実際の動きを見てみましょう。次の例では、テーブルfooとbarについて、トランザクションAとBがたすき掛けで排他ロックを取得しようとしています。

-- トランザクションA                              -- トランザクションB
postgres=# begin;                                 postgres=# begin;
BEGIN                                             BEGIN
postgres=# lock table foo in exclusive mode;
LOCK TABLE
                                                  postgres=# lock table bar in exclusive mode;
                                                  LOCK TABLE
-- 先にロック
postgres=# lock table bar in exclusive mode;
                                                  -- 後にロック
                                                  postgres=# lock table foo in exclusive mode;
                                                  ERROR:  deadlock detected
                                                  DETAIL:  Process 7548 waits for ExclusiveLock on relation 16384 of database 13938; blocked by process 7510.
                                                  Process 7510 waits for ExclusiveLock on relation 16387 of database 13938; blocked by process 7548.
                                                  HINT:  See server log for query details.
-- トランザクションB自動中断後に自動的にロック取得
LOCK TABLE
                                                  -- 中断されたトランザクションでは操作できない
                                                  postgres=# insert into bar values(1);
                                                  ERROR:  current transaction is aborted, commands ignored until end of transaction block

デッドロックを検知したトランザクションB側は、トランザクション全体が中断されました。こうなると、ロールバックの操作しか受け付けなくなります。したがって、トランザクションB側で追加で実施したSQL文は無視されていますし、トランザクションA側はbarテーブルに対するロックを自動的に取得できました。

デッドロックにより影響を受けるトランザクション

前述の検証では、OracleとPostgreSQL両方で同じようにデッドロックを発生させても、ロールバックまたは中断させられるトランザクション(影響を受けるトランザクション)は、それぞれ異なる結果となりました。

公式情報の公開記載は見つけられませんでしたが、これは、デッドロック後の対応を行うトランザクションの判定が、OracleとPostgreSQLで異なっているためと推測されます。

Oracleは「デッドロックを誘発させたトランザクション」について対処し、PostgreSQLは「デッドロックに関わったトランザクションのどちらか」について対処するというものです(※誤りがあったら申し訳ございません)。

Oracle上でデッドロックにより影響を受けるトランザクション

If your ORA-00060 is caused by competing resources, the perpetual embrace happens when the aborted task (Task B) attempts to lock a row which is being held by another task (Task A), which, in-turn, is waiting for task B to release a lock. To prevent a perpetual wait, Oracle aborts the transaction that caused the deadlock.

Oracle deadlocks tips

上記の記載を見ると、中断されるトランザクションは、競合するトランザクションが既にロックしている行に対してロックを試みた側というように捉えられます。「先に仕掛けた方が悪い」ということですね。実際のデッドロック検証時もそのような形でロールバックが行われています。

PostgreSQL上でデッドロックにより影響を受けるトランザクション

PostgreSQLの場合は、ロック待機が1秒を超えるとデットロックが起こってるんじゃないか考えて、デッドロックの有無を確認するチェックが実行されます。このチェックのロジックが走った結果、デットロックが見つかると、どれかのセッションがABORTされ、残ったセッションは継続できる、ということになります。つまり、このデットロックの輪の確認が一秒に1回チェックが走り、問題があればデッドロックを破る、という処理が行われています。

6. ロック制御・PostgreSQL Internals

上記の記載を見ると、中断されるトランザクションは、先にデータベースによるチェックで見つかった側というように捉えられます。実際のデッドロック検証時も、Oracleとは違い、被害を受けた側(トランザクションB)のトランザクションが中断されています。

ちなみに、上記では1秒と記載がありますが、これはdeadlock_timeoutのデフォルト値が1秒だからであり、この値を変更するとこの検証間隔も長くなります。

デッドロックのログ

デッドロックはロジックの設計ミスを暗示するものであるため、デッドロックの検出を監視し、後から情報を確認するというケースもあるかと思います。

Oracleはアラートログにデッドロックが検出されたということが出力され、詳細な情報はトレースファイルに記録されるという形となります。

PostgreSQLはサーバログにデッドロックが検出されたということが出力され、詳細な情報(Oracleに比べると簡易的ですが)も同じくサーバログに記録されるという形となります。

Oracle上のデッドロックのログ

Oracleでは、まず、アラートログ上に次のようなメッセージが出力されます。したがって、よくある運用通り、アラートログにORA-という出力があるかという監視を行えば、デッドロックに気が付くことができます。

Oracle上のデッドロックのアラートログ出力例

Sat Jun 13 12:24:05 2020
ORA-00060: Deadlock detected. More info in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_19394.trc.

その上で、詳細な情報はアラートログに出力されたトレースファイルに記録されます。

Oracle上のデッドロックのトレースファイル出力例

*** 2020-06-13 12:24:05.843
*** SESSION ID:(39.2553) 2020-06-13 12:24:05.843
*** CLIENT ID:() 2020-06-13 12:24:05.843
*** SERVICE NAME:(SYS$USERS) 2020-06-13 12:24:05.843
*** MODULE NAME:(sqlplus@oracle01 (TNS V1-V3)) 2020-06-13 12:24:05.843
*** ACTION NAME:() 2020-06-13 12:24:05.843



*** 2020-06-13 12:24:05.843
DEADLOCK DETECTED ( ORA-00060 )

[Transaction Deadlock]

The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:

Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TM-00012232-00000000        28      39     X             29       1           X
TM-00012234-00000000        29       1     X             28      39           X

session 39: DID 0001-001C-00000C5F      session 1: DID 0001-001D-00000410
session 1: DID 0001-001D-00000410       session 39: DID 0001-001C-00000C5F

Rows waited on:
  Session 39: obj - rowid = 00012234 - AAAAAAAAAAAAAAAAAA
  (dictionary objn - 74292, file - 0, block - 0, slot - 0)
  Session 1: obj - rowid = 00012232 - AAAAAAAAAAAAAAAAAA
  (dictionary objn - 74290, file - 0, block - 0, slot - 0)

----- Information for the OTHER waiting sessions -----
Session 1:
  sid: 1 ser: 5545 audsid: 4294967295 user: 0/SYS flags: 0x41
  pid: 29 O/S info: user: oracle, term: UNKNOWN, ospid: 19396
    image: oracle@oracle01 (TNS V1-V3)
  client details:
    O/S info: user: oracle, term: pts/1, ospid: 19395
    machine: oracle01 program: sqlplus@oracle01 (TNS V1-V3)
    application name: sqlplus@oracle01 (TNS V1-V3), hash value=1634161439
  current SQL:
  lock table foo in exclusive mode

----- End of information for the OTHER waiting sessions -----

Information for THIS session:

----- Current SQL Statement for this session (sql_id=5g9s5xfpspx7s) -----
lock table bar in exclusive mode

主に次のようなことが分かります。

*** SESSION ID:(39.2553)
- セッション識別子39がデッドロックにより影響を受けた
Deadlock graph
- セッション識別子1と39の間でデッドロックが発生した
Information for the OTHER waiting sessions
- セッション識別子1はlock table foo in exclusive modeを実行していた
Current SQL Statement for this session
- セッション識別子39はlock table bar in exclusive modeを実行していた

PostgreSQL上のデッドロックのログ

PostgreSQLでは、log_lock_waitsのパラメータをonに設定すると、deadlock_timeoutよりも長い時間ロック状態となっているSQL文をログ出力できます。サーバログ上に全ての情報が出力されます。

内容はOracleより非常にシンプルです。デッドロック検出自体はERROR: deadlock detectedで記録されるため、こちらも良くある通り、ERROR:で監視していれば気が付くことができます。

PostgreSQL上のデッドロックのサーバログ出力例

2020-06-15 02:01:56 UTC:xx.xx.xx.xx(55590):postgres@postgres:[29366]:LOG: process 29366 still waiting for ExclusiveLock on relation 28685 of database 14007 after 10.061 ms
2020-06-15 02:01:56 UTC:xx.xx.xx.xx(55590):postgres@postgres:[29366]:DETAIL: Process holding the lock: 29052. Wait queue: 29366.
2020-06-15 02:01:56 UTC:xx.xx.xx.xx(55590):postgres@postgres:[29366]:STATEMENT: lock table bar in exclusive mode;
2020-06-15 02:01:58 UTC:xx.xx.xx.xx(55582):postgres@postgres:[29052]:LOG: process 29052 detected deadlock while waiting for ExclusiveLock on relation 28682 of database 14007 after 10.059 ms
2020-06-15 02:01:58 UTC:xx.xx.xx.xx(55582):postgres@postgres:[29052]:DETAIL: Process holding the lock: 29366. Wait queue: .
2020-06-15 02:01:58 UTC:xx.xx.xx.xx(55582):postgres@postgres:[29052]:STATEMENT: lock table foo in exclusive mode;
2020-06-15 02:01:58 UTC:xx.xx.xx.xx(55582):postgres@postgres:[29052]:ERROR: deadlock detected
2020-06-15 02:01:58 UTC:xx.xx.xx.xx(55582):postgres@postgres:[29052]:DETAIL: Process 29052 waits for ExclusiveLock on relation 28682 of database 14007; blocked by process 29366. Process 29366 waits for ExclusiveLock on relation 28685 of database 14007; blocked by process 29052. Process 29052: lock table foo in exclusive mode; Process 29366: lock table bar in exclusive mode;
2020-06-15 02:01:58 UTC:xx.xx.xx.xx(55582):postgres@postgres:[29052]:HINT: See server log for query details.
2020-06-15 02:01:58 UTC:xx.xx.xx.xx(55582):postgres@postgres:[29052]:STATEMENT: lock table foo in exclusive mode;
2020-06-15 02:01:58 UTC:xx.xx.xx.xx(55590):postgres@postgres:[29366]:LOG: process 29366 acquired ExclusiveLock on relation 28685 of database 14007 after 1553.795 ms
2020-06-15 02:01:58 UTC:xx.xx.xx.xx(55590):postgres@postgres:[29366]:STATEMENT: lock table bar in exclusive mode;

主に次のようなことが分かります。

プロセス29366はlock table bar in exclusive modeを実行しロック取得待機をしていた
プロセス29052はlock table foo in exclusive modeを実行しロック取得待機をしていた
プロセス29052でのロック取得待機中にデッドロックを検出した
プロセス29366はlock table bar in exclusive modeの実行によりロック取得を行えた

まとめ

以上、OracleとPostgreSQLのデッドロックの挙動について簡単に比較してきました。

Oracleはデッドロック時の挙動が分かりやすく、より詳細な情報が得られますが、PostgreSQLはデッドロックのタイムアウト時間をユーザ側で指定できるため、チューニングに幅が出ます。

一長一短だとは思いますが、それぞれのデッドロック時の挙動の違いを考えながら設計を行うと、面白いかもしれません。

Active Directory on EC2をバックアップ・リストアする方法(全台障害)

wannabe — Sat, 21 Mar 2020 00:00:00 +0000

本記事では、EC2にActive Directoryをインストールした環境での、バックアップ・リストア手法の一例について記載します。想定シナリオとしては、FSMOを含め、ドメインコントローラーの役割を持つEC2の全てに障害が発生しているという状況です。つまり、EC2を新規作成し、ドメインコントローラーに昇格するという手段は使えないという状況を想定しています。

Active Directory on EC2 バックアップ・リストアの流れ

全台障害時のActive Directoryのバックアップ・リストアについて、大まかな流れを記載します。なお、Windows Server バックアップを利用しているのは、VSSに対応しており、かつ、サードパーティ製のソフトウェアが不要であるためです。

Windows Server バックアップでバックアップを取得する
EC2のAMIイメージを取得する
AMIイメージからEC2をリストアする
Windows Server バックアップからリストアする

上記のバックアップ・リストア工程を経ると、最終的にWindows Server バックアップを利用してバックアップを取得した段階にActive Directoryの内部状態が戻ります。最新の状態というわけではありませんが、全てのドメインコントローラーが壊れてしまっている壊滅的な状態からの復旧なので、そこは妥協点となります。
なお、ドメインコントローラーを冗長化している状態に戻すためには、追加で次のような作業も必要になりますが、取り急ぎ、上記の時点でActive Directoryは最低限度のレベルで復旧となります。

他ドメインコントローラーの強制降格を行う
他ドメインコントローラーのメタデータを削除する
他ドメインコントローラーの再昇格を行う

それでは、具体的な流れに入ります。

Windows Server バックアップでバックアップを取得する

本項目では次のような内容を記載します。

Windows Server バックアップ専用のEBSを用意する
Windows Server バックアップの機能を追加する
Windows Server バックアップの設定を行う

Windows Server バックアップ専用のEBSを用意する

Windows Server バックアップを利用したバックアップ先は専用ディスクを利用することが推奨されています。今回も専用EBSを用意し、そちらにバックアップを行うように設定します。
まず、EBSのボリュームコンソールからボリュームの作成をクリックします。

特に次の2点に注意しつつ値を埋めてボリュームの作成をクリックします。

ボリュームのサイズは保存世代数等の要件に応じて事前に検証して見積もります
AZはEC2が存在するものと同じものを指定します

今回は次のような値を設定しました。

項目	値
ボリュームタイプ	汎用 SSD (gp2)
サイズ(GiB)	20
アベイラビリティーゾーン	ap-northeast-1a
スナップショット ID	なし
暗号化	有効

作成したEBSを右クリックしボリュームのアタッチをクリックします。

インスタンスにはActive DirectoryがインストールされたEC2を指定します。ここでは、FSMOの役割を保有しているドメインコントローラーを指定することをお勧め致します。リストア後、他ドメインコントローラーを追加する際に、FSMOの強制以降を行う手順が減るためです。
また、デバイスは環境に合わせて指定する必要がありますが、今回は他にEBSをアタッチしていないため、xvdfを指定しました。アタッチをクリックすると該当のインスタンスにEBSをアタッチできます。

Windows Server バックアップの機能を追加する

続いて、上述の手順でEBSをアタッチしたEC2上にWindows Server バックアップの機能を追加します。まずは、サーバマネージャーから管理 > 役割と機能の追加をクリックします。

開始する前にが表示された場合は次へをクリックします。

インストールの種類の選択では役割ベースまたは機能ベースのインストールを選択し次へをクリックします。

対象サーバーの選択では自分自身を選択し次へをクリックします。

サーバーの役割の選択では特に何も追加で選択せずに次へをクリックします。

機能の選択でWindows Server バックアップをにチェックを入れ次へをクリックします。

インストールをクリックします。

インストールが完了するまで待ちます。これで機能を追加することができました。

Windows Server バックアップの設定を行う

ここではスケジュールからWindows Server バックアップを行うように設定します。まずはサーバーマネージャーからツール > Windows Server バックアップでwbadminを起動します。

左ペインのローカルバックアップを選択し、右ペインの操作にあるバックアップスケジュールをクリックします。

はじめにでは次へをクリックします。

バックアップの構成の選択ではカスタムを選択し次へをクリックします。

バックアップする項目を選択では、まず項目の追加をクリックします。

項目の選択ウィンドウが出てくるのでシステム状態を選択しOKをクリックします。

システム状態が追加されていることを確認し次へをクリックします。

バックアップの時間の設定では実際のバックアップ時刻を選択します。今回は日次で20時30分としています。設定したら次へをクリックします。

作成先の種類の選択では、今回は専用EBSを用意しているので、バックアップ専用のハードディスクにバックアップするを選択し次へをクリックします。

作成先ディスクの選択では、まずすべての使用可能なディスクを表示をクリックします。

すべての使用可能なディスクを表示ウィンドウが出てくるので、追加したEBS専用のディスクを選択し、OKをクリックします。

EBS専用のディスクにチェックを入れ、次へをクリックします。

該当のディスクがフォーマットされる旨の警告が出てくるので、はいをクリックします。

内容を確認し完了をクリックします。

スケジュールが作成されるまで待ちます。

これでスケジュールの設定ができました。スケジュール時刻まで待ちましょう。

EC2のAMIイメージを取得する

ここからは、先程の工程で設定したスケジュールでバックアップが正常に取れていることを前提としています。
実際の運用では、手動ではなく自動で作成するパターンがほとんどだと思います。ただし、今回はAMIを手動で取得します。インスタンスを右クリックしイメージ > イメージの作成をクリックします。

今回は再起動しないにチェックを入れてイメージの作成をクリックしAMIイメージを取得します。EBSには、Windows Server バックアップ専用のものが含まれていることを確認します。

Windows Server バックアップからリストアする

本項目では次のような内容を記載します。

AMIイメージからEC2をリストアする
EC2がディレクトリサービス復元モードで起動するように設定する
Windows Server バックアップからリストアする

AMIイメージからEC2をリストアする

AMIイメージからリストアする際の前提としては、次のようなものを想定しています。

リストア対象となるドメインコントローラーのEC2は削除済みである
リストア後はリストア前と同じIPアドレスを利用する
リストア対象を含み全てのドメインコントローラーは削除または停止されておりリストア中に通信は発生し得ない

元々、全てのドメインコントローラーに障害が発生した状況を想定してはいますが、作業中に何らかの意図しない通信が発生し、Active Directoryが完全に破損してしまうようなことがあってはいけないので、全てのドメインコントローラーが削除または停止された状態を想定しています。今回も、該当のEC2は削除してからリストア作業を実施しています。

当該AMIイメージを右クリックし起動からEC2をリストアします。この際、IPアドレスは元々のものを利用するように設定することを忘れないようにします。

起動できました。元々のEC2は既に削除済みであるため、同じサブネットにも作成できます。

EC2がディレクトリサービス復元モードで起動するように設定する

ディレクトリサービス復元モード(DSRM)とは、Active Directoryを停止した状態でOSを起動するモードです。主として、名前の通り、Active Directoryを復元するために用いられます。通常はサーバ起動時にF8キーを押すことでこのモードを選択できるのですが、EC2では起動時にF8キーを押すことができませんので、次のように少し手間がかかります。

復元したEC2からルートボリュームのEBSをデタッチする
デタッチしたEBSを作業用のEC2にアタッチする
ディレクトリサービス復元モードで起動するように設定する

実際に流れを見ていきましょう。

まずは、リストアしたEC2を右クリックしインスタンスの状態 > 停止で停止します。

インスタンスが停止したら、ルートボリュームとして利用しているEBSを右クリックしボリュームのデタッチをクリックします。

デタッチできたら、再度同じEBSを右クリックしボリュームのアタッチをクリックします。アタッチ対象のインスタンスは復元したインスタンス以外の作業用Windows系インスタンスです。なお、作業用インスタンスは復元するサーバとは別バージョンを利用することをお勧め致します(※詳細は「詰まった点」にて後述します)。他にEBSをアタッチしていないため、デバイスはxvdfとします。

EBSをアタッチしたら、作業用インスタンスに接続します。ディスクの管理を開き、アタッチしたEBSがオンラインになっていない場合、右クリックしオンラインでオンライン状態にします。

管理者権限でコマンドプロンプトを起動し、次のコマンドを実行します。D:\Boot\BCDの部分はアタッチしたデバイス名に応じて修正します。なお、このコマンドは起動モードを編集するものです。

bcdedit /store D:\Boot\BCD /set {default} safeboot dsrepair

成功すると次のようにこの操作を正しく終了しました。と出力されます。

C:\Users\Administrator>bcdedit /store D:\Boot\BCD /set {default} safeboot dsrepair
この操作を正しく終了しました。

再度、作業用インスタンス上でディスクの管理を開き、アタッチしたEBSを右クリックしオフラインでオフライン状態にします。

該当のEBSを作業用インスタンスからデタッチします。

デタッチしたEBSを復元したEC2のルートボリュームにアタッチしなおします。OSバージョンやAMI等により異なる場合はありますが、今回はルートボリュームの/dev/sda1を指定しています。

これで、復元したEC2がディレクトリサービス復元モードで起動するようになります。

Windows Server バックアップからリストアする

該当のEC2がディレクトリサービス復元モードで起動するようになったので、コンソールから起動し、ログインします。なお、ログイン時のユーザはAdministratorで、パスワードはドメインコントローラー昇格時に指定したディレクトリサービス復元モードのパスワードであることに注意が必要です。Active Directoryが動作していないので、ドメインユーザでログインはできません。

起動したら、サーバマネージャーからツール > Windows Server バックアップでwbadminを開きます。

左ペインのローカルバックアップを選択し、右ペインの操作にある回復をクリックします。

はじめにではこのサーバーを選択します。バックアップ先のEBSは自分自身にアタッチされているためです。

バックアップの日付の選択では要件に応じてバックアップを選択し次へをクリックします。

回復の種類の選択ではシステム状態を選択し次へをクリックします。

システム状態の回復先の場所を選択では元の場所を選択しActive Directory ファイルの Authoritative Restore を実行するにもチェックを入れて次へをクリックします。今回のシナリオでは、この時点で他にドメインコントローラーが存在しないため、バックアップを正とします。

警告が出てきますが、OKをクリックします。

確認では次のように指定されていることを確認し回復をクリックします。

回復項目: システム状態
回復先: 元の場所
回復オプション: Authoritative Restore

警告が出てきますが、はいをクリックします。

回復が終わるまで待ちます。スペックにもよると思いますが、t3a.smallでは、ディレクトリのオブジェクトが初期状態でも30分～40分程度かかりました。

終了すると再起動を促すダイアログが出てくるので再起動をクリックします。

再起動完了後、Administratorかつドメインコントローラー昇格時に指定したディレクトリサービス復元モードのパスワードでログインすると、次のように回復が正常完了した旨のコマンドプロンプトが出てきます。

このままだと、延々とディレクトリサービス復元モードで起動してしまうようになってしまうので、解除します。ファイル名を指定して実行にmsconfigと入力してシステム構成を起動します。

ブートタブのセーフブートのチェックを外してOKをクリックします。

ダイアログが出てくるので再起動をクリックします。

再起動完了後、今度はドメインユーザでログインします。正常に回復できていればログインできます。

以上で取り急ぎ1台目のドメインコントローラーのリストアはできました。一応サービスは再開可能な段階です。

備考

後続作業

冒頭にも記載しましたが、この後、複数のドメインコントローラーでの冗長構成を復活させるためには、次のような作業が必要になります。

他ドメインコントローラーの強制降格を行う
他ドメインコントローラーのメタデータを削除する
他ドメインコントローラーの再昇格を行う

こちらにつきましては、ドメインコントローラー降格手順 (Windows Server 2012) RRS feedに公開情報がありますため、そちらをご参考に実施いただければと存じます。

その他の方法

今回は非常に回りくどいリストア手順となりました。未確認ですが、FSMOの役割を持っているドメインコントローラーを停止できるのであれば、停止して一貫性のあるAMIイメージを取得するのも手段としてあり得るものと思います。また、VSSに対応したスナップショットを利用するのも手段として考えられるかもしれません。

参考
- Amazon EC2 Systems Manager による Microsoft VSS を使用したスナップショットサポート
- VSS 対応 Windows バックアップの作成 - AWS Backup

詰まった点

ディレクトリサービス復元モードにしたら0xc000000eで起動しない

今回、Active DirectoryはWindows Server 2019を利用して検証を行っていたのですが、途中、ルートボリュームをディレクトリサービス復元モードにする際に利用する作業用インスタンスもWindows Server 2019を利用したところ、次のようなエラーでEC2が起動できなくなってしまいました。

状態: 0xc000000e
情報: 要求されたデバイスが接続されていないか、デバイスにアクセスできません。

フォーラムレベルの情報ですが、どうやら、同じOSバージョンだとこの事象に陥ることがあるようです。試しに別のOSバージョンであるWindows Server 2016を利用したところ、上手くいくようになりました。今回、別バージョンのOSを利用するようにお勧めさせていただいた理由です。

参考
- AWS Developer Forums: Windows Instance won't boot after EBS Re-attach

RDS for PostgreSQLにユーザを移行する際の権限エラーについて

wannabe — Mon, 24 Feb 2020 00:00:00 +0000

本記事では、オンプレミス、または、EC2にインストールされているPostgreSQLからRDS for PostgreSQLにユーザを移行する際に発生するエラーについて記載します。この権限エラーは、移行元のPostgreSQLに存在するユーザの設定次第で発生し、そのままだと移行することができません。

ユーザ移行時に発生する権限エラー

pg_dumpall等を用いてユーザを移行するためのSQL文を発行し、それをそのままRDSで実行すると、次のような権限エラーが発生することがあります。本記事では、このエラーに対応するのが目的です。

ユーザ移行時の権限エラー例

ERROR:  must be superuser to alter superusers
ERROR:  must be superuser to alter replication users

ご参考までに、今回検証に利用したユーザの情報を記載致します。

test_superuser{Superuser}
test_repuser{Replication}

参考:検証用ユーザ(移行元)

postgres=# create user test_superuser with superuser password 'password';
CREATE ROLE
postgres=# create user test_repuser with replication password 'password';
CREATE ROLE
postgres=# \du
                                List of roles
   Role name    |                   Attributes                   | Member of
----------------+------------------------------------------------+-----------
 postgres       | Superuser, Create role, Create DB, Replication | {}
 test_repuser   |                                     | {}
 test_superuser | Superuser                                      | {}

参考:移行用SQL文例

-bash-4.2$ pg_dumpall --roles-only
--
-- PostgreSQL database cluster dump
--

SET default_transaction_read_only = off;

SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;

--
-- Roles
--

CREATE ROLE postgres;
ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN REPLICATION;
CREATE ROLE test_repuser;
ALTER ROLE test_repuser WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN REPLICATION PASSWORD 'md56063c92b21c1aa4fc63a8dd9dde8a617';
CREATE ROLE test_superuser;
ALTER ROLE test_superuser WITH SUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN NOREPLICATION PASSWORD 'md52a52fb0807d3bfdc833db8158def1d4a';




--
-- PostgreSQL database cluster dump complete
--

ユーザ移行時の権限エラー対策

次の対応を行うことでユーザを移行することができます。

移行不可の権限を外す
- SUPERUSERの権限を外す
- NOSUPERUSERの権限を外す
- REPLICATIONの権限を外す
- NOREPLICATIONの権限を外す
代替ロールを付与する
- SUPERUSERの権限をrds_superuserロールに置き換える
- REPLICATIONの権限をrds_replicationロールに置き換える

移行不可の権限を外す

上述の通り、次の権限についてはSQL文に記載することができません。記載した場合、上述のエラーが発生します。したがって、ユーザの移行時には必ずSQL文から削除する必要があります。

SUPERUSER
NOSUPERUSER
REPLICATION
NOREPLICATION

例:変更前のユーザ変更文

ALTER ROLE test_repuser WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN REPLICATION PASSWORD 'md56063c92b21c1aa4fc63a8dd9dde8a617';
ALTER ROLE test_superuser WITH SUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN NOREPLICATION PASSWORD 'md52a52fb0807d3bfdc833db8158def1d4a';

例:変更後のユーザ変更文

ALTER ROLE test_repuser WITH INHERIT NOCREATEROLE NOCREATEDB LOGIN PASSWORD 'md56063c92b21c1aa4fc63a8dd9dde8a617';
ALTER ROLE test_superuser WITH INHERIT NOCREATEROLE NOCREATEDB LOGIN PASSWORD 'md52a52fb0807d3bfdc833db8158def1d4a';

なお、SUPERUSERおよびREPLICATIONだけでなく、それらを打ち消すNOSUPERUSERおよびNOREPLICATIONもSQL文に含めることができない点に注意する必要があります。

例:NO系のオプション指定エラー

postgres=> alter role foobarbaz with noreplication;
ERROR:  must be superuser to alter replication users
postgres=> alter role foobarbaz with nosuperuser;
ERROR:  must be superuser to alter superusers

ここまで実施すれば、該当のユーザを利用してRDSに接続する部分までは進むことができます。しかしながら、次の記載通り、作成したユーザは特別な権限を持っていません。次のステップで代替となるロールを付与する必要があります。

postgres=> \du
                                                               List of roles
         Role name         |                   Attributes                   |                          Member of

---------------------------+------------------------------------------------+----------------------------------------------------------
----
 foobarbaz                 | Cannot login                                   | {}
 pg_execute_server_program | Cannot login                                   | {}
 pg_monitor                | Cannot login                                   | {pg_read_all_settings,pg_read_all_stats,pg_stat_scan_tabl
es}
 pg_read_all_settings      | Cannot login                                   | {}
 pg_read_all_stats         | Cannot login                                   | {}
 pg_read_server_files      | Cannot login                                   | {}
 pg_signal_backend         | Cannot login                                   | {}
 pg_stat_scan_tables       | Cannot login                                   | {}
 pg_write_server_files     | Cannot login                                   | {}
 postgres                  | Create role, Create DB                        +| {rds_superuser}
                           | Password valid until infinity                  |
 rds_ad                    | Cannot login                                   | {}
 rds_iam                   | Cannot login                                   | {}
 rds_password              | Cannot login                                   | {}
 rds_replication           | Cannot login                                   | {}
 rds_superuser             | Cannot login                                   | {pg_monitor,pg_signal_backend,rds_replication,rds_passwor
d}
 rdsadmin                  | Superuser, Create role, Create DB, Replication+| {}
                           | Password valid until infinity                  |
 rdsrepladmin              | No inheritance, Cannot login, Replication      | {}
 test_repuser              |                                                | {}
 test_superuser            |                                                | {}

代替ロールを付与する

そもそもRDSでは機能が制限されており、本来の意味でのSUPERUSERを利用することができないため、完全な代替とはなり得ませんが、RDSが用意しているロールを付与することで、ある程度は代替することが可能です。

なお、執筆時点でRDSはストリーミングレプリケーションに対応していませんので、レプリケーショ用の代替ロールと言っても、ロジカルレプリケーションとなる点にも注意が必要です。

SUPERUSER -> rds_superuser
REPLICATION -> rds_replication

例:代替ロールの付与

postgres=> grant rds_superuser to test_superuser;
GRANT ROLE
postgres=> grant rds_replication to test_repuser;
GRANT ROLE

上記でRDSの用意するロールのメンバーとなることができました。

postgres=> \du
                                                               List of roles
         Role name         |                   Attributes                   |                          Member of

---------------------------+------------------------------------------------+----------------------------------------------------------
----
 foobarbaz                 | Cannot login                                   | {}
 pg_execute_server_program | Cannot login                                   | {}
 pg_monitor                | Cannot login                                   | {pg_read_all_settings,pg_read_all_stats,pg_stat_scan_tabl
es}
 pg_read_all_settings      | Cannot login                                   | {}
 pg_read_all_stats         | Cannot login                                   | {}
 pg_read_server_files      | Cannot login                                   | {}
 pg_signal_backend         | Cannot login                                   | {}
 pg_stat_scan_tables       | Cannot login                                   | {}
 pg_write_server_files     | Cannot login                                   | {}
 postgres                  | Create role, Create DB                        +| {rds_superuser}
                           | Password valid until infinity                  |
 rds_ad                    | Cannot login                                   | {}
 rds_iam                   | Cannot login                                   | {}
 rds_password              | Cannot login                                   | {}
 rds_replication           | Cannot login                                   | {}
 rds_superuser             | Cannot login                                   | {pg_monitor,pg_signal_backend,rds_replication,rds_passwor
d}
 rdsadmin                  | Superuser, Create role, Create DB, Replication+| {}
                           | Password valid until infinity                  |
 rdsrepladmin              | No inheritance, Cannot login, Replication      | {}
 test_repuser              |                                                | {rds_replication}
 test_superuser            |                                                | {rds_superuser}

以上の対応を行うことで、RDSの制限上完全に一致とはいきませんが、RDSの制限に即した形でユーザを移行することができました。

おまけ(SQL文書き換えコマンド例)

おまけとして、pg_dumpallで出力したユーザ移行用のSQL文を書き換えるコマンド例を記載致します。数ユーザ程度だったら手動対応も良いのですが、ユーザ数が増えると厳しい面もありますからね。

ユーザ移行SQL文書き換えコマンド例

# 環境変数
incompatible_users_list=<そのままだと移行できないユーザのリスト(任意の場所)>

# 対象ユーザ洗い出し
users_sql=<pg_dumpallで出力したユーザ移行SQLファイル>

super_users_list=<SUPERUSERのユーザリスト(任意の場所)>
grep "^ALTER ROLE .* SUPERUSER " "${users_sql}"   
 | awk -F " " '{print $3}'   
 | tee "${super_users_list}"

replication_users_list=<REPLICATIONのユーザリスト(任意の場所)>
grep "^ALTER ROLE .* REPLICATION " "${users_sql}"   
 | awk -F " " '{print $3}'   
 | tee "${replication_users_list}"

# 非対応部分の削除
cp -p "${users_sql}" "${users_sql}.bk"
sed -i -e 's/NOSUPERUSER//g'   
      -e 's/SUPERUSER//g'   
      -e 's/NOREPLICATION//g'   
      -e 's/REPLICATION//g'   
      "${users_sql}"

# 代替ロール付与文の追加
cat <<'_description_' >>"${users_sql}"

---
--- Grant RDS role to users
---

_description_

while read superuser; do
  echo "grant rds_superuser to ${superuser};"
done <"${super_users_list}" >>"${users_sql}"

while read replication; do
  echo "grant rds_replication to ${replication};"
done <"${replication_users_list}" >>"${users_sql}"

最後に

今回は、記事内でも触れましたが、SUPERUSERおよびREPLICATIONだけでなく、それらを打ち消すNOSUPERUSERおよびNOREPLICATIONも記載できないという部分で少しだけ詰まったため、記事にしました。

「打ち消す指定なら良いのでは？」とも一瞬思いましたが、おそらく、RDSに最初から存在しているrdsadminやrdsrepladminの権限を剥奪されると内部的に影響が出かねないため、このような制限をしているのだと思います。

RDSは非常に便利なサービスではありますが、通常のサーバにインストールしたデータベースとは挙動が異なる点もありますので、また、何か詰まった点等があれば、記事にしていきたいと思います。

VPCピアリングで別VPCのRDSにプライベートで接続する

wannabe — Tue, 11 Feb 2020 00:00:00 +0000

本記事では、VPCピアリングで別VPCのRDSにプライベートで接続する方法を記載します。単純にVPCピアリングを設定するだけで良さそうに見えますが、パブリックアクセシビリティが有効になっている場合、少し詰まった点があったため、記録しておきます。

そもそもVPCピアリングとは

VPCピアリングとは、2つのVPC(別アカウント/別リージョンも可)を接続することで、別VPCのリソースに対してもプライベート接続可能なようにする機能のことです。VPC間でインターネットを経由した通信を行いたくない(行えない)場合、この機能の利用が最有力候補となります。

ただし、VPCピアリングの作成条件には制限もあるため、事前に確認する必要があります。特に、VPCのCIDRが重複する場合には作成できないというのが、最も大きな制限事項です。

詳しくは、以下をご確認ください。

検証環境の構成

2つのCIDRが異なるVPCをVPCピアリングを使って接続しています。VPCにはパブリックサブネットを作成し、接続元のEC2と接続先のRDSを配置する構成です。EC2もRDSもパブリックIPを持っています。

この場合、何もしなければ、EC2からRDSに対する接続はインターネットを経由して行われます。RDSのパブリックアクセシビリティが有効になっているため、エンドポイント名がパブリックIPアドレスに解決されるためです。

ただし、VPCエンドポイントを導入することで、パブリックアクセシビリティが有効になっているRDSのエンドポイントをプライベートIPアドレスに解決することができるため、プライベートでの接続が可能になります。

検証環境の構築

VPCの設定

冒頭で「パブリックアクセシビリティが有効になっている場合、少し詰まった点があった」と記載しましたが、それがここです。この設定を忘れてしまうと、パブリックアクセシビリティが有効になっているRDSのエンドポイント名をプライベートIPに解決することができません。

その設定とは何かと言いますと、VPCのDNS 解決およびDNS ホスト名を有効にするという点です。また、この設定は、VPCピアリングを行う両方のVPCで行う必要がある点に注意が必要です。

上図の通り、執筆時点では、VPCのデフォルト設定値として、次のような値が利用されています。デフォルトから変更しない場合はDNS ホスト名が無効となっているのです。

DNS 解決
- 有効
DNS ホスト名
- 無効

このままだと、別VPCのRDSのエンドポイントをプライベートIPアドレスに解決することができないため、DNS ホスト名をデフォルト値から変更していきます。まずは、該当のVPCを選択し、アクション　＞　DNS ホスト名の編集をクリックします。

DNS ホスト名の有効化にチェックを付け、保存をクリックします。

該当のVPCについて、DNS ホスト名が有効となっていることを確認します。もし、DNS 解決が無効になっている場合は、同じようにしてアクション　＞　DNS 解決の編集から設定することができます。

VPCピアリングの作成

VPCピアリング接続の作成

ダッシュボードからピアリング接続を選択し、ピアリング接続の作成をクリックします。

ここでは、次のように設定しています。重要なのは、 VPC (リクエスタ)には接続元を、VPC (アクセプタ)には接続先を指定する点です。今回の構成だと、VPC (リクエスタ)をVPC-Aに、VPC (アクセプタ)をVPC-Bにします。指定後、ピアリング接続の作成をクリックします。

ピアリング接続ネームタグ
- test-peering
VPC (リクエスタ)
- VPC-A
アカウント
- 自分のアカウント
リージョン
- このリージョン (ap-northeast-1)
VPC (アクセプタ)
- VPC-B

VPCピアリングの承諾

上記で作成したVPCピアリング接続ですが、承認作業を経ていないため、承諾の保留中となり利用することができません。

該当のVPCピアリングを選択し、アクション　＞　リクエストの承諾をクリックすることで、このVPCピアリングがアクティブとなります。

VPCピアリングのDNS設定

VPCだけでなく、VPCピアリング自体でもDNSにまつわる設定を行う必要があります。デフォルトだとリクエスタ VPC からプライベート IP への DNS 解決が無効となっているためです。

設定の変更のために、アクション　＞　DNS 設定の編集からアクセプタ DNS 解決にチェックを入れて保存します。

ルートテーブルの編集

続いて、VPCピアリングを利用したいサブネットのルートテーブルをアクション　＞　ルートの編集から編集します。接続元と先の両方で編集します。今回の構成で言うと、PublicSubnetAおよびPublicSubnetBサブネットが利用している両方のルートテーブルを編集します。

それぞれのルートテーブルでは、通信先、つまり、VPCピアリング先のIPアドレスをVPCピアリングに向けるようなルートを追加します。今回はピアリング先のCIDR単位で指定します。片方だけの設定ですと、戻りの通信が迷子になりますので、両方指定する必要があります。

名前解決の確認

最後に、名前解決の確認を行います。VPCピアリング元から、VPCピアリング先のRDSのエンドポイントを解決してみます。無事にプライベートIPアドレスに解決できたことを確認できました。

プライベートIPアドレスへの解決

[ec2-user@ip-10-10-0-104 ~]$ nslookup testdb.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Server:         10.10.0.2
Address:        10.10.0.2#53

Non-authoritative answer:
testdb.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com    canonical name = ec2-18-176-xx-xx.ap-northeast-1.compute.amazonaws.com.
Name:   ec2-18-176-xx-xx.ap-northeast-1.compute.amazonaws.com
Address: 10.20.0.218

また、RDSへの接続時にも、きちんとプライベートIPアドレスを利用していることが確認できます。

RDSへの接続

[ec2-user@ip-10-10-0-104 ~]$ netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN
tcp        0      0 10.10.0.104:44472       10.20.0.218:5432        TIME_WAIT
tcp        0    252 10.10.0.104:22          xx.xx.xx.xx:65333       ESTABLISHED
tcp        0      0 10.10.0.104:44476       10.20.0.218:5432        ESTABLISHED
tcp        0      0 10.10.0.104:22          xx.xx.xx.xx:65288       ESTABLISHED
tcp6       0      0 :::111                  :::*                    LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN

ちなみに、VPCのDNS ホスト名を無効にした状態だと、次のように、グローバルIPアドレスがエンドポイントから解決されます。

パブリックIPアドレスへの接続

[ec2-user@ip-10-10-0-104 ~]$ nslookup testdb.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
Server:         10.10.0.2
Address:        10.10.0.2#53

Non-authoritative answer:
testdb.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com    canonical name = ec2-18-176-xx-xx.ap-northeast-1.compute.amazonaws.com.
Name:   ec2-18-176-xx-xx.ap-northeast-1.compute.amazonaws.com
Address: 18.176.xx.xx

最後に

VPCピアリングでパブリックアクセシビリティが有効になっているRDSに対してプライベートIPアドレスで接続するためには、接続元先のVPC自体でDNS 解決およびDNS ホスト名を有効にする必要があるという記事でした。

そもそも、RDSをパブリックサブネットに配置するパターンは多くないかもしれませんが、そのような構成を取らざるを得ない時に、役に立つ構成かもしれません。