https://github.com/shayonj/pg_easy_replicate Skip to content Toggle navigation Sign up * Product + Actions Automate any workflow + Packages Host and manage packages + Security Find and fix vulnerabilities + Codespaces Instant dev environments + Copilot Write better code with AI + Code review Manage code changes + Issues Plan and track work + Discussions Collaborate outside of code Explore + All features + Documentation + GitHub Skills + Blog * Solutions For + Enterprise + Teams + Startups + Education By Solution + CI/CD & Automation + DevOps + DevSecOps Case Studies + Customer Stories + Resources * Open Source + GitHub Sponsors Fund open source developers + The ReadME Project GitHub community articles Repositories + Topics + Trending + Collections * Pricing [ ] * # In this repository All GitHub | Jump to | * No suggested jump to results * # In this repository All GitHub | Jump to | * # In this user All GitHub | Jump to | * # In this repository All GitHub | Jump to | Sign in Sign up You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. {{ message }} shayonj / pg_easy_replicate Public * Notifications * Fork 3 * Star 244 Easily setup logical replication and switchover to new database with minimal downtime License MIT license 244 stars 3 forks Star Notifications * Code * Issues 3 * Pull requests 0 * Actions * Projects 0 * Security * Insights More * Code * Issues * Pull requests * Actions * Projects * Security * Insights shayonj/pg_easy_replicate This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository. main Switch branches/tags [ ] Branches Tags Could not load branches Nothing to show {{ refName }} default View all branches Could not load tags Nothing to show {{ refName }} default View all tags Name already in use A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch? Cancel Create 1 branch 1 tag Code * Local * Codespaces * Clone HTTPS GitHub CLI [https://github.com/s] Use Git or checkout with SVN using the web URL. [gh repo clone shayon] Work fast with our official CLI. Learn more about the CLI. * Open with GitHub Desktop * Download ZIP Sign In Required Please sign in to use Codespaces. Launching GitHub Desktop If nothing happens, download GitHub Desktop and try again. Launching GitHub Desktop If nothing happens, download GitHub Desktop and try again. Launching Xcode If nothing happens, download Xcode and try again. Launching Visual Studio Code Your codespace will open once ready. There was a problem preparing your codespace, please try again. Latest commit @dependabot dependabot[bot] Bump rubocop from 1.51.0 to 1.52.1 (#10) ... f8afb7a Jun 20, 2023 Bump rubocop from 1.51.0 to 1.52.1 (#10) Bumps [rubocop](https://github.com/rubocop/rubocop) from 1.51.0 to 1.52.1. - [Release notes](https://github.com/rubocop/rubocop/releases) - [Changelog](https://github.com/rubocop/rubocop/blob/master/CHANGELOG.md) - [Commits](rubocop/rubocop@v1.51.0...v1.52.1) --- updated-dependencies: - dependency-name: rubocop dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> f8afb7a Git stats * 37 commits Files Permalink Failed to load latest commit information. Type Name Latest commit message Commit time .github bin lib spec .gitignore .prettierignore .rspec .rubocop.yml .ruby-version CHANGELOG.md CODE_OF_CONDUCT.md Dockerfile Gemfile Gemfile.lock LICENSE.txt README.md Rakefile docker-compose.yml package.json pg_easy_replicate.gemspec yarn.lock View code [ ] pg_easy_replicate Installation Requirements Limits Usage CLI Replicating all tables with a single group Config check Bootstrap Start sync Stats Performing switchover Replicating single database with custom tables Switchover strategies with minimal downtime Rolling restart strategy DNS Failover strategy README.md pg_easy_replicate CI Gem Version pg_easy_replicate is a CLI orchestrator tool that simplifies the process of setting up logical replication between two PostgreSQL databases. pg_easy_replicate also supports switchover. After the source (primary database) is fully replicating, pg_easy_replicate puts it into read-only mode and via logical replication flushes all data to the new target database. This ensures zero data loss and minimal downtime for the application. This method can be useful for performing minimal downtime (up to <1min, depending) major version upgrades between two PostgreSQL databases, load testing with blue/ green database setup and other similar use cases. Battle tested in production at Tines * Installation * Requirements * Limits * Usage * CLI * Replicating all tables with a single group + Config check + Bootstrap + Start sync + Stats + Performing switchover * Replicating single database with custom tables * Switchover strategies with minimal downtime + Rolling restart strategy + DNS Failover strategy Installation Add this line to your application's Gemfile: gem "pg_easy_replicate" And then execute: $ bundle install Or install it yourself as: $ gem install pg_easy_replicate This will include all dependencies accordingly as well. Make sure the following requirements are satisfied. Or via Docker: docker pull shayonj/pg_easy_replicate:latest https://hub.docker.com/r/shayonj/pg_easy_replicate Requirements * PostgreSQL 10 and later * Ruby 2.7 and later * Database user should have permissions for SUPERUSER * Both databases should have the same schema Limits All Logical Replication Restrictions apply. Usage Ensure SOURCE_DB_URL and TARGET_DB_URL are present as environment variables in the runtime environment. The URL are of the postgres connection string format. Example: $ export SOURCE_DB_URL="postgres://USERNAME:PASSWORD@localhost:5432/DATABASE_NAME" $ export TARGET_DB_URL="postgres://USERNAME:PASSWORD@localhost:5433/DATABASE_NAME" Any pg_easy_replicate command can be run the same way with the docker image as well. As long the container is running in an environment where it has access to both the databases. Example docker run -e SOURCE_DB_URL="postgres://USERNAME:PASSWORD@localhost:5432/DATABASE_NAME" \ -e TARGET_DB_URL="postgres://USERNAME:PASSWORD@localhost:5433/DATABASE_NAME" \ -it --rm shayonj/pg_easy_replicate:latest \ pg_easy_replicate config_check CLI $ pg_easy_replicate pg_easy_replicate commands: pg_easy_replicate bootstrap -g, --group-name=GROUP_NAME # Sets up temporary tables for information required during runtime pg_easy_replicate cleanup -g, --group-name=GROUP_NAME # Cleans up all bootstrapped data for the respective group pg_easy_replicate config_check # Prints if source and target database have the required config pg_easy_replicate help [COMMAND] # Describe available commands or one specific command pg_easy_replicate start_sync -g, --group-name=GROUP_NAME # Starts the logical replication from source database to target database provisioned in the group pg_easy_replicate stats -g, --group-name=GROUP_NAME # Prints the statistics in JSON for the group pg_easy_replicate stop_sync -g, --group-name=GROUP_NAME # Stop the logical replication from source database to target database provisioned in the group pg_easy_replicate switchover -g, --group-name=GROUP_NAME # Puts the source database in read only mode after all the data is flushed and written pg_easy_replicate version # Prints the version Replicating all tables with a single group You can create as many groups as you want for a single database. Groups are just a logical isolation of a single replication. Config check $ pg_easy_replicate config_check Config is looking good. Bootstrap Every sync will need to be bootstrapped before you can set up the sync between two databases. Bootstrap creates a new super user to perform the orchestration required during the rest of the process. It also creates some internal metadata tables for record keeping. $ pg_easy_replicate bootstrap --group-name database-cluster-1 {"name":"pg_easy_replicate","hostname":"PKHXQVK6DW","pid":21485,"level":30,"time":"2023-06-19T15:51:11.015-04:00","v":0,"msg":"Setting up schema","version":"0.1.0"} ... Start sync Once the bootstrap is complete, you can start the sync. Starting the sync sets up the publication, subscription and performs other minor housekeeping things. $ pg_easy_replicate start_sync --group-name database-cluster-1 {"name":"pg_easy_replicate","hostname":"PKHXQVK6DW","pid":22113,"level":30,"time":"2023-06-19T15:54:54.874-04:00","v":0,"msg":"Setting up publication","publication_name":"pger_publication_database_cluster_1","version":"0.1.0"} ... Stats You can inspect or watch stats any time during the sync process. The stats give you can an idea of when the sync started, current flush/ write lag, how many tables are in replicating, copying or other stages, and more. You can poll these stats to perform any other after the switchover is done. The stats include a switchover_completed_at which is updated once the switch over is complete. $ pg_easy_replicate stats --group-name database-cluster-1 { "lag_stats": [ { "pid": 66, "client_addr": "192.168.128.2", "user_name": "jamesbond", "application_name": "pger_subscription_database_cluster_1", "state": "streaming", "sync_state": "async", "write_lag": "0.0", "flush_lag": "0.0", "replay_lag": "0.0" } ], "message_lsn_receipts": [ { "received_lsn": "0/1674688", "last_msg_send_time": "2023-06-19 19:56:35 UTC", "last_msg_receipt_time": "2023-06-19 19:56:35 UTC", "latest_end_lsn": "0/1674688", "latest_end_time": "2023-06-19 19:56:35 UTC" } ], "sync_started_at": "2023-06-19 19:54:54 UTC", "sync_failed_at": null, "switchover_completed_at": null .... Performing switchover pg_easy_replicate doesn't kick off the switchover on its own. When you start the sync via start_sync, it starts the replication between the two databases. Once you have had the time to monitor stats and any other key metrics, you can kick off the switchover. switchover will wait until all tables in the group are replicating and the delta for lag is <200kb (by calculating the pg_wal_lsn_diff between sent_lsn and write_lsn) and then perform the switch. The switch is made by putting the user on the source database in READ ONLY mode, so that it is not accepting any more writes and waits for the flush lag to be 0. It is up to user to kick of a rolling restart of your application containers or failover DNS (more on these below in strategies) after the switchover is complete, so that your application isn't sending any read/write requests to the old/source database. $ pg_easy_replicate switchover --group-name database-cluster-1 {"name":"pg_easy_replicate","hostname":"PKHXQVK6DW","pid":24192,"level":30,"time":"2023-06-19T16:05:23.033-04:00","v":0,"msg":"Watching lag stats","version":"0.1.0"} ... Replicating single database with custom tables By default all tables are added for replication but you can create multiple groups with custom tables for the same database. Example $ pg_easy_replicate bootstrap --group-name database-cluster-1 $ pg_easy_replicate start_sync --group-name database-cluster-1 --schema-name public --tables "users, posts, events" ... $ pg_easy_replicate bootstrap --group-name database-cluster-2 $ pg_easy_replicate start_sync --group-name database-cluster-2 --schema-name public --tables "comments, views" ... $ pg_easy_replicate switchover --group-name database-cluster-1 $ pg_easy_replicate switchover --group-name database-cluster-2 ... Switchover strategies with minimal downtime For minimal downtime, it'd be best to watch/tail the stats and wait until switchover_completed_at is updated with a timestamp. Once that happens you can perform any of the following strategies. Note: These are just suggestions and pg_easy_replicate doesn't provide any functionalities for this. Rolling restart strategy In this strategy, you have a change ready to go which instructs your application to start connecting to the new database. Either using an environment variable or similar. Depending on the application type, it may or may not require a rolling restart. Next, you can set up a program that watches the stats and waits until switchover_completed_at is reporting as true. Once that happens it kicks off a rolling restart of your application containers so they can start making connections to the DNS of the new database. DNS Failover strategy In this strategy, you have a weighted based DNS system (example AWS Route53 weighted records) where 100% of traffic goes to a primary origin and 0% to a secondary origin. The primary origin here is the DNS host for your source database and secondary origin is the DNS host for your target database. You can set up your application ahead of time to interact with the database using DNS from the weighted group. Next, you can set up a program that watches the stats and waits until switchover_completed_at is reporting as true. Once that happens it updates the weight in the DNS weighted group where 100% of the requests now go to the new/target database. Note: Keeping a low ttl is recommended. About Easily setup logical replication and switchover to new database with minimal downtime Topics ruby postgres postgresql logical-replication Resources Readme License MIT license Code of conduct Code of conduct Stars 244 stars Watchers 3 watching Forks 3 forks Report repository Releases 1 v0.1.0 Latest Jun 19, 2023 Packages 0 No packages published Contributors 4 * @shayonj shayonj Shayon Mukherjee * @natacado natacado Paul Paradise * @felixonmars felixonmars Felix Yan * @dependabot[bot] dependabot[bot] Languages * Ruby 98.6% * Shell 1.3% * Dockerfile 0.1% Footer (c) 2023 GitHub, Inc. Footer navigation * Terms * Privacy * Security * Status * Docs * Contact GitHub * Pricing * API * Training * Blog * About You can't perform that action at this time.