Category: Replication

Privilege Escalation via Replication Job

Published 2025-12-23 by Kevin Feasel

Fabiano Amorim makes note of a security concern:

Privilege escalation in SQL Server isn’t just theory – it can happen through everyday maintenance jobs. This article demonstrates how a user with roles like db_owner or db_ddladmin can exploit replication cleanup processes to gain sysadmin rights, and why monitoring trigger creation and job behavior is critical for security.

Replication is one of those things people tend not to understand very well, including the necessary permissions. It’s a lot easier simply to say, “Here’s sysadmin” because that actually works instead of giving you a cryptic error you can barely troubleshoot and that’s only thanks to a Repltalk article from 2009. And heaven help you if you’re looking at merge replication.

But as far as the article goes, I won’t say that it’s much ado about nothing. What I will, however, say is that your account needs to be db_owner or db_ddladmin first, and that does mitigate a fair amount of the risk.

Monitoring Replication in Redgate Monitor

Published 2025-12-16 by Kevin Feasel

Steve Jones shows off some functionality:

The monitoring capabilities in Redgate Monitor were originally fairly limited to a few counters from PerfMon. A few people had written custom metrics on sqlmonitormetrics.com that clients could use, but we’ve had customers asking for more native integrations.

We’ve done it. With version 14.2, we have added an estate view of your replication environment. In the Estate menu, there is a new entry for Replication Monitoring.

I had to check the documentation to see if merge replication was included, and it was. That’s usually the form that people avoid because it’s too hard to implement.

In practice, this doesn’t replace ReplMon or more detailed mechanisms for detailing system behavior, but it does at least provide the ability to alert if things are going wrong with the SQL Agent jobs. That probably catches about 60-70% of issues with replication, with the remaining 30-40% requiring some sort of time of flight indicator to see if data on the subscribers are keeping up to date with data on the publisher.

Data Replication and Columnstore

Published 2025-12-11 by Kevin Feasel

Niko Neugebauer continues a series on columnstore:

In the Columnstore Indexes space, there is a long-standing “tradition” in Microsoft to ignore the needs of the customers for data replication. It has started with with the original SQL Server 2012 release not supporting any data manipulation operations besides Partition switching. Since then it has been improved from version to version up until SQL Server 2016 where Nonclustered Columnstore Indexes has received a support for the Transactional Replication, and voila – that’s where it has stopped!

Read on for the frustration involved in moving around columnstore data.

2 Comments

PostgreSQL Synchronous Replication is Asynchronous

Published 2025-10-28 by Kevin Feasel

Jeremy Schneider doesn’t wait for a response:

Postgres database-level “synchronous replication” does not actually mean the replication is synchronous. It’s a bit of a lie really. The replication is actually – always – asynchronous. What it actually means is “when the client issues a COMMIT then pause until we know the transaction is replicated.” In fact the primary writer database doesn’t need to wait for the replicas to catch up UNTIL the client issues a COMMIT …and even then it’s only a single individual connection which waits. This has many interesting properties.

Click through for the pros and cons of this technical decision.

Comments closed

Trace Flag 1448 and Replication

Published 2025-10-23 by Kevin Feasel

Garry Bargsley covers the behavior of a trace flag:

In SQL Server environments where transactional replication runs alongside Always On Availability Groups (AGs), DBAs sometimes face a frustrating scenario: replication stalls when a secondary replica or subscriber is offline for maintenance, patching, or unexpected downtime.

By default, SQL Server’s Log Reader Agent is cautious. It only marks transactions as ready for replication once they are hardened on both the primary and all replicas. This ensures consistency across the AG, but it can also cause replication to stall if an asynchronous replica or subscriber is unavailable for an extended period of time.

Click through to see how it works and what the consequences are.

Comments closed

Postgres Migration via Logical Replication

Published 2025-10-06 by Kevin Feasel

Elizabeth Christensen makes a move:

Moving a Postgres database isn’t a small task. Typically for Postgres users this is one of the biggest projects you’ll undertake. If you’re migrating for a new Postgres major version or moving to an entirely new platform or host, you have a couple options:

Read on for those three options, when logical replication can possibly work, and the process for upgrade. It’s definitely a bit more fiddly than other options, but it’s hard to beat with respect to downtime.

Comments closed

Replication Types and Modes in PostgreSQL

Published 2025-07-11 by Kevin Feasel

Semab Tariq lays out three types of replication available in PostgreSQL:

PostgreSQL also supports replication to keep standby servers in sync with the primary server using Write-Ahead Log (WAL) files. Every change made to the database is first recorded in these WAL files on the primary server. These logs are then continuously streamed to the standby server, which applies them to stay up to date. This method ensures that all standby servers stay in sync with the primary and are ready to be promoted in case the primary server fails.

In this blog, we will explore the different types and modes of replication available in PostgreSQL to help you understand which option best fits your business needs.

Click through for the list, as well as an overview of each replication type.

Comments closed

Thoughts on Multi-Primary Replication in PostgreSQL

Published 2025-06-19 by Kevin Feasel

Jan Wieremjewicz wants to know if you really need it:

Active-active, also referred to as multi-primary, is a setup where multiple database nodes can accept writes at the same time and propagate those changes to the others. In comparison, regular streaming replication in PostgreSQL allows only one node (the primary) to accept writes. All other nodes (replicas) are read-only and follow changes.

In an active-active setup:

There is no single point of write.

Applications can write to any node.

The database needs a way to sort out conflicts when two nodes try to concurrently change the same data.

Read on for some of the challenges around this, tooling that is available, and thoughts on when this can be important.

Comments closed

Setting the Optimal logical_decoding_work_mem in PostgreSQL

Published 2025-06-06 by Kevin Feasel

Ashutosh Bapat shares a tip with us:

Logical replication is a versatile feature offered in PostgreSQL. I have discussed the the theoretical background of this feature in detail in my POSETTE talk. At the end of the talk, I emphasize the need for monitoring logical replication setup. If you are using logical replication and have setup monitoring you will be familiar with pg_stat_replication_slots. In some cases this view shows high amount of spill_txns, spill_count and spill_bytes, which indicates that the WAL sender corresponding to that replication slot is using high amount of disk space. This increases load on the IO subsystem affecting the performance. It also means that there is less disk available for user data and regular transactions to operate. This is an indication that logical_decoding_work_mem has been configured too low. That’s the subject of this blog: how to decide the right configuration value for logical_decoding_work_mem. Let’s first discuss the purpose of this GUC. Blog might serve as a good background before reading further.

Read on to learn a bit more about how this value works and what you can do to set it correctly.

Comments closed

Postgres Synchronous Replication Guarantees

Published 2024-12-09 by Kevin Feasel

Kaarel Moppel has a public service announcement:

At last week’s local Postgres user group meetup here in Estonia, one of the topics was HA and recent Patroni (the most popular cluster manager for Postgres) improvements in supporting quorum commit, which by the way on its own has been possible to use for years. Things went deep quickly and we learned quite a bit of course. Including a good reminder that you shouldn’t build your bank on Patroni’s default synchronous mode 🙂

Anyways, during the hallway track (which sometimes are as valuable as the real ones) got an interesting question – with some 3+ quorum nodes, is Postgres then 100% bulletproof against all kinds failures? Excluding meteorites, rouge DBAs and such of course. One could think so, right? Nope.

Read on to learn what might cause failure in that scenario. Guaranteeing synchronous replication between machines over a network is a surprisingly difficult challenge.

Comments closed