Search
28 results for “replication”
Search results
Database Replication
Why asynchronous replication can silently lose the most recent commits if the primary crashes, what synchronous_commit's three levels actually each guarantee, and how to measure replication lag instead of assuming it's small.
A PostgreSQL primary crashes right after committing a transaction, under asynchronous replication. Is that transaction guaranteed to exist on the standby?
No. Asynchronous replication (the default) confirms a commit on the primary without waiting for the standby to receive or apply the corresponding WAL records, there's typically a small delay, often under a second, between a commit and its visibility on the standby. If the primary crashes in that window, before the WAL records reached the standby, that transaction is lost even though the client was already told it committed successfully. This is the specific, documented risk asynchronous replication accepts in exchange for not adding network round-trip latency to every commit.
How do you actually measure replication lag, rather than assuming it's negligible?
Replication lag is the gap between WAL records generated on the primary and WAL records actually applied on the standby, and it's measured concretely by comparing the primary's current WAL write position, from `pg_current_wal_lsn()`, against the standby's last replayed position, from `pg_last_wal_replay_lsn()`, via `pg_wal_lsn_diff()`. A large or growing byte gap is a real health signal, it points at the primary generating WAL faster than the network or standby can keep up, or the standby itself being under heavy load, not something to infer from "it's usually under a second" folklore. Monitoring this value directly, not assuming a small delay, is what actually catches a standby falling dangerously behind before a failover makes that lag visible as lost data.
Build a Secure Azure Environment in Minutes with Bicep: VMs, Networking, Private Endpoints & Blob Replication
A hands-on Infrastructure-as-Code lab deploying a production-ready Azure environment from a single Bicep template.
What is the actual difference between synchronous_commit = on, remote_write, and remote_apply?
`on` (the standard synchronous setting) waits for the standby to write the commit record to its own disk, "2-safe" durability, data is lost only if both primary and standby crash simultaneously. `remote_write` only waits for the standby to receive the record and hand it to its operating system, not for a disk flush, weaker durability (a standby OS crash before its own flush could still lose it) in exchange for a faster commit. `remote_apply` is the strongest of the three, it waits until the standby has actually replayed the transaction and made it visible to queries, which is what allows read queries against the standby to see a transaction immediately after the primary reports it committed.
What is a Service Control Policy (SCP), and what is the one thing it does not do?
An SCP is a policy attached to an AWS Organizations root, organizational unit, or member account that defines the maximum available permissions for every identity in that account, including that account's own administrators and its root user. What an SCP does not do is grant any permission by itself, it only sets a ceiling; an identity still needs an actual IAM allow (from an identity-based or resource-based policy) within that ceiling to do anything. An SCP with no matching IAM allow underneath it results in access denied, not access granted, which is the most common misunderstanding of how SCPs work. One exception worth knowing: SCPs never apply to the organization's management account itself, only to member accounts.
How do Azure Monitor, Log Analytics, and Application Insights relate to each other?
Azure Monitor is the umbrella platform for all monitoring data in Azure, metrics, logs, and alerts across every resource. Log Analytics is the query and storage engine underneath it that holds log data in workspaces and is queried using KQL (Kusto Query Language). Application Insights is Azure Monitor's application-performance-monitoring feature specifically, which auto-instruments application code to collect request traces, dependency calls, and exceptions, and stores that data in a Log Analytics workspace like everything else. They are not three separate products so much as one platform (Azure Monitor) with a query engine (Log Analytics) and an application-specific instrumentation layer (Application Insights) on top of it.
What is the practical difference between session pooling and transaction pooling, and why does transaction pooling scale better?
Session pooling assigns one server connection to a client for their entire session, released back to the pool only when the client disconnects, which supports every PostgreSQL feature but means a mostly-idle client still occupies a real server connection the whole time it's connected. Transaction pooling instead assigns a server connection only for the duration of a single transaction, returning it to the pool the moment the transaction ends, so many more clients can share a small, fixed pool of real connections, since a client that isn't actively mid-transaction isn't holding one at all. This is why transaction pooling is the standard choice for applications with many short-lived connections (like a web app's connection-per-request pattern) against a database with a hard connection limit.
A query filters WHERE logdate >= 2008-01-01 against a table range-partitioned by logdate across dozens of monthly partitions. What does partition pruning actually do, and what does it depend on?
Partition pruning lets the planner prove, from the query's WHERE clause and each partition's declared bounds, that some partitions cannot possibly contain a matching row, and it excludes them from the plan entirely rather than scanning and filtering every partition. In this example, `logdate >= 2008-01-01` has no upper bound, so it prunes only the partitions entirely before 2008-01, decades of older monthly partitions are eliminated before execution, while every partition from 2008-01 onward, including all of them up to the present, is still considered and scanned. Pruning down to a single partition would need a bounded predicate on both ends, for example `logdate >= 2008-01-01 AND logdate < 2008-02-01`. This depends entirely on the partition bounds themselves, not on any index, a partitioned table with no indexes at all still benefits from pruning, and pruning specifically requires the WHERE clause to reference the partition key directly with values (or parameters) the planner can actually compare against those bounds.
A transaction under Repeatable Read isolation fails with "could not serialize access due to concurrent update." What actually happened, and what is the application expected to do?
Repeatable Read uses snapshot isolation, the transaction sees a consistent snapshot from its own start, but if it then tries to update a row that another, concurrently-committed transaction already modified, PostgreSQL detects the conflict and aborts the transaction with a serialization failure rather than silently applying an update based on stale data. This is not an application bug, it is Repeatable Read (and Serializable) working as designed, both isolation levels explicitly require the application to catch this specific error and retry the transaction from the beginning, trading the guarantee of not overwriting concurrent changes for the operational cost of occasional automatic retries.
What problem does policy-as-code solve that a manual infrastructure change review does not?
A manual review depends on a human noticing a specific misconfiguration, an open security group, an unencrypted storage bucket, in a plan diff that may span hundreds of resources, and that scrutiny has to be repeated consistently by every reviewer on every change. Policy-as-code encodes the same rule once as executable logic and runs it automatically against every plan, so an overly permissive security group is caught the same way on the hundredth change as the first, without depending on which reviewer happened to be paying attention that day.
Why does `ping` succeeding not guarantee an application on that host is reachable?
ping tests only ICMP echo reachability at the network layer; it confirms a host responds to the network, nothing about any specific service running on it. An application listening on a TCP port can be down, crashed, or blocked by a firewall rule that specifically targets that port while still allowing ICMP through, or conversely ICMP itself can be blocked while the actual service is reachable. Confirming an application is actually up requires testing the application layer directly, e.g. `curl` against its port or `ss -tulpn` to confirm something is listening at all.
How does the sidecar proxy pattern actually intercept traffic without changing application code?
A sidecar proxy (typically Envoy) runs as a second container inside the same Pod as the application, sharing its network namespace. Traffic rules (usually iptables rules injected automatically by the mesh's admission controller) transparently redirect all inbound and outbound traffic through that proxy before it reaches or leaves the application container. The application still just makes normal HTTP/gRPC calls to `localhost` or a service DNS name, it has no idea a proxy is involved, which is exactly what makes the mesh's capabilities (mTLS, retries, observability) apply uniformly without any code changes.
A banking system typically favors CP behavior during a partition, while a chat application typically favors AP. What does each system actually do differently when a partition occurs, and why does the choice fit each use case?
A CP system, during a partition, pauses or rejects requests that can't be guaranteed consistent, a bank stopping a transfer rather than risking two nodes independently approving withdrawals against the same balance, since a duplicated or lost transaction is a correctness failure worse than a temporary outage. An AP system keeps responding during the partition, accepting the risk of temporarily inconsistent state, a chat app still accepting and displaying messages on both sides of a network split, reconciling them once the partition heals, because staying available and eventually consistent matters more to users than every message reappearing everywhere in a strict, immediate order.
What is the difference between a client tool and a server tool, and why does that distinction matter for what your application has to do?
A client tool executes in your own application, the model only returns the structured request to call it; your code is responsible for actually running it (hitting your database, calling your API) and returning the result. A server tool, like a web search or code execution tool a provider offers, executes on the provider's own infrastructure, so your application sees the final result directly without ever writing execution code for it. The distinction determines how much you have to build: every client tool needs your own execution and error-handling code, while server tools need none, just declaring them in the request.
Microsoft Entra Conditional Access Explained: MFA, Location Controls, and the What If Tool (Full Lab Guide)
How Conditional Access Evaluates Sign‑Ins Behind the Scenes
Building Golden Images with Azure Compute Gallery: Custom VM Image Creation & Deployment (Hands-On Lab)
A step-by-step Azure lab for creating, versioning, and deploying standardized VM images at scale.
Why does a real ring hash implementation give each host many positions on the ring instead of just one, and what problem would a single position per host cause?
A host thrown onto the ring at just one point can end up, purely by chance, owning a disproportionately large or small arc of the ring if the hash values happen to land unevenly, since with few points there's no averaging effect smoothing out the randomness. Assigning each host many positions on the ring, scaled by that host's intended weight, so a double-weight host gets roughly twice as many ring entries as a single-weight one, averages out that randomness across many smaller arcs per host, producing a much more even overall traffic distribution than a single coin-flip-like placement per host would.
Why does wrapping several statements in `BEGIN`/`COMMIT` matter, even for a multi-step operation that's logically one action?
Without an explicit transaction, PostgreSQL commits each statement independently the moment it succeeds; if a multi-step operation (debit one account, credit another) fails halfway through, the database is left in an inconsistent, partially-applied state with no way to undo the completed step. Wrapping the statements in `BEGIN`/`COMMIT` groups them so they can be committed or rolled back together, but that alone isn't automatic protection against every failure mode: PostgreSQL only aborts a transaction on its own when a statement raises an actual SQL error, an `UPDATE` that runs successfully but matches zero rows (a mistyped account id, for instance) is not an error at all, and would otherwise be committed as if the transfer had actually happened. Making the transaction genuinely safe means checking that each `UPDATE` affected exactly the one row expected and issuing an explicit `ROLLBACK` if either check fails, only issuing `COMMIT` once both checks pass.
Why are environment variables considered a weaker place to store a secret than a dedicated secrets manager, even though they avoid hardcoding it in source?
Environment variables are readable by the entire process (and often child processes) they're set for, commonly get dumped into crash reports, debugging output, or `/proc` on Linux, and are easy to accidentally log in full, none of which requires a targeted attack, just an ordinary operational mistake. A dedicated secrets manager instead requires an authenticated, audited API call to retrieve a secret, can issue it as short-lived, and centralizes rotation and access logging in one place. Environment variables are a real improvement over hardcoding in source, but they are a stopgap, not the same security posture as centralized, audited secret retrieval.
DHCP Server Deployment on Hyper-V: From Scope Creation to Failover Configuration
Step-by-step deployment of a highly available DHCP service in a Hyper-V virtual environment
When would you choose Azure App Service over a Virtual Machine for hosting a web application?
App Service is a fully managed PaaS; it handles OS patching, runtime installation, and built-in scaling and deployment slots, so you only manage application code and configuration. A Virtual Machine is IaaS, full control over the OS and everything installed on it, but you own patching, scaling configuration, and availability yourself. Choose App Service when the workload is a standard web app/API in a supported runtime and the team wants to minimize operational burden; choose a VM when you need OS-level control, unsupported runtimes/dependencies, or specific compliance requirements that mandate managing the host directly.
Two transactions each update two of the same two accounts, but in opposite order, and deadlock. What's the actual fix, not just for this pair of transactions, but for the application generally?
The deadlock happens because Transaction 1 locks account A then waits for account B, while Transaction 2 locks account B then waits for account A, a circular wait. The general fix isn't retry logic alone, retries only paper over deadlocks that keep recurring, it's acquiring locks on multiple objects in the same, consistent order everywhere in the application (for example, always locking accounts in ascending id order), which makes the circular-wait pattern structurally impossible rather than merely less frequent. Retry logic is still worth having as a safety net, but consistent lock ordering is what actually eliminates this class of deadlock.
An application uses PREPARE to create a reusable prepared statement, then relies on it across multiple requests. What happens if it's deployed behind a transaction-pooled PgBouncer, and why?
It breaks. A SQL PREPARE statement is a session-level feature, it lives on whatever specific server connection issued the PREPARE, but transaction pooling reassigns the underlying server connection to a different client (or the same client's next transaction) as soon as each transaction ends, so there's no guarantee a later request lands on that same server connection where the prepared statement actually exists. This is explicitly documented as one of the session-based features transaction pooling breaks, along with SET/RESET, LISTEN, WITH HOLD cursors, and session-level advisory locks, all of which depend on state tied to one specific, persistent server connection. This is distinct from protocol-level named prepared statements issued via the extended query protocol (what most driver-level "prepared statements" actually are), which PgBouncer can support under transaction pooling when `max_prepared_statements` is set to a non-zero value.
Azure Policy, Tags, and Resource Locks Explained: A Complete Governance Guide for Cloud Engineers
Effective governance is essential as cloud environments grow. Without proper controls, organizations often face challenges in visibility, accountability, and cost tracking. In this lab, we explore how to implement governance practices in Azure using Azure Policy , Resource Tags , and Resource Locks…
How to Add a Secondary Domain Controller to an Existing Domain (Hyper-V Lab)
As part of strengthening an Active Directory Domain Services (AD DS) environment, this lab demonstrates how to add a secondary (additional) Domain Controller to an existing domain hosted on Windows Server using Hyper V. The objective is to introduce redundancy, replication, and improved availabilit…
PostgreSQL vs MySQL
How PostgreSQL and MySQL actually differ in data types, concurrency, indexing, and replication, and which one fits which workload.
Why are idempotency keys typically associated with state-changing requests like POST, and are they ever relevant to DELETE?
GET is defined to have no side effects at all, retrying it any number of times simply returns the current state and changes nothing, so there is no duplicate-side-effect risk an idempotency key could protect against, GET genuinely doesn't need one. DELETE is idempotent in the narrow sense that deleting an already-deleted resource is a no-op or a consistent "not found," but whether an idempotency key is relevant to it is API- and version-specific, not settled by the HTTP verb alone: a DELETE can still trigger complex, non-idempotent side effects (a refund, a cascading cleanup, a billing adjustment), and some APIs explicitly accept an idempotency key on DELETE for exactly that reason. Idempotency keys exist to make an operation's retry semantics explicit and safe regardless of whether the underlying operation is inherently idempotent, checking the specific endpoint's documented contract matters more than assuming based on the verb.