できるのはわかっているが、レプリがしたい。そこで頭を切り替えます。AWSのデータ同期と言えばDMSでしょうということで、ドキュメントをつらつら読んでいきました。いずれかを使用できます。RDSはソースにもターゲットにもできる様なので問題なしですね。2016年と古いですがこんな記事も。PostgreSQLがロジカルレプリケーションをサポートしました。ServiceはAWSへのデータベースマイグレーションをサポートするサービスです。PostgreSQLへデータ同期できるとのことで、検証を行っていきます。手を動かす各サービス起動はじめに検証環境として以下の3サービスを立ち上げます。PostgreSQLEC2次にRDSのセキュリティグループでEC2のプライベートIPを許可します。許可します(ちょっと無駄に広いですけど)。DBへ接続確認EC2へログインし、送信元、送信先のDBインスタンスに接続できることを確認します。毎回パスワードを入力するのが面倒なのでpgpassファイルを最初に作成します。~/.pgpass続いてEC2上でpsqlコマンドを使える状態にします。postgres-serverを入れる必要はないのですが、大して重くないので入れてしまいました。contribはpgbenchで簡単な負荷テストをするためです。postgresql96-contribここまできたら接続テストをします。morihaya-aurorapg.xxxx.us-east-1.rds.amazonaws.com無事つながりました。続いてDMSを設定していきます。設定することでデータ同期を行う様です。(多分その専用EC2でattunityみたいなツールが動いているんでしょうね(想像))ここも特に迷わずポチポチして作成が完了しました。[テーブルマッピング]というセクションで同期するテーブル、しないテーブルを制御できるのも分かりやすくて良いです。できるので、成功を確認して作成完了です。変更後のRDS側の再起動を行っておらずプチハマりしました。以下のエラーをRDSのログでみて気づけましたが。PostgreSQLに入れます。EC2から以下を実行します。morihaya念のためカウントで確認します。row)DMS同期開始コンソールから開始を実行します。ステータスが完了になれば成功です。同期先のauroraにてデータの伝搬を確認します。row)無事にレプリケーションが組めました。簡単!主キー無しテーブルを試してみるここでちょっと興味が湧いたので、主キー無しのテーブルがどの様に伝搬されるかを確認します。ver10のロジカルレプリケーションではDDLは伝搬しないのですが、それも含めてテストします。PostgreSQLへpsqlで接続、以下を実行します。rows)結果をaurora側でも確認します。全指定したこともあり、DDL,DML全てが送信先のAuroraに伝搬されていることを確認しました。PostgreSQLで実行します。rows)ではDELETEはどうでしょう。rows)送信先のauroraで確認すると、「マイガッ!」DELETEもダメですね。rows)整合性がなくなったのでテーブルを削除します。TABLE送信先でも無事に削除されました。結論としては主キーの無いテーブルの場合以下の挙動になりました。サービスとしては使えませんが、動きとして知っておくとトラブル対応が捗るかもですね。伝搬される念のため主キーがあるテーブル確認ここまでくると不安なのでサクッと主キーありテーブルの挙動を確認しました、もちろん正しく伝搬したので何の問題も無しでした!送信元で以下を実施。PostgreSQLへのデータ同期を試したメモでした。該当するパラメタが存在しないんですよね。wal_levelを確認するとreplicaとなっています。Postgresを送信元にできないのじゃ無いかなって思ったりしましたが、本日は力尽きたので次に試したいと思います。指定できるので問題なさそうかな。含まれ...2018-12-302018年の振り返り今年も残すこと僅かというところで、1年の振り返りをします。#23に参加してきました月別アーカイブスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。