この記事はLCL Advent Calendar 2020 - 25日目です。
Pg_pool+ReplicationからAurora PostgreSQLへ～
技術開発部の杉山です。 今回は、弊社で進めているPostgreSQLのAuora PostgreSQLへの移行における、事前障害試験の内容をメモしておこうと思います。 弊社では既に、Auroraを別のサービスでも利用してはいるのですが、今回は古いレガシーなPostgreSQLを一気にバージョンアップすると同時にAuroraへ移行するので、 良いタイミングなので導入後にテストし難い障害試験を実施しておきました。
余談ですが、最近は在宅勤務が多くなってきたおかげで、
疲れてきたらリフレッシュにウクレレを1～2曲弾いて気分転換しています。
モチベーション
- 移行する事で、常に安定したサービスを利用者及び提携先に提供する。 - 可用性が99.99%まで高まり、サービスに対する機会損失を削減する事が出来る。 - 障害発生時の切り替えがシンプルでアプリケーション側の対応も不要で属人的でない。 - Auroraに移行しても、現状のレプリケーション構成とコストは微増程度で変らない。 - エンジニアのインフラ対応工数が減るので、トータルで見るとTCOは削減出来る。 備考：アプリケーション側はRails6のmultiple databasesで対応。
現在の構成と課題
LCLでは、これまでも、サービス開発と並行してサービスを安定稼働させる為の取り組みを適宜実施してきました。 そのうちの一つである、”pg_pool + Replication”の構成も十分安定していて良い構成なのですが、 幾つかの課題を抱えていた為、体制も整ってきたこのタイミングで入れ替える事に致しました。
| # | 課題 |
|---|---|
| 1 | pg_poolの構築・運用に慣れているメンバーで無いと分かり難い。 |
| 2 | 障害パターンにより、適切にフェールオーバー出来ない事がある。 |
| 3 | AWS障害発生時に、アベイラビリティゾーン間でのフェールオーバーの手間。 |
| 4 | マスターDB障害発生時に、レプリケーション構成を組み直すのがDBA不在だと大変。 |
| 5 | データ障害以外の場合は、障害発生時に工数をかけたくない。 |
Aurora PostgreSQL障害シュミレーション
障害シュミレーション環境とパターン
| 検証# | テスト内容 |
|---|---|
| ❶ | 参照専用ノードを再起動 |
| ❷ | 書き込みノードを再起動 |
| ❸ | フェールオーバー処理 |
| ❹ | バッチ処理中の障害 |
| ❺ | aurora_inject_crash ('instance') |
| ❻ | aurora_inject_crash ('dispatcher') |
| ❼ | aurora_inject_crash ('node') |
フェールオーバー処理とエラー発生時の挙動のみの確認なので以下の環境を準備
- INSERT処理に関してはシンプルなテーブルとスクリプトを準備。
- 参照は単純に以下のテーブルをSELECT LOOPし続けて参照エラーを確認。
- Rails側のエラーは、テスト環境にアクセスしてRailsのログを確認。
テストテーブルとスクリプト
- テスト用テーブル
※ テーブル（書き込み時間を確認する為に、timestampを追加)
testdb=> CREATE SEQUENCE aurora_test_id START 1; CREATE SEQUENCE testdb=> create table aurora_test (id integer DEFAULT nextval('aurora_test_id'),memo varchar (100)); CREATE TABLE testdb=> ALTER TABLE aurora_test add column created timestamp default CURRENT_TIMESTAMP; ALTER TABLE testdb=> \d aurora_test; Table "public.aurora_test" Column | Type | Collation | Nullable | Default ---------+-----------------------------+-----------+----------+------------------------------------- id | integer | | | nextval('aurora_test_id'::regclass) memo | character varying(100) | | | created | timestamp without time zone | | | CURRENT_TIMESTAMP testdb=>
- スクリプト（書き込み)
※ ポートフォワードしているので、実際にはローカルホストではありません。
#! /bin/sh
echo 'Aurora DR TESTにデータを継続的にINSERT'
for r in `seq 1 10000`
do
psql -h localhost -p 54320 -U postgres testdb -c "insert into aurora_test(id,memo) values(nextval('aurora_test_id'),'Aurora Failover Test 2020年12月');"
echo "Insert Loop処理中です $r 回目";
#sleep 0.5
done
echo 'END LOOP'
❶ 参照専用ノードを再起動
結果
| 概要 | 影響 | フェールオーバー | 参照ノードの再起動 | 2秒～5秒程度の参照障害が発生 | 無し |
|---|
Select Loopの1304 回目で処理がエラーになっている事が確認出来ます。
Select Loop処理中です 1302 回目 count | now -------+------------------------------- 4689 | 2020-12-21 14:56:46.710698+09 (1 row) Select Loop処理中です 1303 回目 count | now -------+------------------------------- 4690 | 2020-12-21 14:56:48.904611+09 (1 row) Select Loop処理中です 1304 回目 psql: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. Select Loop処理中です 1305 回目 count | now -------+------------------------------- 4694 | 2020-12-21 14:56:54.947152+09 (1 row) Select Loop処理中です 1306 回目 count | now -------+------------------------------- 4695 | 2020-12-21 14:56:56.599045+09 (1 row)
備考：検証終了後に参照専用ノードを削除した時に、SELECT LOOPで確認したのですが参照エラーは発生しませんでした。
❷ 書き込みノードを再起動
結果
| 概要 | 影響 | フェールオーバー | 書き込みノード再起動 | 2秒～5秒程度の障害が発生 | 無し |
|---|
Insert Loopの1796 回目と1797回目で処理がエラーになっている事が確認出来ます。
Insert Loop処理中です 1795 回目 INSERT 0 1 Insert Loop処理中です 1796 回目 psql: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. Insert Loop処理中です 1797 回目 psql: FATAL: the database system is starting up FATAL: the database system is starting up Insert Loop処理中です 1798 回目 INSERT 0 1
❸ フェールオーバー処理 (≒フェールバック)
※ この処理でCNAMEが切り替わりIPが変るので、DNS TTLの影響を受けるのはこちら。
※ FQDNで接続してい場合は勿論問題無いが、IPが切り替わるのでIPでの接続は勿論NG
結果
| 概要 | 影響 | フェールオーバー | フェールオーバー | 2秒～5秒程度の障害が発生 | 有り |
|---|
Insert Loopの2233回目で処理がエラーになっている事が確認出来ます。
Insert Loop処理中です 2232 回目 INSERT 0 1 Insert Loop処理中です 2233 回目 WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. SSL SYSCALL error: EOF detected connection to server was lost Insert Loop処理中です 2234 回目
❹ バッチ処理中の障害 (書き込み)
トランザクションを利用して、長時間実行しているバッチ処理があるので、
バッチ処理実行時の再起動とフェールオーバーが発生した場合の状況を確認。
結果
| フェールオーバーが発生した場合 | 再起動が発生した場合 |
|---|---|
| トランザクションはサーバーが切り替わるので、エラーになりロールバックされる。 | トランザクションは再起動で接続が切れるので、エラーになりロールバックされる。 |
トランザクションが破棄され、ロールバックされているのでデータは更新されていません。
※以下のケースでは、コミット実行時に既にサーバーが再起動されて、 roll back the current transaction and exitでトランザクションが破棄されているのでデータが更新されて無い事が確認出来ます。
testdb=> select * from aurora_test where id <= 10; id | memo | created ----+--------------------------------------------+---------------------------- 1 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 2 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 3 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 4 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 5 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 6 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 7 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 8 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 9 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 10 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 (10 rows) testdb=> begin transaction; BEGIN testdb=> update aurora_test set memo = 'transaction under failover' where id <= 10; UPDATE 10 testdb=> commit; WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. SSL SYSCALL error: EOF detected The connection to the server was lost. Attempting reset: Succeeded. psql (11.9 (Ubuntu 11.9-1.pgdg18.04+1), server 11.8) SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off) testdb=> select * from aurora_test where id <= 10; id | memo | created ----+--------------------------------------------+---------------------------- 1 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 2 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 3 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 4 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 5 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 6 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 7 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 8 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 9 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 10 | Aurora Failover Test 2020年12月 | 2020-12-21 14:40:47.680559 (10 rows)
障害挿入クエリを使用したAurora PostgreSQLの検証
AWSでは、障害挿入クエリを使用して、Aurora PostgreSQL DB クラスターの耐障害性をテスト出来る様になっています。 上記の検証と合わせて、以下の障害試験もせっかくなので実施しました。
構文
SELECT aurora_inject_crash ('instance' | 'dispatcher' | 'node');
| シュミレーション | 概要 |
|---|---|
| instance | Amazon Aurora インスタンスの PostgreSQL 互換データベースのクラッシュがシミュレートされます。 |
| dispacher | Aurora DB クラスターのプライマリインスタンスにあるディスパッチャーのクラッシュがシミュレートされます。ディスパッチャー は Amazon Aurora DB クラスターのクラスターボリュームに対して更新を書き込みます。 |
| node | PostgreSQL 互換データベースと Amazon Aurora インスタンスのディスパッチャーの両方のクラッシュがシミュレートされます。 |
❺ aurora_inject_crash ('instance')
書き込み、読み込み専用ノード共に実行しましたが、ダウンタイムという観点では書き込み・読み込み共に大きな差異はありませんでした。
プロンプトでSQLコマンドを実行して、再接続したら既にアクセスする事は可能でした。
結果
| 概要 | 影響 | フェールオーバー | インスタンス障害 | 2秒～5秒程度の障害が発生 | 無し |
|---|
postgres=> SELECT aurora_inject_crash ('instance'); SSL SYSCALL error: EOF detected The connection to the server was lost. Attempting reset: Failed. !> \q shinya@ubuntu:~/tool$ psql -h localhost -p 54320 -U postgres postgres Password for user postgres: psql (11.9 (Ubuntu 11.9-1.pgdg18.04+1), server 11.8) SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off) Type "help" for help. postgres=> select current_user,inet_server_addr( ), inet_server_port( ),usename,client_addr,query_start,state,left(application_name,50),left(query,50) from pg_stat_activity where query <> '<insufficient privilege>' limit 10; current_user | inet_server_addr | inet_server_port | usename | client_addr | query_start | state | left | left --------------+------------------+------------------+----------+-------------+-------------------------------+--------+------+---------------------------------------------------- postgres | 10.1.1.100 | 5432 | rdsadmin | | | | | postgres | 10.1.1.100 | 5432 | | | | | |
Auroraのログをawsのシェルで確認して見ます。
aws rds download-db-log-file-portion --db-instance-identifier test-db-dev-instance-1-rds --log-file-name error/postgresql.log.2020-12-22-0345 --starting-token 0 --output text
読み込み専用ノードの場合のログを見ると,４秒程度しか差異が無い事が確認出来ました。 Database system is ready to acceptを起動時間としています。
| 停止時間 | 起動時間 | 差異 | 2020-12-22 03:57:14 | 2020-12-22 03:57:18 | 4秒 |
|---|
2020-12-22 03:57:14 UTC::@:[32149]:LOG: Aurora Runtime process (PID 32156) was terminated by signal 9: Killed 2020-12-22 03:57:14 UTC::@:[32149]:LOG: terminating any other active server processes 2020-12-22 03:57:14 UTC:10.1.1.101(40330):postgres@postgres:[5870]:WARNING: terminating connection because of crash of another server process 2020-12-22 03:57:14 UTC:10.1.1.101(40330):postgres@postgres:[5870]:DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2020-12-22 03:57:14 UTC:10.1.1.101(40330):postgres@postgres:[5870]:HINT: In a moment you should be able to reconnect to the database and repeat your command. 2020-12-22 03:57:14 UTC:10.1.1.101(41578):test@testdb:[26011]:WARNING: terminating connection because of crash of another server process 2020-12-22 03:57:14 UTC:10.1.1.101(41578):test@testdb:[26011]:DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2020-12-22 03:57:14 UTC:10.1.1.101(41578):test@testdb:[26011]:HINT: In a moment you should be able to reconnect to the database and repeat your command. 2020-12-22 03:57:14 UTC::@:[32149]:FATAL: Can't handle storage runtime process crash 2020-12-22 03:57:14 UTC::@:[32149]:LOG: database system is shut down 2020-12-22 03:57:16 UTC::@:[26226]:LOG: Waiting for runtime initialization complete... 2020-12-22 03:57:16 UTC::@:[26233]:LOG: setting shmemname /dev/shm/aurora-postgres-buffer-cache 2020-12-22 03:57:18 UTC:[local]:rdsadmin@rdsadmin:[26263]:FATAL: the database system is starting up 2020-12-22 03:57:18 UTC::@:[26262]:LOG: database system was interrupted; last known up at 2020-12-22 03:57:12 UTC 2020-12-22 03:57:18 UTC::@:[26226]:LOG: In Aurora for PostgreSQL read only hot standby mode. Database system is ready to accept read only
❻ aurora_inject_crash ('dispatcher')
以下のログが記録されていて、ダウンタイムという観点ではインスタンス障害と大きな差異はありませんでした。
結果
| 概要 | 影響 | フェールオーバー | ディスパッチャー障害 | 2秒～5秒程度の障害が発生 | 無し |
|---|
Auroraのエラーログでは、kill9でプロセスが強制終了されている事が確認出来ました。
Aurora Runtime process (PID 32156) was terminated by signal 9: Killed
書き込みサーバーで実行した結果
postgres=> SELECT aurora_inject_crash ('dispatcher'); aurora_inject_crash ------------------------------------------------ fault injection has been executed successfully (1 row)
- Loopしていた書き込み処理も2回程、エラーになりましたが、2～5秒の瞬断と言ったところでしょうか。 アプリケーション側でリトライ処理を入れておけば、カバー出来る位の間隔かもしれません。
Insert Loopの1151回目と1152回目で処理がエラーになっている事が確認出来ます。
INSERT 0 1 Insert Loop処理中です 1148 回目 INSERT 0 1 Insert Loop処理中です 1149 回目 INSERT 0 1 Insert Loop処理中です 1150 回目 INSERT 0 1 Insert Loop処理中です 1151 回目 psql: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. Insert Loop処理中です 1152 回目 psql: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. Insert Loop処理中です 1153 回目 INSERT 0 1 Insert Loop処理中です 1154 回目 INSERT 0 1 Insert Loop処理中です 1155 回目 INSERT 0 1 Insert Loop処理中です 1156 回目 INSERT 0 1
- 上記処理中のAuroraログ (障害としては4秒程度)
database system is ready to accept connectionsを起動時間としています。
| 停止時間 | 起動時間 | 差異 | 2020-12-22 04:17:02 | 2020-12-22 04:17:06 | 4秒 |
|---|
shinya@ubuntu:~$ aws rds download-db-log-file-portion --db-instance-identifier test-db-dev-instance-1-rds --log-file-name error/postgresql.log.2020-12-22-0400 --starting-token 0 --output text
2020-12-22 04:17:02 UTC:10.1.1.101(42122):postgres@postgres:[11257]:LOG: Simulating Aurora dispatcher crash
2020-12-22 04:17:02 UTC:10.1.1.101(42122):postgres@postgres:[11257]:STATEMENT: SELECT aurora_inject_crash ('dispatcher');
2020-12-22 04:17:02 UTC::@:[10854]:LOG: Aurora Runtime process (PID 10862) exited with exit code 1
2020-12-22 04:17:02 UTC::@:[10854]:LOG: terminating any other active server processes
2020-12-22 04:17:02 UTC:10.1.1.101(42122):postgres@postgres:[11257]:WARNING: terminating connection because of crash of another server process
2020-12-22 04:17:02 UTC:10.1.1.101(42122):postgres@postgres:[11257]:DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2020-12-22 04:17:02 UTC:10.1.1.101(42122):postgres@postgres:[11257]:HINT: In a moment you should be able to reconnect to the database and repeat your command.
2020-12-22 04:17:02 UTC::@:[10928]:WARNING: terminating connection because of crash of another server process
2020-12-22 04:17:02 UTC::@:[10928]:DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2020-12-22 04:17:02 UTC::@:[10928]:HINT: In a moment you should be able to reconnect to the database and repeat your command.
2020-12-22 04:17:02 UTC::@:[10854]:FATAL: Can't handle storage runtime process crash
2020-12-22 04:17:02 UTC::@:[10854]:LOG: database system is shut down
2020-12-22 04:17:04 UTC::@:[1001]:LOG: Waiting for runtime initialization complete...
2020-12-22 04:17:04 UTC::@:[1006]:LOG: setting shmemname /dev/shm/aurora-postgres-buffer-cache
2020-12-22 04:17:05 UTC:[local]:rdsadmin@rdsadmin:[1038]:FATAL: the database system is starting up
2020-12-22 04:17:05 UTC:[local]:rdsadmin@rdsadmin:[1037]:FATAL: the database system is starting up
2020-12-22 04:17:05 UTC::@:[1036]:LOG: database system was interrupted; last known up at 2020-12-22 04:16:18 UTC
2020-12-22 04:17:05 UTC::@:[1036]:LOG: Outbound recovery is not required
2020-12-22 04:17:06 UTC::@:[1001]:LOG: database system is ready to accept connections
❼ aurora_inject_crash ('node')
インスタンスとディスパッチャーの両方のクラッシュがシミュレートされるので、若干ダウンタイムは長いですが5秒程度で復旧している事が確認出来ます。
結果
| 概要 | 影響 | フェールオーバー | ノード障害 | 2秒～5秒程度の障害が発生 | 無し |
|---|
書き込みサーバーで実行した結果
postgres=> SELECT aurora_inject_crash ('node'); SSL SYSCALL error: EOF detected The connection to the server was lost. Attempting reset: Failed. !> \q shinya@ubuntu:~/tool$ psql -h localhost -p 54320 -U postgres postgres Password for user postgres: psql (11.9 (Ubuntu 11.9-1.pgdg18.04+1), server 11.8) SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off) Type "help" for help. postgres=> select current_user,inet_server_addr( ), inet_server_port( ),usename,client_addr,query_start,state,left(application_name,50),left(query,50) from pg_stat_activity where query <> '<insufficient privilege>' limit 10; current_user | inet_server_addr | inet_server_port | usename | client_addr | query_start | state | left | left --------------+------------------+------------------+----------+-------------+-------------------------------+--------+------+---------------------------------------------------- postgres | 10.1.1.100 | 5432 | rdsadmin | | | | | postgres | 10.1.1.100 | 5432 | | | | | |
Insert処理が1597 回目、1598 回目、1599 回目で3回程失敗している事が確認出来ます。
Insert Loop処理中です 1596 回目 INSERT 0 1 Insert Loop処理中です 1597 回目 psql: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. Insert Loop処理中です 1598 回目 psql: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. Insert Loop処理中です 1599 回目 psql: FATAL: the database system is starting up FATAL: the database system is starting up Insert Loop処理中です 1600 回目 INSERT 0 1 Insert Loop処理中です 1601 回目 INSERT 0 1
Auroaログの確認 (読み込み・書き込み同様)
- AWSコマンドによるログの確認
shinya@ubuntu:~$ aws rds download-db-log-file-portion --db-instance-identifier test-db-dev-instance-1-rds --log-file-name error/postgresql.log.2020-12-23-0500 --starting-token 0 --output text
database system is ready to accept connectionsを起動時間としています。
| 停止時間 | 起動時間 | 差異 | 2020-12-23 05:43:07 | 2020-12-23 05:43:12 | 5秒 |
|---|
- node障害中のエラーログ
2020-12-23 05:43:07 UTC:10.1.1.101(36114):postgres@postgres:[30829]:STATEMENT: SELECT aurora_inject_crash ('node');
2020-12-23 05:43:11 UTC::@:[1897]:LOG: Waiting for runtime initialization complete...
2020-12-23 05:43:11 UTC::@:[1977]:LOG: setting shmemname /dev/shm/aurora-postgres-buffer-cache
2020-12-23 05:43:12 UTC:[local]:rdsadmin@rdsadmin:[2092]:FATAL: the database system is starting up
2020-12-23 05:43:12 UTC:[local]:rdsadmin@rdsadmin:[2091]:FATAL: the database system is starting up
2020-12-23 05:43:12 UTC::@:[2090]:LOG: database system was interrupted; last known up at 2020-12-23 05:42:12 UTC
2020-12-23 05:43:12 UTC::@:[2090]:LOG: Outbound recovery is not required
2020-12-23 05:43:12 UTC::@:[1897]:LOG: database system is ready to accept connections
障害テスト中は管理コンソールには以下の様なログが記録されます。
上記テスト中にRailsの検証環境でもAuroraを参照していましたが、障害発生時間が5秒未満だった為かエラーログは有りませんでした。
結論
| # | 考察 |
|---|---|
| 1 | 障害発生時はOLTP系はリトライで問題は無い (2秒～5秒) |
| 2 | 書き込み処理はアプリでリトライがあれば問題無い (2秒～5秒) |
| 3 | バッチも1日1回のもので無ければ、再実行で処理されるので問題は無い。 |
| 4 | 1日1回の処理のバッチがエラーになった場合は、そちらをマニュアルで再実行する。 |
| 5 | マイナーパッチ適用等は、ダウンタイムは殆ど無いのでカジュアルに対応可能 |
| 6 | メジャーバージョンアップは変更内容を確認し、利用者の少ない時間にカジュアルに実行 |
| 7 | マニュアルで切り替えが必要な場合も、メンバー全員が容易にフェールオーバー可能!! |
留意事項
sequenceの欠損について
上記の検証中に、シークエンス nextval('aurora_test_id')を用いてデータをINSERTしていましたが、 障害試験中にやはりROLL BACKも発生し データの欠損も発生しているので、 提供しているサービスによってはメンテナンス時間は気を付ける必要は有ります。
- 以下、id列でソートして次のidから前のidの差分を算出した場合です。最大で31 idの欠番が発生していました。(総データ数：12,634件)
testdb=> select count(*) from aurora_test; count ------- 12634 (1 row) testdb=> select a.id - a.lag as diff from (select id, created, lag(id) over (order by id) from aurora_test) a order by diff desc limit 10; diff ------ 31 29 28 19 17 13 1 1 1 (10 rows)
- 欠番している部分は以下のように書き込みのLAGが約5秒発生しています。
testdb=> select a.id,a.created - a.lag as diff from (select id, created, lag(created) over (order by id) from aurora_test) a where a.id >= 1160 limit 3; id | diff ------+----------------- 1160 | 00:00:01.911308 1161 | 00:00:01.997045 1189 | 00:00:05.636869 (3 rows) testdb=> select * from aurora_test where id in (1160,1161,1189); id | memo | created ------+--------------------------------------------+---------------------------- 1160 | infra-935: Aurora Failover Test 2020年12月 | 2020-12-22 13:16:59.232346 1161 | infra-935: Aurora Failover Test 2020年12月 | 2020-12-22 13:17:01.229391 1189 | infra-935: Aurora Failover Test 2020年12月 | 2020-12-22 13:17:06.86626 (3 rows)
There is no silver bullet
接続先エンドポイントのTTL (digにて確認)
接続先は、CNAMEなのでTTL(5秒)が障害発生時の影響を受ける事もあるかと思います。 また、トランザクション、データベースバッファー内のデータや、データベースに書き込まれてない処理等もあると思いますので、 データベースサーバーの負荷によってもフェールオーバーの時間は変わってくると思います。 今回の検証を通じて、おおよそ～30秒程度のダウンタイムを目安に運用して行けば問題無いという事が分かりました。 目標値としては、99.99%(年間ダウンタイム：52分34秒)なので100回/年ダウンしてもまだ大丈夫そうです。
- 書き込みエンドポイントのTTL
;; ANSWER SECTION: test-db-dev.cluster-assxnzl0xkrk.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME test-db-dev-instance-1.assxnzl0xkrk.ap-northeast-1.rds.amazonaws.com. test-db-dev-instance-1.assxnzl0xkrk.ap-northeast-1.rds.amazonaws.com. 5 IN A 10.1.1.100
- 読み込みエンドポイントのTTL
;; ANSWER SECTION: test-db-dev.cluster-ro-assxnzl0xkrk.ap-northeast-1.rds.amazonaws.com. 1 IN CNAME test-db-dev-instance-1-rds.assxnzl0xkrk.ap-northeast-1.rds.amazonaws.com. test-db-dev-instance-1-rds.assxnzl0xkrk.ap-northeast-1.rds.amazonaws.com. 5 IN A 10.1.1.101
バックアップ
データベースがどんなに優れたソフトウエアでも、人的障害には対応していません。 ビジネス要件に応じたバックアップを適切に取得してリカバリー出来るようにしておきましょう。
最後に
今年1年は本当に色々な事があり、多くの方が色々な苦労をされたと思います。 良い事ばかりではありませんが、チャレンジしながら多くの事を楽しみながら新たに学んで、 日々を過ごして行ければと思います。皆さんも良い年末・年始をお迎えください!!
