Concept on PIG.CENTER

Features

Mon, 01 Jan 0001 00:00:00 +0000

Several levels of brutality when rotating connections:

Session pooling

Most polite method. When a client connects, a server connection will be assigned to it for the whole duration it stays connected. When the client disconnects, the server connection will be put back into pool. This mode supports all PostgreSQL features.

Transaction pooling

A server connection is assigned to a client only during a transaction. When PgBouncer notices that the transaction is over, the server will be put back into the pool. This mode breaks a few session-based features of PostgreSQL. You can use it only when the application cooperates by not using features that break. See the table below for incompatible features.

Statement pooling

Most aggressive method. This is transaction pooling with a twist: Multi-statement transactions are disallowed. This is meant to enforce “autocommit” mode on the client, mostly targeted at PL/Proxy.
Low memory requirements (2 kB per connection by default). This is because PgBouncer does not need to see full packets at once.

Introduction

Mon, 01 Jan 0001 00:00:00 +0000

Patroni is a template for high availability (HA) PostgreSQL solutions using Python. Patroni originated as a fork of Governor , the project from Compose. It includes plenty of new features.

For additional background info, see:

PostgreSQL HA with Kubernetes and Patroni , talk by Josh Berkus at KubeCon 2016 (video)
Feb. 2016 Zalando Tech blog post

Development Status

Patroni is in active development and accepts contributions. See our Contributing section below for more details.

Patroni 4.1.5 Documentation

Mon, 01 Jan 0001 00:00:00 +0000

Warning

Running Patroni on memory-restricted systems with Python 3.11+

If you run Patroni on a system with strict memory limits, for example with vm.overcommit_memory=2 (recommended for PostgreSQL), and use Python 3.11 or newer, you may observe unexpected behavior:

Patroni appears healthy
PostgreSQL continues to run
Patroni REST API becomes unresponsive
The operating system reports that Patroni is listening on the REST API port
Patroni logs look normal; however, following messages may appear once: Exception ignored in thread started by: <object repr() failed>, MemoryError
Kernel logs may contain messages such as not enough memory for the allocation

This behavior is caused by a bug in Python 3.11+ . Under strict memory conditions, starting a new thread may hang indefinitely when there is not enough free memory.

Load Balancing Fundamentals

Mon, 01 Jan 0001 00:00:00 +0000

This document is an introduction to HAProxy for all those who don’t know it, as well as for those who want to re-discover it when they know older versions. Its primary focus is to provide users with all the elements to decide if HAProxy is the product they’re looking for or not. Advanced users may find here some parts of solutions to some ideas they had just because they were not aware of a given new feature. Some sizing information is also provided, the product’s lifecycle is explained, and comparisons with partially overlapping products are provided.

pgBackRest 2.59.1 Documentation

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

pgBackRest is a reliable backup and restore solution for PostgreSQL that seamlessly scales up to the largest databases and workloads.

pgBackRest v2.59.1 is the current stable release. Release notes are on the Releases page.

Please give us a star on GitHub if you like pgBackRest!

News

August 17, 2026 - pgBackRest 2.59.1 Released

July 20, 2026 - New Distribution Tarball

July 20, 2026 - pgBackRest 2.59.0 Released

What HAProxy Is and How It Works

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy is written as “HAProxy” to designate the product, and as “haproxy” to designate the executable program, software package or a process. However, both are commonly used for both purposes, and are pronounced H-A-Proxy. Very early, “haproxy” used to stand for “high availability proxy” and the name was written in two separate words, though by now it means nothing else than “HAProxy”.

PgBouncer 1.25.2 Documentation

Mon, 01 Jan 0001 00:00:00 +0000

pgbouncer is a PostgreSQL connection pooler. Any target application can be connected to pgbouncer as if it were a PostgreSQL server, and pgbouncer will create a connection to the actual server, or it will reuse one of its existing connections.

The aim of pgbouncer is to lower the performance impact of opening new connections to PostgreSQL.

In order not to compromise transaction semantics for connection pooling, pgbouncer supports several types of pooling when rotating connections:

Basic Features

Mon, 01 Jan 0001 00:00:00 +0000

This section will enumerate a number of features that HAProxy implements, some of which are generally expected from any modern load balancer, and some of which are a direct benefit of HAProxy’s architecture. More advanced features will be detailed in the next section.

3.3.1. Basic features : Proxying

Proxying is the action of transferring data between a client and a server over two independent connections. The following basic features are supported by HAProxy regarding proxying and connection management:

pgBadger 13.2 Documentation

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger is a fast, standalone PostgreSQL log analyzer written in Perl. It reads PostgreSQL or PgBouncer logs and produces detailed HTML, text, binary, JSON, or raw CSV output. The HTML reports are self-contained, interactive, zoomable, and need only a web browser to view.

Why pgBadger

pgBadger is designed for large logs and operational use:

one Perl program, with no mandatory non-core Perl modules;
automatic detection of stderr, syslog, csvlog, jsonlog, RDS, Cloud SQL, logplex, Redshift, and PgBouncer input;
direct reading of local files, standard input, remote files over SSH, and HTTP, FTP, or SFTP URLs;
gzip, bzip2, lz4, xz, zip, and zstd compressed input;
parallel parsing of one large file or many smaller files;
daily, weekly, and on-demand monthly incremental reports;
filters by time, database, user, client, application, process, session, and query pattern.

What the reports contain

The PostgreSQL report set covers:

Standard Features

Mon, 01 Jan 0001 00:00:00 +0000

In this section, some features that are very commonly used in HAProxy but are not necessarily present on other load balancers are enumerated.

3.4.1. Standard features : Sampling and converting information

HAProxy supports information sampling using a wide set of “sample fetch functions”. The principle is to extract pieces of information known as samples, for immediate use. This is used for stickiness, to build conditions, to produce information in logs or to enrich HTTP headers.

Advanced Features

Mon, 01 Jan 0001 00:00:00 +0000

3.5.1. Advanced features : Management

HAProxy is designed to remain extremely stable and safe to manage in a regular production environment. It is provided as a single executable file which doesn’t require any installation process. Multiple versions can easily coexist, meaning that it’s possible (and recommended) to upgrade instances progressively by order of importance instead of migrating all of them at once. Configuration files are easily versioned. Configuration checking is done off-line so it doesn’t require to restart a service that will possibly fail. During configuration checks, a number of advanced mistakes may be detected (e.g. a rule hiding another one, or stickiness that will not work) and detailed warnings and configuration hints are proposed to fix them. Backwards configuration file compatibility goes very far away in time, with version 1.5 still fully supporting configurations for versions 1.1 written 13 years before, and 1.6 only dropping support for almost unused, obsolete keywords that can be done differently. The configuration and software upgrade mechanism is smooth and non disruptive in that it allows old and new processes to coexist on the system, each handling its own connections. System status, build options, and library compatibility are reported on startup.

etcd 3.7 Documentation

Mon, 01 Jan 0001 00:00:00 +0000

etcd is a strongly consistent, distributed key-value store. These guides cover installing and operating etcd, building applications against its APIs, understanding its design, measuring performance, and upgrading or downgrading clusters in the 3.7 release line.

Start with Quickstart for a local single-member cluster, Install for supported installation paths, or Operations guide for production deployments.

Replication modes

Mon, 01 Jan 0001 00:00:00 +0000

Patroni uses PostgreSQL streaming replication. For more information about streaming replication, see the Postgres documentation . By default Patroni configures PostgreSQL for asynchronous replication. Choosing your replication schema is dependent on your business considerations. Investigate both async and sync replication, as well as other HA solutions, to determine which solution is best for you.

Asynchronous mode durability

In asynchronous mode the cluster is allowed to lose some committed transactions to ensure availability. When the primary server fails or becomes unavailable for any other reason Patroni will automatically promote a sufficiently healthy standby to primary. Any transactions that have not been replicated to that standby remain in a “forked timeline” on the primary, and are effectively unrecoverable¹.

Community

Mon, 01 Jan 0001 00:00:00 +0000

Tutorials

How to Set Up PgBouncer for Postgres Plus Standard Server

Good overview of PgBouncer concepts.
What is the point of bouncing?

Discusses differences between pooling modes.

Support

Project page at GitHub
Issue tracker at GitHub
PgBouncer section at Stack Overflow
Community discussions at GitHub

Project Metrics

Mon, 01 Jan 0001 00:00:00 +0000

Code Coverage

pgBackRest aims to have complete function/branch/line coverage for the core C code in /src.

Function/line coverage is complete with no exceptions.

Branch coverage excludes branches inside macros and assert() calls. Macros have their own unit tests so they do not need to be tested everywhere they appear. Asserts are not expected to have complete branch coverage since they test cases that should always be true.

Companion Products and Alternatives

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy integrates fairly well with certain products listed below, which is why they are mentioned here even if not directly related to HAProxy.

4.1. Apache HTTP server

Apache is the de-facto standard HTTP server. It’s a very complete and modular project supporting both file serving and dynamic contents. It can serve as a frontend for some application servers. It can even proxy requests and cache responses. In all of these use cases, a front load balancer is commonly needed. Apache can work in various modes, some being heavier than others. Certain modules still require the heavier pre-forked model and will prevent Apache from scaling well with a high number of connections. In this case HAProxy can provide a tremendous help by enforcing the per-server connection limits to a safe value and will significantly speed up the server and preserve its resources that will be better used by the application.

Watchdog support

Mon, 01 Jan 0001 00:00:00 +0000

Having multiple PostgreSQL servers running as primary can result in transactions lost due to diverging timelines. This situation is also called a split-brain problem. To avoid split-brain Patroni needs to ensure PostgreSQL will not accept any transaction commits after leader key expires in the DCS. Under normal circumstances Patroni will try to achieve this by stopping PostgreSQL when leader lock update fails for any reason. However, this may fail to happen due to various reasons:

DCS Failsafe Mode

Mon, 01 Jan 0001 00:00:00 +0000

The problem

Patroni is heavily relying on Distributed Configuration Store (DCS) to solve the task of leader elections and detect network partitioning. That is, the node is allowed to run Postgres as the primary only if it can update the leader lock in DCS. In case the update of the leader lock fails, Postgres is immediately demoted and started as read-only. Depending on which DCS is used, the chances of hitting the “problem” differ. For example, with Etcd which is only used for Patroni, chances are close to zero, while with K8s API (backed by Etcd) it could be observed more frequently.

1. Quick Reminder About HTTP

Mon, 01 Jan 0001 00:00:00 +0000

This document covers the configuration language as implemented in the version specified above. It does not provide any hints, examples, or advice. For such documentation, please refer to the Reference Manual or the Architecture Manual. The numbered chapters are ordered in the flat HAProxy sidebar for direct navigation.

When HAProxy is running in HTTP mode, both the request and the response are fully analyzed and indexed, thus it becomes possible to build matching criteria on almost anything found in the contents.

Citus support

Mon, 01 Jan 0001 00:00:00 +0000

Patroni makes it extremely simple to deploy Multi-Node Citus clusters.

TL;DR

There are only a few simple rules you need to follow:

Citus database extension to PostgreSQL must be available on all nodes. Absolute minimum supported Citus version is 10.0, but, to take all benefits from transparent switchovers and restarts of workers we recommend using at least Citus 11.2.
Cluster name (scope) must be the same for all Citus nodes!
Superuser credentials must be the same on coordinator and all worker nodes, and pg_hba.conf should allow superuser access between all nodes.
REST API access should be allowed from worker nodes to the coordinator. E.g., credentials should be the same and if configured, client certificates from worker nodes must be accepted by the coordinator.
Add the following section to the patroni.yaml:

citus:
 group: X  # 0 for coordinator and 1, 2, 3, etc for workers
 database: citus  # must be the same on all nodes

After that you just need to start Patroni and it will handle the rest:

Integration with other tools

Mon, 01 Jan 0001 00:00:00 +0000

Patroni is able to integrate with other tools in your stack. In this section you will find a list of examples, which although not an exhaustive list, might provide you with ideas on how Patroni can integrate with other tools.

Barman

Patroni delivers an application named patroni_barman which has logic to communicate with pg-backup-api, so you are able to perform Barman operations remotely.

This application currently has a couple of sub-commands: recover and config-switch.

Security Considerations

Mon, 01 Jan 0001 00:00:00 +0000

A Patroni cluster has two interfaces to be protected from unauthorized access: the distributed configuration storage (DCS) and the Patroni REST API.

Protecting DCS

Patroni and patronictl both store and retrieve data to/from the DCS.

Despite DCS doesn’t contain any sensitive information, it allows changing some of Patroni/Postgres configuration. Therefore the very first thing that should be protected is DCS itself.

The details of protection depend on the type of DCS used. The authentication and encryption parameters (tokens/basic-auth/client certificates) for the supported types of DCS are covered in settings .

HA multi datacenter

Mon, 01 Jan 0001 00:00:00 +0000

The high availability of a PostgreSQL cluster deployed in multiple data centers is based on replication, which can be synchronous or asynchronous (see replication modes ).

In both cases, it is important to be clear about the following concepts:

Postgres can run as primary or standby leader only when it owns the leading key and can update the leading key.
You should run the odd number of etcd, ZooKeeper or Consul nodes: 3 or 5!

Synchronous Replication

To have a multi DC cluster that can automatically tolerate a zone drop, a minimum of 3 is required.

2. HAProxy Architecture

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy is a multi-threaded, event-driven, non-blocking daemon. This means it uses event multiplexing to schedule all of its activities instead of relying on the system to schedule between multiple activities. Most of the time it runs as a single process, so the output of “ps aux” on a system will report only one “haproxy” process, unless a soft reload is in progress and an older process is finishing its job in parallel to the new one. It is thus always easy to trace its activity using the strace utility. In order to scale with the number of available processors, by default haproxy will start one worker thread per processor it is allowed to run on. Unless explicitly configured differently, the incoming traffic is spread over all these threads, all running the same event loop. A great care is taken to limit inter-thread dependencies to the strict minimum, so as to try to achieve near-linear scalability. This has some impacts such as the fact that a given connection is served by a single thread. Thus in order to use all available processing capacity, it is needed to have at least as many connections as there are threads, which is almost always granted.

Internals

Mon, 01 Jan 0001 00:00:00 +0000

Learning

Mon, 01 Jan 0001 00:00:00 +0000

Data model

Mon, 01 Jan 0001 00:00:00 +0000

etcd is designed to reliably store infrequently updated data and provide reliable watch queries. etcd exposes previous versions of key-value pairs to support inexpensive snapshots and watch history events (“time travel queries”). A persistent, multi-version, concurrency-control data model is a good fit for these use cases.

etcd stores data in a multiversion persistent key-value store. The persistent key-value store preserves the previous version of a key-value pair when its value is superseded with new data. The key-value store is effectively immutable; its operations do not update the structure in-place, but instead always generate a new updated structure. All past versions of keys are still accessible and watchable after modification. To prevent the data store from growing indefinitely over time and from maintaining old versions, the store may be compacted to shed the oldest versions of superseded data.

etcd client design

Mon, 01 Jan 0001 00:00:00 +0000

etcd Client Design

Gyuho Lee (github.com/gyuho, Amazon Web Services, Inc.), Joe Betz (github.com/jpbetz, Google Inc.)

Introduction

etcd server has proven its robustness with years of failure injection testing. Most complex application logic is already handled by etcd server and its data stores (e.g. cluster membership is transparent to clients, with Raft-layer forwarding proposals to leader). Although server components are correct, its composition with client requires a different set of intricate protocols to guarantee its correctness and high availability under faulty conditions. Ideally, etcd server provides one logical cluster view of many physical machines, and client implements automatic failover between replicas. This documents client architectural decisions and its implementation details.

etcd learner design

Mon, 01 Jan 0001 00:00:00 +0000

etcd Learner

Gyuho Lee (github.com/gyuho, Amazon Web Services, Inc.), Joe Betz (github.com/jpbetz, Google Inc.)

Background

Membership reconfiguration has been one of the biggest operational challenges. Let’s review common challenges.

1. New Cluster member overloads Leader

A newly joined etcd member starts with no data, thus demanding more updates from leader until it catches up with leader’s logs. Then leader’s network is more likely to be overloaded, blocking or dropping leader heartbeats to followers. In such case, a follower may election-timeout to start a new leader election. That is, a cluster with a new member is more vulnerable to leader election. Both leader election and the subsequent update propagation to the new member are prone to causing periods of cluster unavailability (see Figure 1).

etcd v3 authentication design

Mon, 01 Jan 0001 00:00:00 +0000

Why not reuse the v2 auth system?

The v3 protocol uses gRPC as its transport instead of a RESTful interface like v2. This new protocol provides an opportunity to iterate on and improve the v2 design. For example, v3 auth has connection based authentication, rather than v2’s slower per-request authentication. Additionally, v2 auth’s semantics tend to be unwieldy in practice with respect to reasoning about consistency, which will be described in the next sections. For v3, there is a well-defined description and implementation of the authentication mechanism which fixes the deficiencies in the v2 auth system.

etcd API

Mon, 01 Jan 0001 00:00:00 +0000

This document is meant to give an overview of the v3 etcd APIs central design. This should not be mistaken with etcd v2 API, deprecated in etcd v3.5. It is by no means all encompassing, but intended to focus on the basic ideas needed to understand etcd without the distraction of less common API calls. All etcd APIs are defined in gRPC services , which categorize remote procedure calls (RPCs) understood by the etcd server. A full listing of all etcd RPCs are documented in markdown in the gRPC API listing .

etcd persistent storage files

Mon, 01 Jan 0001 00:00:00 +0000

This document explains the etcd persistent storage format: naming, content and tools that allow developers to inspect them. Going forward the document should be extended with changes to the storage model. This document is targeted at etcd developers to help with their data recovery needs.

Prerequisites

The following articles provide helpful background information for this document:

etcd data model overview
Raft overview (especially “5.3 Log replication” section).

Overview

Long leaving files

File name High level purpose

File name	High level purpose
./member/snap/db	bbolt b+tree that stores all the applied data, membership authorization information & metadata. It’s aware of what's the last applied WAL log index ("consistent_index").
./member/snap/0000000000000002-0000000000049425.snap ./member/snap/0000000000000002-0000000000061ace.snap	Periodic snapshots of legacy v2 store, containing: basic membership information etcd-version etcd API guarantees Mon, 01 Jan 0001 00:00:00 +0000 etcd is a consistent and durable key value store. The key value store is exposed through gRPC Services . etcd ensures the strongest consistency and durability guarantees for a distributed system. This specification enumerates the API guarantees made by etcd. APIs to consider KV APIs Range RangeStream Put Delete Transaction Watch APIs Watch Lease APIs Grant [Revoke] Keep alive KV API allows for direct reading and manipulation of key value store. Watch API allows subscribing to key value store changes. Lease API allows assigning a time to live to a key. etcd versus other key-value stores Mon, 01 Jan 0001 00:00:00 +0000 The name “etcd” originated from two ideas, the unix “/etc” folder and “d"istributed systems. The “/etc” folder is a place to store configuration data for a single system whereas etcd stores configuration information for large scale distributed systems. Hence, a “d"istributed “/etc” is “etcd”. etcd is designed as a general substrate for large scale distributed systems. These are systems that will never tolerate split-brain operation and are willing to sacrifice availability to achieve this end. etcd stores metadata in a consistent and fault-tolerant way. An etcd cluster is meant to provide key-value storage with best of class stability, reliability, scalability and performance. Why gRPC gateway Mon, 01 Jan 0001 00:00:00 +0000 etcd v3 uses gRPC for its messaging protocol. The etcd project includes a gRPC-based Go client and a command line utility, etcdctl , for communicating with an etcd cluster through gRPC. For languages with no gRPC support, etcd provides a JSON gRPC gateway . This gateway serves a RESTful proxy that translates HTTP/JSON requests into gRPC messages. Using gRPC gateway The gateway accepts a JSON mapping for etcd’s protocol buffer message definitions. Note that `key` and `value` fields are defined as byte arrays and therefore must be base64 encoded in JSON. The following examples use `curl`, but any HTTP/JSON client should work all the same. Failure modes Mon, 01 Jan 0001 00:00:00 +0000 Failures are common in a large deployment of machines. A machine fails when its hardware or software malfunctions. Multiple machines fail together when there are power failures or network issues. Multiple kinds of failures can also happen at once; it is almost impossible to enumerate all possible failure cases. In this section, we catalog kinds of failures and discuss how etcd is designed to tolerate these failures. Most users, if not all, can map a particular failure into one kind of failure. To prepare for rare or unrecoverable failures , always back up the etcd cluster. Performance Mon, 01 Jan 0001 00:00:00 +0000 Understanding performance etcd provides stable, sustained high performance. Two factors define performance: latency and throughput. Latency is the time taken to complete an operation. Throughput is the total operations completed within some time period. Usually average latency increases as the overall throughput increases when etcd accepts concurrent client requests. In common cloud environments, like a standard `n-4` on Google Compute Engine (GCE) or a comparable machine type on AWS, a three member etcd cluster finishes a request in less than one millisecond under light load, and can complete more than 30,000 requests per second under heavy load. Design of runtime reconfiguration Mon, 01 Jan 0001 00:00:00 +0000 Runtime reconfiguration is one of the hardest and most error prone features in a distributed system, especially in a consensus based system like etcd. Read on to learn about the design of etcd’s runtime reconfiguration commands and how we tackled these problems. Two phase config changes keep the cluster safe In etcd, every runtime reconfiguration has to go through two phases for safety reasons. For example, to add a member, first inform the cluster of the new configuration and then start the new member. Versioning Mon, 01 Jan 0001 00:00:00 +0000 This document describes the versions supported by the etcd project. Service versioning and supported versions etcd versions are expressed as x.y.z, where x is the major version, y is the minor version, and z is the patch version, following Semantic Versioning terminology. New minor versions may add additional features to the API. The etcd project maintains release branches for the current version and previous release. For example, when v3.5 is the current version, v3.4 is supported. When v3.6 is released, v3.4 goes out of support.

./member/snap/db

bbolt b+tree that stores all the applied data, membership authorization information & metadata. It’s aware of what's the last applied WAL log index ("consistent_index").

./member/snap/0000000000000002-0000000000049425.snap
./member/snap/0000000000000002-0000000000061ace.snap

Periodic snapshots of legacy v2 store, containing:

basic membership information
etcd-version

etcd API guarantees

Mon, 01 Jan 0001 00:00:00 +0000

etcd is a consistent and durable key value store. The key value store is exposed through gRPC Services . etcd ensures the strongest consistency and durability guarantees for a distributed system. This specification enumerates the API guarantees made by etcd.

APIs to consider

KV APIs
- Range
- RangeStream
- Put
- Delete
- Transaction
Watch APIs
- Watch
Lease APIs
- Grant
- [Revoke]
- Keep alive

KV API allows for direct reading and manipulation of key value store. Watch API allows subscribing to key value store changes. Lease API allows assigning a time to live to a key.

etcd versus other key-value stores

Mon, 01 Jan 0001 00:00:00 +0000

The name “etcd” originated from two ideas, the unix “/etc” folder and “d"istributed systems. The “/etc” folder is a place to store configuration data for a single system whereas etcd stores configuration information for large scale distributed systems. Hence, a “d"istributed “/etc” is “etcd”.

etcd is designed as a general substrate for large scale distributed systems. These are systems that will never tolerate split-brain operation and are willing to sacrifice availability to achieve this end. etcd stores metadata in a consistent and fault-tolerant way. An etcd cluster is meant to provide key-value storage with best of class stability, reliability, scalability and performance.

Why gRPC gateway

Mon, 01 Jan 0001 00:00:00 +0000

etcd v3 uses gRPC for its messaging protocol. The etcd project includes a gRPC-based Go client and a command line utility, etcdctl , for communicating with an etcd cluster through gRPC. For languages with no gRPC support, etcd provides a JSON gRPC gateway . This gateway serves a RESTful proxy that translates HTTP/JSON requests into gRPC messages.

Using gRPC gateway

The gateway accepts a JSON mapping for etcd’s protocol buffer message definitions. Note that key and value fields are defined as byte arrays and therefore must be base64 encoded in JSON. The following examples use curl, but any HTTP/JSON client should work all the same.

Failure modes

Mon, 01 Jan 0001 00:00:00 +0000

Failures are common in a large deployment of machines. A machine fails when its hardware or software malfunctions. Multiple machines fail together when there are power failures or network issues. Multiple kinds of failures can also happen at once; it is almost impossible to enumerate all possible failure cases.

In this section, we catalog kinds of failures and discuss how etcd is designed to tolerate these failures. Most users, if not all, can map a particular failure into one kind of failure. To prepare for rare or unrecoverable failures , always back up the etcd cluster.

Performance

Mon, 01 Jan 0001 00:00:00 +0000

Understanding performance

etcd provides stable, sustained high performance. Two factors define performance: latency and throughput. Latency is the time taken to complete an operation. Throughput is the total operations completed within some time period. Usually average latency increases as the overall throughput increases when etcd accepts concurrent client requests. In common cloud environments, like a standard n-4 on Google Compute Engine (GCE) or a comparable machine type on AWS, a three member etcd cluster finishes a request in less than one millisecond under light load, and can complete more than 30,000 requests per second under heavy load.

Design of runtime reconfiguration

Mon, 01 Jan 0001 00:00:00 +0000

Runtime reconfiguration is one of the hardest and most error prone features in a distributed system, especially in a consensus based system like etcd.

Read on to learn about the design of etcd’s runtime reconfiguration commands and how we tackled these problems.

Two phase config changes keep the cluster safe

In etcd, every runtime reconfiguration has to go through two phases for safety reasons. For example, to add a member, first inform the cluster of the new configuration and then start the new member.

Versioning

Mon, 01 Jan 0001 00:00:00 +0000

This document describes the versions supported by the etcd project.

Service versioning and supported versions

etcd versions are expressed as x.y.z, where x is the major version, y is the minor version, and z is the patch version, following Semantic Versioning terminology. New minor versions may add additional features to the API.

The etcd project maintains release branches for the current version and previous release. For example, when v3.5 is the current version, v3.4 is supported. When v3.6 is released, v3.4 goes out of support.