diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml new file mode 100644 index 0000000..03bf668 --- /dev/null +++ b/.github/workflows/lint.yml @@ -0,0 +1,28 @@ +--- +name: Lint + +on: # yamllint disable-line rule:truthy + push: + branches: [main] + pull_request: + branches: [main] + +permissions: {} + +jobs: + naming-lint: + name: Naming Lint + runs-on: ubuntu-latest + + permissions: + contents: read + + steps: + - name: Checkout code + uses: actions/checkout@v4 + with: + persist-credentials: false + + - name: Check Multigres name capitalization + run: ./tools/naming_linter.sh + shell: bash diff --git a/content/blog/deploying-the-multigres-operator.mdx b/content/blog/deploying-the-multigres-operator.mdx index d3f3385..d66550c 100644 --- a/content/blog/deploying-the-multigres-operator.mdx +++ b/content/blog/deploying-the-multigres-operator.mdx @@ -29,13 +29,13 @@ A Multigres cluster is made up of several components that work together across a **GlobalTopoServer** is a managed etcd cluster that records the topology state: which databases exist, which cells they live in, and where every component is registered. Cells are user-defined groupings that map to availability zones. In a multi-zone deployment, the topology splits into a global server for cluster-wide state and per-cell servers for local discovery, so a partitioned cell keeps operating against its own local view. -**MultiAdmin** is the management plane for the cluster, including a web UI. +**Multiadmin** is the management plane for the cluster, including a web UI. -**MultiGateway** speaks the Postgres wire protocol. Your application connects to a gateway, which forwards queries to the right MultiPooler over gRPC. Adding more gateways scales Multigres’ connection capacity horizontally. +**Multigateway** speaks the Postgres wire protocol. Your application connects to a gateway, which forwards queries to the right Multipooler over gRPC. Adding more gateways scales Multigres’ connection capacity horizontally. -**MultiOrch:** the orchestrator. One set of MultiOrch instances per shard, running across cells. It watches replication health, appoints leaders through a consensus protocol, runs failovers, and coordinates bootstrap, backup, restore, and scaling events. When you apply the manifest, MultiOrch runs bootstrap as a consensus-backed election. This is the same code path as every later failover- so, there is no separate provisioning script that can race with itself. +**Multiorch:** the orchestrator. One set of Multiorch instances per shard, running across cells. It watches replication health, appoints leaders through a consensus protocol, runs failovers, and coordinates bootstrap, backup, restore, and scaling events. When you apply the manifest, Multiorch runs bootstrap as a consensus-backed election. This is the same code path as every later failover- so, there is no separate provisioning script that can race with itself. -**Postgres** pods themselves, managed by pgctld which owns the local Postgres process and MultiPooler. One pooler per Postgres instance. +**Postgres** pods themselves, managed by pgctld which owns the local Postgres process and Multipooler. One pooler per Postgres instance. ## Deploying on EKS @@ -45,7 +45,7 @@ The short version of what you need is a kubeconfig pointed at an EKS cluster wit In the Manifest linked to above, you’ll see three cells, each mapped to a real AWS availability zone. `AT_LEAST_2` durability means every committed write is acknowledged by one standby (one primary and one standby). The operator infers everything else from the templates: resource limits, gateway configuration, topo server sizing — and builds the full topology. -Run `kubectl apply -f demo-multi-az.yaml` and then `kubectl get pods -w`. Within a minute you have a global topo server, MultiAdmin, MultiGateway, MultiOrch across three zones, and Postgres pool pods across three zones. +Run `kubectl apply -f demo-multi-az.yaml` and then `kubectl get pods -w`. Within a minute you have a global topo server, Multiadmin, Multigateway, Multiorch across three zones, and Postgres pool pods across three zones. You should eventually see pods for global topo, multiadmin, multigateway, multiorch, and three poolers. @@ -78,7 +78,7 @@ The operator provisions new standby pods across all three zones simultaneously. ## Connecting -Applications inside the cluster connect through the MultiGateway service: +Applications inside the cluster connect through the Multigateway service: `postgresql://postgres:@demo-multi-az-multigateway:5432/postgres` diff --git a/content/blog/drop-in-postgres-proven-with-a-real-app.mdx b/content/blog/drop-in-postgres-proven-with-a-real-app.mdx index 64e5d3c..3afcf4b 100644 --- a/content/blog/drop-in-postgres-proven-with-a-real-app.mdx +++ b/content/blog/drop-in-postgres-proven-with-a-real-app.mdx @@ -43,16 +43,16 @@ Most poolers impose a hard limit on client connections. Once that limit is reach Multigres splits connection pooling into two distinct jobs: -1. `MultiGateway` is the tier that accepts client connections. It scales horizontally: connection capacity grows by adding gateways, not by tuning a single process. That is where the large connection counts come from. -2. `MultiPooler` sits behind MultiGateway and runs next to every Postgres instance. It manages the real Postgres connections - a small, stable set that client connections are multiplexed onto. +1. `Multigateway` is the tier that accepts client connections. It scales horizontally: connection capacity grows by adding gateways, not by tuning a single process. That is where the large connection counts come from. +2. `Multipooler` sits behind Multigateway and runs next to every Postgres instance. It manages the real Postgres connections - a small, stable set that client connections are multiplexed onto. The gateway gives you the connections and the pooler keeps the backend side small. Both are managed by the same Multigres machinery that is responsible for replication and failover. ## Pooling as a property of the cluster -In Multigres, connection pooling is a property of the cluster, not a service bolted on in front of it. Each Postgres instance has its own `MultiPooler`, co-located with it and registered in the same topology as the rest of the cluster. +In Multigres, connection pooling is a property of the cluster, not a service bolted on in front of it. Each Postgres instance has its own `Multipooler`, co-located with it and registered in the same topology as the rest of the cluster. -This pooler also supervises the Postgres instance. If Postgres goes down, the pooler is the component that notices and brings it back, through `pgctld`. `MultiOrch` handles failover across instances, and the gateway watches the topology - when the primary moves, the gateway routes to whichever pooler now owns it. The application keeps talking to the gateway and is unaware that anything has changed. +This pooler also supervises the Postgres instance. If Postgres goes down, the pooler is the component that notices and brings it back, through `pgctld`. `Multiorch` handles failover across instances, and the gateway watches the topology - when the primary moves, the gateway routes to whichever pooler now owns it. The application keeps talking to the gateway and is unaware that anything has changed. ## Technical Deep Dive diff --git a/content/blog/handling-edge-cases-using-consensus.mdx b/content/blog/handling-edge-cases-using-consensus.mdx index e530428..2d97141 100644 --- a/content/blog/handling-edge-cases-using-consensus.mdx +++ b/content/blog/handling-edge-cases-using-consensus.mdx @@ -19,7 +19,7 @@ The full demo: Start with the simplest version. A Multigres cluster has one primary and two replicas. An operator wants a third replica, for read capacity, for a multi-zone deployment, or to prepare for a planned shrink elsewhere. -The Kubernetes operator scales the number of replicas from three to four. A new pod comes up. A new MultiPooler registers in the topology of the cluster. A new Postgres process starts as a fresh replica. The orchestrator notices the new node and brings it into the cluster. +The Kubernetes operator scales the number of replicas from three to four. A new pod comes up. A new Multipooler registers in the topology of the cluster. A new Postgres process starts as a fresh replica. The orchestrator notices the new node and brings it into the cluster. The naive way to bring it in is to point the new replica at the current primary, let it restore from a backup, let it stream WAL forward, and once it has caught up, count it as a member. @@ -27,7 +27,7 @@ The naive approach is wrong because it treats membership as a local orchestratio ## The race -The hard part in distributed systems is that changes take time to propagate, and agents may take action based on stale information. Multiple MultiOrch instances are watching the cluster from different cells. They do not share local state, and for short periods of time they can have different views of the world. The challenge is that those local decisions still have to honor the cluster's consensus rules. That is intentional. It is part of what makes the orchestrator partition-tolerant. +The hard part in distributed systems is that changes take time to propagate, and agents may take action based on stale information. Multiple Multiorch instances are watching the cluster from different cells. They do not share local state, and for short periods of time they can have different views of the world. The challenge is that those local decisions still have to honor the cluster's consensus rules. That is intentional. It is part of what makes the orchestrator partition-tolerant. The risk appears when cluster membership is implemented naively using only the local view of a coordinator. During a membership change, one orchestrator may already believe a new replica has joined, while another may still be operating with the old view of the cluster. diff --git a/content/blog/high-availability-from-first-principles.mdx b/content/blog/high-availability-from-first-principles.mdx index 6702a35..5d06c9c 100644 --- a/content/blog/high-availability-from-first-principles.mdx +++ b/content/blog/high-availability-from-first-principles.mdx @@ -31,9 +31,9 @@ Multigres provides strict guarantees. The HA implementation is anchored in a bod Together, these enable the team change the implementation with confidence. New failover scenarios do not require re-proving the safety of the entire system. Instead, each change is evaluated against a well-defined set of invariants that preserve the core guarantees. -## MultiOrch: the coordinator +## Multiorch: the coordinator -The HA coodinator in Multigres is called "MultiOrch". It uses a more efficient approach to HA than most other database implementations. Take a Raft implementation, where every node is a candidate: nodes vote among themselves, elect a leader, and replicate the log. The members do all the work. +The HA coodinator in Multigres is called "Multiorch". It uses a more efficient approach to HA than most other database implementations. Take a Raft implementation, where every node is a candidate: nodes vote among themselves, elect a leader, and replicate the log. The members do all the work. Generalized consensus separates the roles: @@ -42,11 +42,11 @@ Generalized consensus separates the roles: 3. `Observers` replicate completed requests for read scaling. 4. `Coordinators` run health checks, detect failures, and drive rule changes (including leadership changes). -In Multigres, MultiOrch is the coordinator and Postgres processes can be leaders, followers, or observers depending on their state. +In Multigres, Multiorch is the coordinator and Postgres processes can be leaders, followers, or observers depending on their state. -In our deployments, we spread each Postgres cluster across three availability zones to provide cross-AZ redundancy. We also run MultiOrch in multiple AZs so that the system can tolerate a coordinator becoming network-partitioned from part of the cluster. +In our deployments, we spread each Postgres cluster across three availability zones to provide cross-AZ redundancy. We also run Multiorch in multiple AZs so that the system can tolerate a coordinator becoming network-partitioned from part of the cluster. -Typically there are two or three MultiOrch instances per shard, one per cell, each watching the cluster from an independent vantage point. They can all act independently and they do not talk to each other directly. Each instance observes the state of the shard, detects failures independently, and races to repair the cluster when it sees a problem. +Typically there are two or three Multiorch instances per shard, one per cell, each watching the cluster from an independent vantage point. They can all act independently and they do not talk to each other directly. Each instance observes the state of the shard, detects failures independently, and races to repair the cluster when it sees a problem. The remediation follows the consensus rules. A coordinator that wants to perform a leadership change has to: @@ -63,13 +63,13 @@ If two coordinators race, only one can complete the sequence. The other one noti The demo video above demonstrates the full sequence of a primary failover in a local Kubernetes cluster. This is what happens in that sequence of events from the consensus perspective: -**Detection:** The cluster is healthy: one primary, two replicas, three MultiOrch instances watching. A demo button kills the Postgres process on the primary. Within a configurable timeout, every MultiOrch notices that the primary's pooler has stopped reporting healthy status. +**Detection:** The cluster is healthy: one primary, two replicas, three Multiorch instances watching. A demo button kills the Postgres process on the primary. Within a configurable timeout, every Multiorch notices that the primary's pooler has stopped reporting healthy status. -**Race:** Each MultiOrch starts a failover attempt. Each one picks a new term number, one higher than any term it has observed on the cohort, and asks the replicas to pledge to it. Replicas accept only one coordinator per term, so only one MultiOrch can gather a quorum of pledges for this round. The losers back off and retry later if needed. +**Race:** Each Multiorch starts a failover attempt. Each one picks a new term number, one higher than any term it has observed on the cohort, and asks the replicas to pledge to it. Replicas accept only one coordinator per term, so only one Multiorch can gather a quorum of pledges for this round. The losers back off and retry later if needed. **Revocation:** The quorum's pledge to a new term is the revocation, and we recruit enough replicas for it to do two things. First, the old primary can no longer satisfy the cluster's durability policy with whatever replicas remain, so it can't durably commit any new writes under the old term. Second, we recruit enough replicas that they can't be part of any other quorum either, preventing a network-partitioned slice of the cluster from forming an independent quorum and electing a competing leader. This gives the coordinator sole authority to establish the next rule (in this demo the new leadership). -**Discovery:** The winning MultiOrch inspects the WAL position reported by each pledged replica and identifies the most-advanced replica that satisfies the durability requirements. +**Discovery:** The winning Multiorch inspects the WAL position reported by each pledged replica and identifies the most-advanced replica that satisfies the durability requirements. **Candidacy:** The new leader is chosen from the nodes already tied at that most-advanced position. There may be more than one; any of them is safe. Reachability and the cluster's durability policy are checked against the proposed cohort before the choice is finalized. diff --git a/content/blog/multigres-cluster-bootstrap.mdx b/content/blog/multigres-cluster-bootstrap.mdx index 19ed466..c89caf2 100644 --- a/content/blog/multigres-cluster-bootstrap.mdx +++ b/content/blog/multigres-cluster-bootstrap.mdx @@ -17,10 +17,10 @@ A recording of the same flow: A Multigres deployment runs four services alongside Postgres, plus a topology server. -- **MultiGateway.** Speaks the Postgres wire protocol, so your application thinks it is talking to a Postgres server. The gateway forwards queries to the right MultiPooler over gRPC. -- **MultiPooler.** Sits next to a single Postgres instance and owns its connection pool. One pooler per Postgres process. +- **Multigateway.** Speaks the Postgres wire protocol, so your application thinks it is talking to a Postgres server. The gateway forwards queries to the right Multipooler over gRPC. +- **Multipooler.** Sits next to a single Postgres instance and owns its connection pool. One pooler per Postgres process. - **pgctld.** Runs alongside the pooler and manages the local Postgres process: `initdb`, start, stop, restart. -- **MultiOrch.** The orchestrator. Watches replication, appoints leaders, runs failovers, and coordinates bootstrap, backup, restore, and scale. +- **Multiorch.** The orchestrator. Watches replication, appoints leaders, runs failovers, and coordinates bootstrap, backup, restore, and scale. - **Topology server.** A distributed key-value store, typically etcd. Records which databases exist, which cells they live in, and where every component is registered. Cells are user-defined groupings that map to availability zones or regions. In a multi-zone deployment, the topology splits into a global server holding cluster-wide state and per-cell servers holding local discovery state. A partitioned cell keeps operating against its own local view. @@ -33,7 +33,7 @@ When the manifest applies, each service registers itself with the topology serve Poolers register next, each bound to a Postgres instance through pgctld. Every data directory is empty. Every pooler advertises itself as REPLICA, the safe default. The cluster still has no primary. -This is the most fragile moment of a cluster's life. If a hand-rolled bootstrap script picked a primary now, two scripts could run in parallel and pick two different primaries. This is a split-brain. Multigres avoids it by coordinating leader appointment through MultiOrch, which runs as a small set of independent instances that agree on the leader through our [consensus protocol](/blog/generalized-consensus-part1). +This is the most fragile moment of a cluster's life. If a hand-rolled bootstrap script picked a primary now, two scripts could run in parallel and pick two different primaries. This is a split-brain. Multigres avoids it by coordinating leader appointment through Multiorch, which runs as a small set of independent instances that agree on the leader through our [consensus protocol](/blog/generalized-consensus-part1). ## Seed backup first, then leader @@ -43,9 +43,9 @@ Bootstrap runs in two phases. Each pooler independently runs `initdb`, starts Postgres through pgctld, and creates the Multigres schema and pgBackRest stanza. The poolers then race for a backup lease. One wins, takes a full backup of its local data directory, and writes it to S3. The others find that a backup already exists and skip the create step. Every pooler then tears down its local data directory and restores from the shared backup. After this phase, every pooler holds the same restored state, in hot-standby mode. -### Phase 2: MultiOrch appoints the initial leader +### Phase 2: Multiorch appoints the initial leader -MultiOrch waits for enough initialized poolers to satisfy the durability policy. It then claims the exclusive right to initialize the shard, picks one of the restored poolers as the leader, and promotes it to primary. The other poolers point at the new primary and start streaming WAL. +Multiorch waits for enough initialized poolers to satisfy the durability policy. It then claims the exclusive right to initialize the shard, picks one of the restored poolers as the leader, and promotes it to primary. The other poolers point at the new primary and start streaming WAL. Bootstrap and failover share the same election code path. A new cluster is a failover with no prior leader. diff --git a/content/docs/architecture.mdx b/content/docs/architecture.mdx index 5939a61..5d2f98e 100644 --- a/content/docs/architecture.mdx +++ b/content/docs/architecture.mdx @@ -55,23 +55,23 @@ In a single database deployment, Multigres will act as a proxy layer in front of The main components involved will be: -- **MultiGateway**: MultiGateway will speak the Postgres protocol and route queries to MultiPooler through a single multiplexed gRPC connection. -- **MultiPooler**: The MultiPooler will be connected to a single Postgres server, and will manage a pool of connections to the database. They will both run on the same host, which will typically be a Kubernetes pod. +- **Multigateway**: Multigateway will speak the Postgres protocol and route queries to Multipooler through a single multiplexed gRPC connection. +- **Multipooler**: The Multipooler will be connected to a single Postgres server, and will manage a pool of connections to the database. They will both run on the same host, which will typically be a Kubernetes pod. In this scenario, Multigres will not address the durability of the underlying data. Therefore, it is recommended to use a resilient form of cloud storage to ensure data safety. For a Multigres cluster to operate, two other components will be required: -- **Provisioner**: This will typically be a Kubernetes operator that handles provisioning of resources for the cluster. For example, a `CREATE DATABASE` command will be redirected to the provisioner that will allocate the necessary resources and launch the MultiPooler along with its associated Postgres instance. -- **Topo Server**: This will typically be an etcd cluster. The Provisioner will store the existence of the newly created database in the Topo Server. The MultiPooler will also register itself in the Topo Server to allow MultiGateway to discover it. +- **Provisioner**: This will typically be a Kubernetes operator that handles provisioning of resources for the cluster. For example, a `CREATE DATABASE` command will be redirected to the provisioner that will allocate the necessary resources and launch the Multipooler along with its associated Postgres instance. +- **Topo Server**: This will typically be an etcd cluster. The Provisioner will store the existence of the newly created database in the Topo Server. The Multipooler will also register itself in the Topo Server to allow Multigateway to discover it. ## Multiple database deployment -Unlike a traditional Postgres server, every Multigres database will be created in a brand new Postgres instance coupled with its own MultiPooler. +Unlike a traditional Postgres server, every Multigres database will be created in a brand new Postgres instance coupled with its own Multipooler. Multiple database deployment -The MultiGateways will be scalable independently based on resource needs. The application will connect to any MultiGateway, which will route the queries to the appropriate MultiPooler based on the database name. +The Multigateways will be scalable independently based on resource needs. The application will connect to any Multigateway, which will route the queries to the appropriate Multipooler based on the database name. This deployment style will allow for a large number of databases to be deployed under a single Multigres cluster. @@ -79,21 +79,21 @@ The figure does not show the Topo Server and Provisioner components, but they wi ## Performance and High Availability -Multigres can be configured to add replicas as standbys. In this setup, we introduce the `MultiOrch` component, which manages the health of replication across replicas. It monitors replication, repairs broken streams, and coordinates failover, ensuring replicas remain in sync with the primary database. +Multigres can be configured to add replicas as standbys. In this setup, we introduce the `Multiorch` component, which manages the health of replication across replicas. It monitors replication, repairs broken streams, and coordinates failover, ensuring replicas remain in sync with the primary database. ![High Availability and Performance](/img/site/arch-ha.svg) -MultiOrch will implement a distributed consensus algorithm that will provide the following benefits: +Multiorch will implement a distributed consensus algorithm that will provide the following benefits: - **High Availability**: by promoting one of the replicas to be the new primary in case of a failure. - **Data Durability**: by ensuring that all writes are acknowledged by a quorum of replicas before being considered successful. - **Performance**: because the data can be stored on a local NVMe for faster access. -MultiOrch will operate on an unmodified Postgres engine by using full sync replication. For a better experience, we recommend using the two-phase sync plug in (more details on this later). +Multiorch will operate on an unmodified Postgres engine by using full sync replication. For a better experience, we recommend using the two-phase sync plug in (more details on this later). -MultiOrch will be configurable to use a Raft style majority quorum. It will also be configurable to support more advanced durability policies that don't depend on the quorum size. This will be achieved by using a new generalized consensus approach (covered later). +Multiorch will be configurable to use a Raft style majority quorum. It will also be configurable to support more advanced durability policies that don't depend on the quorum size. This will be achieved by using a new generalized consensus approach (covered later). -MultiGateway will make use of the replicas to scale reads for situations where the application can tolerate eventual consistency. It will also be configurable to support consistent reads from replicas at the cost of waiting for writes to finish transmitting the data to the replicas. +Multigateway will make use of the replicas to scale reads for situations where the application can tolerate eventual consistency. It will also be configurable to support consistent reads from replicas at the cost of waiting for writes to finish transmitting the data to the replicas. ## Cluster management @@ -109,23 +109,23 @@ In a multi-cell deployment, the Topo Server will be splittable into multiple ins The Global Topo Server will contain the list of databases and the cells in which replicas are deployed. This information will be used more sparingly. -The cell-specific topo servers will contain the list of components deployed in that cell, such as MultiGateways and MultiPoolers. The purpose of this design is to ensure that a cell that is partitioned from the rest of the system can continue to operate independently for as long as the data is not stale. +The cell-specific topo servers will contain the list of components deployed in that cell, such as Multigateways and Multipoolers. The purpose of this design is to ensure that a cell that is partitioned from the rest of the system can continue to operate independently for as long as the data is not stale. ### Single Primary -Irrespective of the number of cells, there will exist only one primary database at any given time. The MultiGateways will route all requests meant for the primary to the current primary even if it is not in the same cell. +Irrespective of the number of cells, there will exist only one primary database at any given time. The Multigateways will route all requests meant for the primary to the current primary even if it is not in the same cell. However, read traffic directed at replicas will be served from the local cell. -### MultiOrch +### Multiorch -It will be recommended that one MultiOrch be deployed per cell to ensure that failovers can be successfully performed even if the network is partitioned. +It will be recommended that one Multiorch be deployed per cell to ensure that failovers can be successfully performed even if the network is partitioned. -The consensus protocol will ensure safety even if the MultiOrchs are not able to communicate with each other. +The consensus protocol will ensure safety even if the Multiorchs are not able to communicate with each other. The durability policies will be settable to survive network partitions. For example, you may request a cross-cell durability policy that will require an acknowledgment from a replica in a different cell before considering a write successful. -You will also be able to request MultiOrch to prefer appointing a primary within the same cell as the previous primary to avoid unnecessary churn. +You will also be able to request Multiorch to prefer appointing a primary within the same cell as the previous primary to avoid unnecessary churn. ### Backup and Restore @@ -159,13 +159,13 @@ If cells were one axis of a Multigres cluster, then shards would be another axis In a fully deployed cluster, the components will function in the following ways: -* **MultiGateway**: There can be multiple instances of MultiGateways in each cell. A MultiGateway uses MultiPoolers within the current cell to serve traffic. If necessary, a MultiGateway would go cross-cell to access a primary if it's not in the current cell. The user or application can connect to any MultiGateway to run their queries. +* **Multigateway**: There can be multiple instances of Multigateways in each cell. A Multigateway uses Multipoolers within the current cell to serve traffic. If necessary, a Multigateway would go cross-cell to access a primary if it's not in the current cell. The user or application can connect to any Multigateway to run their queries. -* **MultiPooler**: There will be one instance of MultiPooler per Postgres instance. Such an instance contains the data for one shard. Among all MultiPoolers, one of them will be the primary and the others will be standbies or replicas. +* **Multipooler**: There will be one instance of Multipooler per Postgres instance. Such an instance contains the data for one shard. Among all Multipoolers, one of them will be the primary and the others will be standbies or replicas. -* **MultiOrch**: A MultiOrch watches over a single shard across all cells. For a given shard, it is recommended that a MultiOrch be provisioned for each cell. This allows for resilience against network partitions. If one MultiOrch does not have the connectivity to perform a failover, another one in a different can take over. The MultiOrchs are capable of operating without interfering with each other. +* **Multiorch**: A Multiorch watches over a single shard across all cells. For a given shard, it is recommended that a Multiorch be provisioned for each cell. This allows for resilience against network partitions. If one Multiorch does not have the connectivity to perform a failover, another one in a different can take over. The Multiorchs are capable of operating without interfering with each other. -* **Local Toposerver**: One local toposerver per cell is required. For smaller deployments, the global toposerver could also be reused for this purpose. However, it is recommended that separate local toposervers be provisioned for each cell in case of larger deployments. This server is used for components within a cell to discover each other. For example, a MultiPooler will publish itself through the toposerver, which will allow MultiGateway to discover its existence. +* **Local Toposerver**: One local toposerver per cell is required. For smaller deployments, the global toposerver could also be reused for this purpose. However, it is recommended that separate local toposervers be provisioned for each cell in case of larger deployments. This server is used for components within a cell to discover each other. For example, a Multipooler will publish itself through the toposerver, which will allow Multigateway to discover its existence. * **Global Toposerver**: One global toposerver is needed to store the list of cells, the list of databases, and their backup locations. The global toposerver is typically deployed across multiple cells to survive network partitions. diff --git a/content/docs/index.mdx b/content/docs/index.mdx index 30ec717..c8af8a8 100644 --- a/content/docs/index.mdx +++ b/content/docs/index.mdx @@ -10,19 +10,19 @@ This document is a loosely ordered tentative list of features we intend to build Multigres will have a two-level proxy layer. In the case of a single small server, the primary benefit of these two layers would be connection pooling. -### MultiGateway +### Multigateway -MultiGateway is the top layer. In its simplest form, it will masquerade as a Postgres server. When it receives a query, it will forward the request to the next (MultiPooler) layer. In the case of a single Postgres server, its primary usefulness is to shield the clients from restarts or failovers that may happen in the underlying layers due to software rollouts and failures. +Multigateway is the top layer. In its simplest form, it will masquerade as a Postgres server. When it receives a query, it will forward the request to the next (Multipooler) layer. In the case of a single Postgres server, its primary usefulness is to shield the clients from restarts or failovers that may happen in the underlying layers due to software rollouts and failures. -In the case of primary-replica configurations, MultiGateway can be configured to send read traffic to the replicas. +In the case of primary-replica configurations, Multigateway can be configured to send read traffic to the replicas. -The MultiGateway layer could be conceptualized as the compute layer of Multigres. It can be horizontally scaled as needed. +The Multigateway layer could be conceptualized as the compute layer of Multigres. It can be horizontally scaled as needed. -### MultiPooler +### Multipooler -There will be one MultiPooler per Postgres instance. MultiPooler's primary function is to provide connection pooling. It will be aware of transaction state and connection specific changes of state, and will preserve the correct behavior to the clients connected at the MultiGateway level. +There will be one Multipooler per Postgres instance. Multipooler's primary function is to provide connection pooling. It will be aware of transaction state and connection specific changes of state, and will preserve the correct behavior to the clients connected at the Multigateway level. -Each MultiPooler, its associated Postgres instance, and its storage are treated as one unit. This trio can be conceptualized as one node in the storage layer. In this layer, data can be replicated and/or sharded across other (trio) nodes as needed. Traditional storage layers typically implement a file or object store API. In the case of Multigres, the storage layer API is that of a database. +Each Multipooler, its associated Postgres instance, and its storage are treated as one unit. This trio can be conceptualized as one node in the storage layer. In this layer, data can be replicated and/or sharded across other (trio) nodes as needed. Traditional storage layers typically implement a file or object store API. In the case of Multigres, the storage layer API is that of a database. ## Sharding @@ -32,27 +32,27 @@ Multigres will provide a powerful relational sharding model that will help you k TODO: Doc on Vitess sharding model -### MultiGateway (Sharding) +### Multigateway (Sharding) -In a sharded setup, MultiGateway's functionality will expand to present this distributed cluster as if it was a single Postgres server. For simpler queries, it will just act as a routing layer by sending it to where the data is. For more complex queries, it will act as a database engine while maximally leveraging the capabilities of the individual databases underneath. +In a sharded setup, Multigateway's functionality will expand to present this distributed cluster as if it was a single Postgres server. For simpler queries, it will just act as a routing layer by sending it to where the data is. For more complex queries, it will act as a database engine while maximally leveraging the capabilities of the individual databases underneath. -MultiGateway will have the ability to push entire join queries into an underlying shard if it determines that all data for that join is within that shard. Similarly, MultiGateway will "scatter" entire joins across all shards if it determines that the related rows of a join are within their respective shards. +Multigateway will have the ability to push entire join queries into an underlying shard if it determines that all data for that join is within that shard. Similarly, Multigateway will "scatter" entire joins across all shards if it determines that the related rows of a join are within their respective shards. -### MultiPooler (Sharding) +### Multipooler (Sharding) -The query serving functionality of MultiPooler will have no awareness of sharding. It will just use the underlying Postgres instance to serve the requested queries. However, MultiPooler will be the workhorse behind facilitating all the resharding efforts. +The query serving functionality of Multipooler will have no awareness of sharding. It will just use the underlying Postgres instance to serve the requested queries. However, Multipooler will be the workhorse behind facilitating all the resharding efforts. -When the need to reshard arises, new (target) MultiPoolers will be created to receive filtered data from the original unsharded table. This data will be streamed by the source MultiPooler. Once these tables are populated and up-to-date, a failover will be performed to move traffic to the sharded MultiPoolers. For safety, the replication will be reversed. If any issue is found after the cut-over, it can be undone by switching traffic back to the source tables. +When the need to reshard arises, new (target) Multipoolers will be created to receive filtered data from the original unsharded table. This data will be streamed by the source Multipooler. Once these tables are populated and up-to-date, a failover will be performed to move traffic to the sharded Multipoolers. For safety, the replication will be reversed. If any issue is found after the cut-over, it can be undone by switching traffic back to the source tables. This failover and fail-back can be repeatedly performed without requiring any change in the application. ### 2PC -Due to the flexible sharding scheme of Multigres, you should be able to minimize or completely eliminate the need for distributed transactions by a careful selection of an optimal sharding scheme. However, if the need arises, MultiGateway and MultiPooler will work together and use the two-phase commit protocol supported by Postgres to complete transactions that span across multiple instances. +Due to the flexible sharding scheme of Multigres, you should be able to minimize or completely eliminate the need for distributed transactions by a careful selection of an optimal sharding scheme. However, if the need arises, Multigateway and Multipooler will work together and use the two-phase commit protocol supported by Postgres to complete transactions that span across multiple instances. TODO: Doc on 2PC atomicity and isolation -## MultiOrch: NVME performance, durability and High Availability +## Multiorch: NVME performance, durability and High Availability Multigres allows for the Postgres data files to be stored on the local NVME. For an OLTP system like Multigres, a local NVME has substantial advantages over a mounted drive: @@ -63,9 +63,9 @@ These advantages translate into higher performance and reduced cost. Multigres will implement a consensus protocol to ensure that transactions satisfy the required durability policy. This will be achieved using a two-phase sync to replicate the WAL to the required number of replicas in the quorum. This functionality eliminates the need to rely on a mounted (and replicated) file system like EBS to safeguard from data loss. -In case of a primary node failure, MultiOrch (Multigres Orchestrator) will promote an existing replica to primary, ensuring that it contains all the committed transactions of the previous primary. Following this, Multigres will resume serving of traffic using the new primary. Essentially, this solves the problem of durability and high availability. +In case of a primary node failure, Multiorch (Multigres Orchestrator) will promote an existing replica to primary, ensuring that it contains all the committed transactions of the previous primary. Following this, Multigres will resume serving of traffic using the new primary. Essentially, this solves the problem of durability and high availability. -The above approach aligns with the conceptual view of the MultiPooler+Postgres+Data trio as being part of the data layer. Hence, there is no need to rely on yet another (mounted) data layer underneath Postgres. +The above approach aligns with the conceptual view of the Multipooler+Postgres+Data trio as being part of the data layer. Hence, there is no need to rely on yet another (mounted) data layer underneath Postgres. It is certainly possible to run Multigres on a mounted drive. It is just not necessary. @@ -77,23 +77,23 @@ Multigres will come equipped with a variety of tools and automation to facilitat Multigres can automatically perform backups of your Postgres instances on a regular basis to a centralized location. -### New MultiPoolers +### New Multipoolers -Adding more replicas to a Postgres instance will be as trivial as launching a MultiPooler with the right command line arguments. The MultiPooler will seek the latest available backup, restore it, and point the Postgres instance to the current primary. Once the replication has caught up, it will open itself up to serve read traffic. +Adding more replicas to a Postgres instance will be as trivial as launching a Multipooler with the right command line arguments. The Multipooler will seek the latest available backup, restore it, and point the Postgres instance to the current primary. Once the replication has caught up, it will open itself up to serve read traffic. -MultiPoolers can be of different types: They can be quorum participants, in which case they will follow the two-phase sync protocol during replication. If not, they will just be "observers", to just serve additional read traffic. +Multipoolers can be of different types: They can be quorum participants, in which case they will follow the two-phase sync protocol during replication. If not, they will just be "observers", to just serve additional read traffic. -Bringing up a MultiPooler as a quorum participant will automatically make it join the quorum after it has fully caught up on replication. +Bringing up a Multipooler as a quorum participant will automatically make it join the quorum after it has fully caught up on replication. -MultiPoolers will have configurable user-defined tags that will allow MultiGateways to split traffic based on differing workloads. For example, you may tag a group of MultiPoolers as "olap". Workloads that would like to perform analytics queries would specify "dbname@olap" as the database to connect to. This will inform the MultiGateways to redirect these reads to only MultiPoolers that export the "olap" tag. +Multipoolers will have configurable user-defined tags that will allow Multigateways to split traffic based on differing workloads. For example, you may tag a group of Multipoolers as "olap". Workloads that would like to perform analytics queries would specify "dbname@olap" as the database to connect to. This will inform the Multigateways to redirect these reads to only Multipoolers that export the "olap" tag. ### Replication -Beyond managing the consensus protocol for MultiPoolers in the quorum, MultiOrch will also monitor all MultiPoolers and ensure that they are replicating from their respective primaries. If a connection is lost for any reason, MultiOrch will restore it. +Beyond managing the consensus protocol for Multipoolers in the quorum, Multiorch will also monitor all Multipoolers and ensure that they are replicating from their respective primaries. If a connection is lost for any reason, Multiorch will restore it. ### Cross-zone clusters -Multigres can be deployed across a large number of nodes distributed across the world. This is architecturally achieved by a star configuration in the topology. There will be a global topology server (etcd). It will contain information that changes infrequently, like sharding info, etc. This information will be propagated into cell-specific topology servers (local etcds), one for each cell. MultiGateways and MultiPoolers will be deployed in a cell, and they'll use the local topology to serve traffic for that cell. In case of a network partition, a cell will be capable of continuing to serve traffic for as long as the replication lag is tolerable. +Multigres can be deployed across a large number of nodes distributed across the world. This is architecturally achieved by a star configuration in the topology. There will be a global topology server (etcd). It will contain information that changes infrequently, like sharding info, etc. This information will be propagated into cell-specific topology servers (local etcds), one for each cell. Multigateways and Multipoolers will be deployed in a cell, and they'll use the local topology to serve traffic for that cell. In case of a network partition, a cell will be capable of continuing to serve traffic for as long as the replication lag is tolerable. Of course, there can exist only one Primary per shard. Any cell that does not host the primary database is meant to serve read-only traffic that is replicated from the primary. @@ -105,7 +105,7 @@ Multigres will be cloud-native. This means that it can run in a cloud framework - Components can be migrated to different nodes. - Components can use mounted persistent storage, and will automatically reattach if moved. - New components can be launched to increase capacity. They will initialize themselves correctly, and join the system to serve traffic. Conversely, components can be removed in order to scale down. -- Specific to databases: Primary failures and restarts will be handled automatically by a watchdog process (MultiOrch) that can perform a failover to an up-to-date replica. +- Specific to databases: Primary failures and restarts will be handled automatically by a watchdog process (Multiorch) that can perform a failover to an up-to-date replica. - Scale to zero: You can shut down all components. This will result in just the metadata and backups being preserved, with no active components to serve any traffic. Adding the serving components back to the system will bootstrap the cluster to an operational state. Multigres will come with a Kubernetes Operator that will translate components described using Multigres terminology like cells, shards and replicas into corresponding Kubernetes components. @@ -124,7 +124,7 @@ If the materialization expression is non-lossy (reversible), you can atomically Materializer streams operate orthogonally to each other. For example, resharding uses Materializer, but a simultaneous table materialization will correctly migrate to use the new shards after resharding. -Materializer works in conjunction with MultiGateway routing rules that allow you to smoothly and safely transition traffic from source to target. +Materializer works in conjunction with Multigateway routing rules that allow you to smoothly and safely transition traffic from source to target. ## Migrations @@ -132,13 +132,13 @@ Materializer works in conjunction with MultiGateway routing rules that allow you MoveTables will be a workflow built using Materializer. This will allow you to migrate a group of tables from any source to any target. This can be used to split a database into smaller parts, or merge two databases into one. Let us assume that you want to migrate table `t` from database `a` to database `b`. -- Initially, the MultiGateways will have a rule to redirect traffic intended for `a.t` and `b.t` to `a.t`. MoveTables will setup these routing rules automatically before starting Materializer. +- Initially, the Multigateways will have a rule to redirect traffic intended for `a.t` and `b.t` to `a.t`. MoveTables will setup these routing rules automatically before starting Materializer. - Once this rule is setup, you can start refactoring your application to write to `b.t` instead of `a.t`. Writing to any of these tables will get redirected to `a.t`. -- Once the data is verified to be correct, we can switch the MultiGateway routing rules to send traffic to `b.t` instead. MoveTables will have a subcommand to do this safely. If the application has not finished refactoring all the code, it's ok, because all traffic will flow to `b.t`. +- Once the data is verified to be correct, we can switch the Multigateway routing rules to send traffic to `b.t` instead. MoveTables will have a subcommand to do this safely. If the application has not finished refactoring all the code, it's ok, because all traffic will flow to `b.t`. - At this time, Materializer will reverse the replication to keep `a.t` up-to-date. If any problem is detected after the cutover, you can fall back to `a.t`. This back and forth can be repeated as often as necessary. - After we are certain that all problems are resolved, and we have verified that the application refactor is complete, we can use the MoveTables clean up command to drop the reverse replication, routing rules, and source table `a.t`. -Of course, this workflow would require MultiGateways to have access to both `a` and `b`. +Of course, this workflow would require Multigateways to have access to both `a` and `b`. ### Migrate across Postgres versions @@ -189,7 +189,7 @@ As your database grows into multiple shards, you can run individual MStreams for ## Observability -Apart from exporting real-time metrics, Multigres will also have an extensive toolset to facilitate troubleshooting when the system exhibits unexpected behavior. These will be exported by MultiGateway and MultiPooler: +Apart from exporting real-time metrics, Multigres will also have an extensive toolset to facilitate troubleshooting when the system exhibits unexpected behavior. These will be exported by Multigateway and Multipooler: - Standard metrics like QPS, latencies, and error rates. - Per-table metrics. @@ -217,6 +217,6 @@ If any of these features are already available in Postgres, Multigres will utili ## Tooling -### MultiAdmin +### Multiadmin -MultiAdmin will be a dashboard that allows you to view the various components of a live cluster, like the currently running MultiPoolers, browse to their status pages, etc. +Multiadmin will be a dashboard that allows you to view the various components of a live cluster, like the currently running Multipoolers, browse to their status pages, etc. diff --git a/content/docs/mvp.mdx b/content/docs/mvp.mdx index 8e6ddfa..11d708a 100644 --- a/content/docs/mvp.mdx +++ b/content/docs/mvp.mdx @@ -26,12 +26,12 @@ Multigres will have the following project tracks, and they will be worked on in ## Proxy -- MultiPooler: Connection pooling -- MultiGateway: Postgres and PostgREST protocols, discovery of MultiPoolers, route traffic to primary or replica MultiPoolers, load balance replica traffic +- Multipooler: Connection pooling +- Multigateway: Postgres and PostgREST protocols, discovery of Multipoolers, route traffic to primary or replica Multipoolers, load balance replica traffic -The MVP must be able to scale to support tens of thousands of connections per MultiGateway. +The MVP must be able to scale to support tens of thousands of connections per Multigateway. -Each pool of MultiGateways should be able to support up to ten thousand databases. +Each pool of Multigateways should be able to support up to ten thousand databases. ## Cluster management @@ -39,7 +39,7 @@ The purpose of cluster management is to minimize human intervention by automatin - Initialize a new database - Automated backups of databases and WALs -- Add (and remove) replicas, will use backups and WALs to make them catch up to the cluster, and publish to MultiGateway about readiness to serve traffic +- Add (and remove) replicas, will use backups and WALs to make them catch up to the cluster, and publish to Multigateway about readiness to serve traffic - Deactivate a database (scale to zero) and bring up a previously deactivated database - Kubernetes Operator @@ -55,17 +55,17 @@ The existing Postgres primitives are insufficient to build a robust consensus pr ### Multigres -Multigres will build the coordination part of the consensus protocol using a brand new MultiOrch. This will not be ported from Vitess, because the MultiOrch from Vitess has a large amount of legacy code that was inherited from the MySQL Orchestrator. +Multigres will build the coordination part of the consensus protocol using a brand new Multiorch. This will not be ported from Vitess, because the Multiorch from Vitess has a large amount of legacy code that was inherited from the MySQL Orchestrator. -MultiOrch will operate as a coordinated cluster across failure zones to ensure that at least one of them can perform a successful failover if there is a network partition. +Multiorch will operate as a coordinated cluster across failure zones to ensure that at least one of them can perform a successful failover if there is a network partition. -Functionally, MultiOrch will be the same as its Vitess counterpart: +Functionally, Multiorch will be the same as its Vitess counterpart: - Elect a primary if none exist - Perform smooth primary changes if requested - Detect failures and failover as needed - Rewire replicas and observers if they lose their connection to the primary, or if their connection to the primary needs to be updated -- Cooperate with other MultiOrchs to ensure that they don't step on each others' actions. +- Cooperate with other Multiorchs to ensure that they don't step on each others' actions. - Honor a variety of durability policies for each cluster. ## Materializer diff --git a/package.json b/package.json index c5274d0..e360e96 100644 --- a/package.json +++ b/package.json @@ -9,6 +9,7 @@ "start": "vite preview", "preview": "vite preview", "types:check": "fumadocs-mdx && tsc --noEmit", + "lint:naming": "./tools/naming_linter.sh", "postinstall": "fumadocs-mdx" }, "dependencies": { diff --git a/public/img/site/arch-cluster.svg b/public/img/site/arch-cluster.svg index 81bb9e4..2ec362a 100644 --- a/public/img/site/arch-cluster.svg +++ b/public/img/site/arch-cluster.svg @@ -1,4 +1,4 @@ AppMultiGatewaydb1@primarydb1db1db1@replicaMultiOrchAppMultiGatewaydb1@primarydb1db1@replicaMultiOrchdb1AppMultiGatewaydb1db1@replicadb1MultiOrchHAHAHATopo Cell2Topo Cell1Topo Cell3Global TopoOnly oneprimaryCell1Cell2Cell3Multigatewayscan go cross-Cellto write to primaryRead-only trafficserved locallyMultiOrchs coordinatewith each other for HACell specifictopoGlobal Topois deployedcross-cellBackupRestoreAutomated backupsand restores to bringup new replicas as needed.Figure 4: Cluster management + @font-face { font-family: Excalifont; src: url(data:font/woff2;base64,d09GMgABAAAAABvwAA4AAAAAMFAAABuaAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGiIbihYcgXYGYACBHBEICslotlILXAABNgIkA4E0BCAFgxgHIBtpJSMDdWnSqk/2lwc8GB6NXgAWvprWrga5Dv2VK3BmpCN/uOEnI4QUgzwtRxqe5vbv3e3ulgG9pEakRG2syVElGY7R2liYlFFB6I/E5EeJjf5AvxVY2PDw7Xz9Es6gi5M8GQzW3cTmONSMGmv31VDXFSTRKjGQ0slQAP9EstvfgCJOJhBEEXavznr7XZe0dITZ+0QVdQiB3171ueildqadkQwJG0LLSXYPgGX5/3Jq0lVz/TMjMBQsyy6gnaQAbGi7J+++PfZwT67OVWAOSbZMcV5rKgBLmoWr/V71BUiyBnSJsGHJQsWYNxvcxwm/fwFiBUQuQn0fRUC1f6riqkRklamrla8Vqsa4WolbqGy/85MKHkI4mKto7k1rAggAOlAEOnRPQuUO8iQQwfZb+FIhdX18GrC72q21wO62ltUAu13UVA/skAAAJKTaU2atB2QqBHuukRICcAhCX4NklWEj9G8r4LCxmLTHwJj65K3KnR//4zWf3Bq8LXbMqOe1PoLtqaNC7FQhg8z9981BWVwDor/p8rT0LKetjnL7vQC4/hIxrql+/pGlOvrU2S5x0uf34Nc3xhhUpLaFaWvKJ8DgO+Xlc0MiCBwFDR0DBxcPn4CIDVsOnEhIybhy4956tSOUuMhd11QQG5UgHCWszIISwb1CEiEsVnhEXUJbHEeg4+NgEHRimSAIaf2zAQHlKCLbkf8vJPRSAhnl7hQAWsjR0xAOZA45Vr8bRSzMRGSC1bSxRCuBDtdLYACCRiAnpYoEh9BF8gsPKQrrcgQzfTwSAsEISCQoiCH0Fx8pgcvsqooiwH+tpfV5F24PfnWSDmE8S0QA6SVM6kHZ46AYl3PwSbTF0HQ8fsUIOSojEihw6WC7GMEhCXu3O1pMxYeQQqoknBB6HJMXZ6sRQRyeX9tGGuyGIcfyyAIAxCmXAC7g731L+IU21E5DIhgm1p5bPgNsUQ22iAPYfhb30aSLkcuAAsDnCIqSdLYUZO8h0+A63gKF0TBKkCRFmioWrdpPAsWLn85GRW9XpIb1q5oaf/nFf/z5yDNPH/7joYMH9oMgwHKkAHj1SI77CIDeAGAOgEQ27A7n+khPdC/80RBpcUSCoxYeQdUEVq5PVtp0fkcxj4IzYXtsQsr0UsfZGUkBHS6ioAimOz8VydDYOcQr4jW2Th6sIFVunCHJ5O9MFToLDNZOaxGf0vCSRniG32MeOXgienPUHJMCDYfZKJ5Ee3R26H4vlw3sz40LQMDkA15G5f9RN/I+TETPlE2qmaarVOPzIVS5zDn1+sG6n4iy0bhDp+wcPsYt/bz7IDp6dRDsoe2KHpCu60Xd1E2IHskbx65/vnS/hkk22uV+fSXkbfxwz889yDqXvhp/FDkBQwGaY2Izzl4pQNC8N67dGdPVG6onjX2c1fC70gtmHkk1TZMEa5pmrD/8lEsEOF/b2B7O6veTcjzyHz7sH/R67gfbQJxeXuGn5X5d7GfMT0QqlSDqunLrkUrBzqmKWVlY4ntse2uWnojmxMyQeGOSk2U2dK6I1iLCc9hCVYvmDh+raV9kkWBL9MRJWPTgLEDBK3GeVGYsEg3VITvRc/6JFuPN7ALVOOHeVR06PKQRhqkGVNJ1oGIBcla38nju9HMrp3dTSnGk3XsxrS2CLV7PtYewCCKS0cvf0/kil4RzZUngY8x5bYT0OttnBV7CwKRX/+FHJ8N3rRlCFY0SR6nISy3ups+VkaKpEpSt22BGvP49IGpXRa0RKSuhYnuxSABSoCdPgL4A8N3drdtlWbPB7gNFLpGZVsW2WKflEgyWPY4ROoZhYNaB5gjI57heLgH9iZPWpNWi1TNu0yUP5h6QUYAcBCRpdshQSxGe+bbYzckgKMOa1gpQLJqmSRLelRbNdmP/bUqzGQZehnScvWYrW17GOG29b10eKFbJu2AKUuRjAdmXTqPj0Ptl/3JuI5i5p4wXIDh6KYhY576c/qSIDi3qKk0llhjfDEc9YUUqilS6WwKiOk2Aoe3qPTDMyBiZliJ8i3kexmA4JYpX/IF3G5f22Oxjc2uCEONTkUtApKKIBQ0FgpIjwoi/ZDSA/HYR14E8+KPFYAqFGphBZxCje2RWSDdqou7kI+tddi23Rmvn4r60dfrOXS0a2lP7if4FDAf+mSWbzUufCoKuaUXpajxxHMyIGdYT/HDUgDZ6cOGWgkC2KJFehuwgik+VYdTdoKpqdWlVr1G5xruywcuBlib9eSCvdkgYCN+r9zfTmutGcmGgLXeKLbyQ0DlvueYBr5RrzfNV4H9qkmR9lQSBrAJZkkDwNjwYpy7l1Pp98qGBQSteHJJ9gTI7pdkgV8IHnUGI47bEBi43BNaM7uZVtUvRwWVuY/axPy9l5JeY3b8gyFnn5bmYMpV99WGi6HNHRcZEGNWho9LZ4++v+/OxjeDgSoDD5HKRPRWvtBg1KGHe7D9tJyf3gFw6OQ22PVOgBFWq01fT+H6yp83uxx9pJUCG60aZM2Qfd0LeE7KQh7lcQV53W7S6o4Sf1Qm+O4n4E0YZ2e87XCq5+hSioQfOBMe+Wi6XkXtjIol6CagQ7VKMyIDKteE3JnajTrCfetSvlPw6t560KDqOhizP7O0sl3VMOiTFGAyFAsBZEjxMPsd+2KEEoTgbBduU3ETTwQbPP9X0OsIsOwaU4xHwjV3H1ko0owy2I5UgZ6JQe3x8e1guNdetv/TeHu+cFO7Iyg63QrbVKYJjOXzbEw1ns/dreGHph/wNN2GUj4ev4vMml0nHZMwb+Ovjuw0YFsfEnm3ke6+PXWfp9GE76ZdFD8A2SZeoMSx+7BC1MvYvxL7W4jYn5hZZ2KZIEChuXrj0peqJ1gm9Vl2iIeNDjR9if3NdZDxPdA594Pd97AMJEL+WuzFhbu6o/RQhzU1NwV4YD9mp3NUU302jA+90JMDFmscN/HPLS2vpuVRyrqTOmi0j6xix4SwuovS5El6swdRNHGyonHt6YiuK2OGgq+oRbXbzvVuzQ3pCG0vMRhmLcgm8uOqQJAU2WXkZM/rc8r09nGU3RgIEZCVAzDnotH1J6Pbfj5Q0O3JXmyHE/LJ9Dmn6gNGQKXeqcPZSEBmxQ5cRnhAgBCDqbDLtJQhIz0kdiBGy7/35djHeWa50PNGgvbFjHqMCxDcC2U5FX1wD8zkSYJfiZWXBoj22auVRsPWMsizLMBDBITIIf1PuFGHyqr85GxA6dviDmp9I0lDCxypbBpbCfIRr8Ee0bUpcBTNYPkyzJOrlFSxqJc7C7WWm6cdWCyH2Z6qi2/Ckg/Uv5zOyluJJZjxjpTpECgXyxHZsIW9EdbXK6wZ/oBuwPq2me4Xv9/pcg7NA1HqjssqPWHTItoQIk8LADeb6nhd8v96RGCi7kFWFd0OEbXzI23x7eCZfVuOdzowpm9oyuZ316nXsi2ST5KwGDXOVDwRykQGlz0pqKx2iJlG8W1BgQIWbLUHsmGoQ1RFg9xN5ohf/wg0ZlbLiZRej5HOixunBgOpul85mtdM3pCw0RJ3zgezsvb9L65GWWqCX85cR+ieyFQMa2u/yyNiwqlTMDrFVgAjIhX2RSnWO+zi+Q/oz0pJWMljIl3Jl9PtS9ulAxpdoe2cXwdGC8DhDXxz/gbtzTd+d3s/4By6m4z92D10/d393wgkYC9AkhUXi/ByoB32Jy3pJbwQZz+Rm17uqEmrawWxwItvSVXr3kEcj5z1CTVdJEpASWaVCuod+zo3OYlE/XScBb/SFbQOV8EU/mQWRuZP3VoXVNnW/odjxMBKQCGBIXMWx1RL9dO9c1Z2lJxL7+Fz6vvXJJ8vQWNY0kCq153piJzuaBlLzI4aqNqRDfZi7X87TsADNJlEVs5Bkg/hIHfMZCVYrjNe8q7bqLtUjlNCtSnOuv5MdA+H23Cd68iMjvX18PAkJaM/74U6CsmCS6atddig42VXudMWZpp9KGQ/55TZmqp9bA6tbpWF0d7tWGYkMGypv1vXMgfSiYjEL9lUa7gtWV+XDssLPqblgFfpGbew4fpiR7g5oNXzQzTiHRhnHwusSS2uz16xf79fHtOXQSejZ64mnwjOZ/9/KBu9u5kMWvRGrsO1SLlhYY0oPIZ6IlOhn/aeqbnWrg+YPrzpZ2iSfcHK8TiWOPGh7e0jXS6IX+zOpyDSFB1X4xcvts5aWTtAeks62coqGdtOkl2kmLa0GaauLOnhu5jX47EWeDL+cP4TRRqh9f8Z838lr1vI7wj56eMh1vJ4pzb1Li/LIZFmti57AwYwcB3HewUkgmVptpaulabmsGycHsShekMn/TqUfLqPfuj9Zy2cnG6mvoAhJLBL+Nq1BJ1xt3xpfiviT/cStwh27is9kj5fP7xUWunb/pAUrFPO31UmFcbC95K5LXxKtoOAMsFm8R1ALh52QDFcarqxYpfVWLmwkN+/48t2CKM/UwdSS96V9GDXIt5f4m0gmJdHQc6Z2ElhFXvc0U3B0mv4LZE337k6wZsVH9aq7z+137tv6c2+eDAqhAgaIU9SqwG8VPkXW8NEMceh/Jx+ce1OWPaco4huPZ2PP1SGt9VjPulwn3l2Wf303qQ9jn1/dq+eXMOIRazLwgupIxRlVwvFiVIFHZ3QWd2RJbyfzTba+PxWExPy5y0QU6VKWh+2soFtr7WPlNxzqjWixbeyxKO/xl5GFD/rGX/BN9F30HGrVN5XhITqb4mGa9ZGu9VZLFVmZodHZgZUy/6sBU7dEdE9abfTeHUn835u7c+wIABdMK83rPLDy1qmV/qpvo+PzsZ0senp/SXcjAiFk46jPJKkR29noKi7Ak7hO0tQrgpAv5PxSW9P64/vZ24cvI2xklYuLcLlSiQv9wCxyxwbb/Mfzw9mMhyWEEuraEeZiJ/9+j3h7p/0slxOUIxS4wHBtvkoI7v2uSeAvENd1BHLXPHHcMrqMJn0TR284VqxR5bjWgxl3u22wt+MwUH92n+V2drz1VWR8olJZ98C532LAf/S+xjJM1OBYCI5TfOi0yWjWPs/gnHq+d6lj74w0iUmYxuulnXFI+yme2TC/jzGhZXBd31ILlMiq/I7Zdn5/DAV2T6xcdnrrWwGeeq73t+RY5Y5Zo8B2M04+ajLRLzhQ16XDNdpO4UY+jX4b9/+mtHQ/+4CMZ744PfNN885X27x0mnf8PNgBZ1j6+d8Cooolc8IhRIrtNjIRbs+ZpQpIgwfv+gYkcEwYOY236ee9+GvcIo5pvHqi1NcbZHq/k2hu+mZbtgINiFHFa3FCh6kkzZb4X36MEFJWtqOnmcM0dBXQk+pLnQWXqCiX/F/PWY0XFoD8o46DZn8roz2HZ3B+XZuGaxea8tRObBdODPebkLTNX1m0MZiZwZ6+oNftqdxfwNaU89tbDaiUstmWvSnEgV+KzoqdXID0pfieTbGNXirQN+eGvY9uotCMyHWwFkYsdrvwVUz6NkFVbm9MjtqholGMIy1sEnJbontbP891zk9JyI92lRoOG8CLJ3SVaSvyL3CoeY+fvdHlbEg0B6rrHfoAmoKvQXlMfXq7bVvy/Dgb0MzeFc/H8+mnPsTiP+6VxLakEOLRIZbNXtGszPArZwe/2p9mXsL4Q1+yGunY+Ft0QimlkFdIQeocZVqCZjvN1u/xvUJmw9gSiQIt5BB30vHpvxL2Rw+AdPeikQmOY4LKvdMhFzTXTkvQFYfUpVTUtFQbj0Uky/EG7V0+dXciQjR9936pR88BO21xPsmoStVygpYL6k3SmOAzoIBUgqnBSbnTdxbo27ksnehNQ9N6teJ5VE6ViymW7PYO9Gd0UMwKtNAUg82U/6an8sm46q/G6Eq5oAOrVNqY29jSvKgsH1o2TEGGUd4e9hvbWiuZSTFInKAWMr7ikmME4N0uhzmoUeSTW2WWB5faCg+PQBTJnGEPk5gUnb17Eq9pUAx+MV64/WuseTLkEK9ooxeR0QQId3S+VqQrqG/Mkqqn+YRBCivD3hyxU6oH30h+Rq/4FwoWrGvfmRgnSyULtHkaXt8Pt2nEZUPneWS2XBH1P2o95JyZux7PElqEgGTt2cneo/uSooJgoIOoCd4uJGGGcBCe/L4CdoLrEmWao7G4rcMD5gvn92ULHXCN1lsFvclrZbZxUmN5foJXinNsFtNF90fReJvI7w977QVlZmJ3u52vxaUG7juY0Z/gKdganeDis6eiff7wSzAbki8H3bxbmW5ujNe/50nOfV4vGQ0RiP/6zNipOOQzx+OmZ6Cay5sIy6JT6kl7ESwuSCzmCV6ih4uozeTjiOFbqJXyWY3p6mck96KAk+VxmFlmxhbIcrzSDUHXHVhHht497PSnjcVgC/CsJVFmQ6R2IxdCcfl8jO2uKwMDtpqAMpiI8Ug/ezPzfM1adhKc2+A01SETsCIc3xe7r08V5REqrGwxusPCxixUIxyPJSlxvcSZDDeyLTst9L10Hqa6rcIeEpngLzKVsmkXajNP+i37HDiN31bbuKyqvpaULvCAHrqvPUulPUZWEsGp2hTyW17ualGiSJprs4qZRPoAMGXxAf0ZeeBBodpV05AWk8+5CmeXGdE2IjCWFNCXNWQhVdkBKq3U4B7rTcmDqXPwNHvBU4ag+iZnPdXhOcZa6sBaiZrny+87GTc5e5ulIZZl6+MD/bIz2CMzfxpJ4xhePdzmKU+i/Kj/J/1XTg7IYwzbJb8oYd94j+vruzqEBa73VSOS8gvRipFhdPR16OjaBz0TboHfIjHhe176f0iAgzWYNZCwacsH+7h+P48de4cnRxKUpIUzE+njsW5RKIG2E7ivsDSRy56ORHz1PMV+fSAwK+g1cucEuarIJ9PBXhXr9CiI4Nc9ta2vZxlMZ0YC91hOSkSTmZ6RawU7EQMlrSwAuL6z8vLqqOR4mxclww3J0S6k5GxUKAio/edn5v7i+IW8BSM3NFaFlH9riVmYnESKcdfKch62Yo2v1VRHJPX/gNUNAv6v/hU7wQC15+3SDveZAq5m/sz92YJ5Mmd2d9gQrBHaJi+3CRxq7LOakVn7Fh6a5GK1fgP/PSs6K9+RClt8w4KsjESycfS8aTZv8uL6KCV4ie01gh0uItsWMkYOcZhHI24mAP7n6YNz6jarbBOLRNxvtb2TUhSMdVASpnNJycjqaX7hS8OM1KCsysnEYAPAaL40rPULnfnTixq9VBsebjpU/g3nhlwcwy9wJrdsRfcvkQP72ZLkXMVsFZduvul5H0xgssslpVXE0tz/1r0m0FTJoF+hiTqlACUxfAJ8kTgumosImR/deVhITE9hPwRTf2B280gvo4kifY4lJUAolBj5zlnbHbI8YDBX1wC6Tt165yim7uso4nHMKWtVnf4zZe0wlJPJWWrz2x7AcLQnzEQWYef4wOXcn4K6GRe9yFIfiPi4V4P99tdLdCvVvnf30Tl4BYrr355uMp9ZCB6PRBbmmBxPH70wV8eMGUNaXItKpR5fQYSMI/l+Vzx1I0s/ozVuXHI74RiE1kI9dbXvF3IMScKrFLkyuMsIFvBEI//AOTYMgkr7yQ6h/eHZLnRwRuZhqIHK8GJ8Taw1QVQnPr6bMXMEzAR7CuXbkJdhQnpPbkHQlg+3s9y/es0PbuRFpo5fO74mdpicDTN/dNzsQm89nTZVP1/uNRspofilats4W5O2BsQ/6UNuRmfSGhE/MO0EFKwAQwjVlltewVXnuRwziqQ4WaIODkrheSc27NR+52yirXXEElAKW/NcfKZayQyGmsHLsowZsjGVZHd1d82gkyGdm4yegnYPxZXgJsmj6gfTB1JVtUfVMbXbhujYzuiRAP3R6Lo5Dq/LLL7iOLcMoSlET1PvqIDSNG9P53PfcNJ6tGRXJQ1S654P1oAtVotlLON7jquBup8Myu1gSh5FO+/5zzwdg+hrdvI1fqLPfVofJR1LCdxKoiBLJER1WGnvxmnrfoiwF5iM+rRjije0ONb2OcyZoEvWx9TysQEpXRQgZcDdO0R7V+Z2FPAxit0qI59+wDBnGZWnWA6sQsbK0PC94xcimagJFSJaoNbxLitC/B857hlQ0Rx+6Qtq8dqWEJNupw7SF4/a43X38uSpGCJBJ/yGtC1GQcpiLPn5ieYPVy8tnnw2lD6RFRwz/RbBaZDMnQv4cyFXMfqFgjbLhW/M0Jy+RnEcKL7xnyaUl0UfDqn4qlK4x9sVtZQr/MYG1Bf2HgYLiib17AFRvp4VQk06bve5LND3pXlIvUjXWjXbQGrmHxu+8HeyqnBWcIK5QTwXjNFxIky97P68MpsUJGpWu7N4z+CSoIADPTZQR0tn4N5veFK/BQZU7I3IFWE+KX8Wu52hOH4XW+4Q6xby+1ECJRXuZkp8lC4hpEiG4cVHbjb4h+Cc+frnkHxb8/FWkeMCII0EyO9r4N8a25qlS7/a9vL2R6lN5o6tdldyL91NxTcMiEnD8SzivxB1mzZNl78y+G/1Pk6pROOrxglwnomKaRdjxivXL54REA63ILgLg6OUcjLnEy2ctHzHOXpsrYcmM05tLb/lgpo0kjhcyXU85122xS91MPR/uD19okjVfczQEBgrjYnS/zEuaLVPCasE/zSK1yok9Omhq49E9o5e04dKbEsu2+fWqouoRtF8N87kfAOufI4WMj0Nf83c+N/VzI+hSRUkbcSq1Nk2DtKEmVENgU+RMIXFpj/qqH9wGCVKZkcFmpMpbxWNgQ0XBYol7tJWzeYOyd/2HYjfih/ZvCBVVjHnXwpxmFHftCv0TCYNLWG0UJ9RhSvHdr/nmhfrvjc6/JmAfNwzhmefhRev5IB/T5woCUVpmXGLiT9Z3EWcJXJg4TxzyBa4G9RdO69yq4znYp+4pa6esZ5kvYBqZgkEpnlHbkyj9YLv/3bKosTl/4iuu4waJmw80QNr3b22c23jjYSc4ebPv+p4B64D3dbzpWY89VnIXwO85O7/hl7ZAfDQX3zZRGtiASviNZmG3gewHW/30IJlb+16NGtq0edZpIek0G/XBGTEg+8RZYyrMfn0EfZaQs28uhjoYDcAcDPghQti4GEg9B0QKgS2TEAWMlCjkcDXHgCQd4CGNAORtcC96VOfRAKlz4BvCnD9B2LRbAARFXChBEF5C8TygTtbYJ+JqXeUQCkYBNUrjk0AvGocBFoPIjBBqCzgyxYEZwvw4wzcuAOIyOPtGICBnFzPK7jAP+3j4NN153MK7L1chUvIt8SJKmhMyIGChRJb1Rp1hPh+cEQw9TuiPCxxJJErdsREkSM+em4AdNqUKFKrSrkZ6jXxkqJMhWa1ilhlKGPVqEpXXcyPN19PCWfQF7azqOwxR0kA+it0C4n/3MHcyT0QtyRbuFYqg0ThVi1HbWtRoxSLdg1WGXGVd0I3A3RXij9fHwNDLNb2FNtiqXFhkVbeI1TvYW23mT3XuIVlipRhy6haKW8ohDb1GQYA); }AppMultigatewaydb1@primarydb1db1db1@replicaMultiorchAppMultigatewaydb1@primarydb1db1@replicaMultiorchdb1AppMultigatewaydb1db1@replicadb1MultiorchHAHAHATopo Cell2Topo Cell1Topo Cell3Global TopoOnly oneprimaryCell1Cell2Cell3Multigatewayscan go cross-Cellto write to primaryRead-only trafficserved locallyMultiorchs coordinatewith each other for HACell specifictopoGlobal Topois deployedcross-cellBackupRestoreAutomated backupsand restores to bringup new replicas as needed.Figure 4: Cluster management diff --git a/public/img/site/arch-combined.svg b/public/img/site/arch-combined.svg index 86bac24..badbb54 100644 --- a/public/img/site/arch-combined.svg +++ b/public/img/site/arch-combined.svg @@ -1,4 +1,4 @@ MultiGatewayMultiOrchMultiOrchMultiOrchTopo Cell2Topo Cell1Topo Cell3Global TopoCell1Cell2Cell3Figure 5: Multi-shard and Multi-cell clusterMultiGatewayMultiGatewaydefault:0-infMultiOrchMultiOrchMultiOrchtg1:0-8MultiOrchMultiOrchMultiOrchtg1:8-inf \ No newline at end of file + @font-face { font-family: Excalifont; src: url(data:font/woff2;base64,d09GMgABAAAAABeMAA4AAAAAKWgAABc0AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGhwbiDgcghQGYACBNBEICr1YrU4LUAABNgIkA4EcBCAFgxgHIBsfICMDwcYBCFB8LrK/SohySHlWPyC6xIiY2qpr5hNPJD1/J1S2VSByKnfnSsPzc+v9/7f9NauENdUyQlw0PaIVRoUj2kCsIqwizLwozsJIbPQCM++Mgue/9rrz7v4YHx2jE1rXpXXLYAwOoQTb/wD+/ffT+eW87ZJyAag6qqhCClzRXXVFP26lVhoZEh7b4aUPxDuxNX4/fbUfZJkcwphyyUDN2Ukx4wv0U5v2cGWu781AqO0usRVNVkwjK6d8Of7DvbmmVyBiFSDe9m9JkxVxYL78//u5uodY01DESmQJTif1d+707mH2NsTtMzQ0kyoWmksS3fCKRxqhQCNCKtRC5dCslM46XGXlTMpb37iFFLb1xLEXzQ8gAJAhwto1kQxESSAE5t4DaGCmcys7BEcfj9cEZ48nVwTXB8+3BDBA9igDoKuTx1t4kZIAQOA2B+6F4FPx4Ozz/PiQSe6gYcMcY89dcHMsultP/jWteCQqMXbBOvts0ZQ0NwOG8meQ2NXHc32pm/i7DNsCY/vqYTc9v9WmiKshy5vlxe6eOCBgBEoBdUeAekT9QVhgCBwiEioXNHRMLGw8fEIiYlKyNKGACrYpvjXDCyBKSOFysmBhIQoxQ6TdIsEEYUKPIGGkoC9TyC0CFksAAGLaIKliOFlARgjXKBJSGkdQUDevSD0LsgqgmAcI4XQKxSVDhComIl+AvjDBhmGjhjhfLGuII6g3KBmeDZFlgIBkyeuLswOSu8djBkq7GotVcdCwYxPC2mIaNS/kofSQypIhFOQUu51FRSNkOCTHZDigHCFySJDyZggbYjRUQqs4XgSEdjLgQH1xcnBLqJYQNij5S3MAkM1SbyKHtotjklKdsPBZkAwAxNBooF1BPkP3kFkN2/NrBkm0tMZ/gJ3lqcYxsNGJ/cj4SsotnEjG2jiQJcYmriAZImamD1/BQqlF0DOLkyBFmUpODZq09A6Ah2mAsYnk21SrfRMZG3XNFcMuuWjICYP+8Iu9dttlpx22B6WXeQfIIO5A4kVhZkS/ENKrBBIGvzekGyMvKvhWMVTUBaaiBUHuDeIq4/pnpFSHcV1ZLFucvVDsmRDMUnFDo6ierOQ0vUCk1PNdvVxCNdkxCdYgNyLHjW2WEZnGfHYq0mfhJSF4ht8hD23syd5+ctZpnlw3N5XRy/fptfZUnfN0JjHw3hFHkUMfb5xvYTc83OtDcHT8UYIE7SQzZDFJvvuRAwqmGIjutPv/dM547yvmqfqGCY9KlUmxWCQY5rLgFIs3in7MpM16l/X5OXyEFXnWW5vuvDwIlmu1ZQ8IvxEF3dRNMA9D42Orny7t+hhno1Me1BcmvNXv7djQg0l02g9HH2SOgSuBs07THZ4s5SBw3q5HtkpSLRaLRRb5OPHxm9oI9h5QO6ZJg6WocJ4OP2ZiCc4/G28J98m7EUZD/8GHgez12+8tD6Lk9BV+Uh7U5WbK2rMZOnNQS3qZBmthRMb5YTJ619vyejE42nciJmESUxJE+pveZB+7xSILqau6LCdbhGF40+e/7/lsPKrLSjPwrQnexpwylIBSd0h2CGf37Q5x+GSwbeRPWNhfiOzsyg3O9FOaMliKZg8y0qLWludsxCeyIyz6e4L7msUVju9vnddvxywnJwLZqK6YXTrcvANXjszr3FWGgZGPhYp8Y4FKFBxJSynIAn897XbJ3k+Hj8KFaAO3gWqCat/VXdY+JAQnqQZU0nWgQg6CowvBVKpMi8kvCmizglRZorDCuO7ueNIMvabptfrGYKNrB9dq632wNjFG5NGE4BvkWeiuRvepFtU8l7Y3Ls3yfYfi1ojgAcVyCaiDOVOQKxFccdQk4ndMPO5n5mM4qgN5YDwNxpB/BjbrtDT6i8wKrU/bDbd2i1Qf+LVMQp6fiwbK29Nb98+Ma42tx/pnsNbyz0zzfdk+pYMg1q+o9SiPbBuZMEcZ4X7Rglb78D85NF5epEEw9gu5VEbyVj3oJhYSIuxTCy0LzLEh3h2og1PCV7gaTj91ghh1FDbwakmhcPYhq6s9hjZe5Q6yj/6sMjF+gdz+HYJMqmz/Ukh4mP3w/tbUQLijUnYDSxy1Rmzw6NurdFYaBwdnJDhMbcFYY3kJqKSXkDf4TzrxXs5s15y6AXOX8iFN016RYC5xkNZqdpNJRi2Gth1FnmX+psllHUmHuKCBK+UL8IQkD8kX2J90KEaYPW2CzdqsqC3kWYM/OyRslWCabQOuRshp9nGErbnZqz10Q68FGbshRg9PNvNukxpPM5/7W7vberktpkzzlZBvSjwIoHmrnmxtsG/XxwvT/oS/GqaUmSd8GYkluEw6kjFr4JeP2yG4hXWano+zjVfHVnkyedCJ+2XZA7BMWqd6Haa+b1W1MvoXIj9a4Y6g9k+lYbOmQaDmsr1N+8r1+5X7slRtspCLYZQfoL+hqFKeJzs3P/EHPvpAEkRWMmsVe7vF6hOCLBM5Unpp1eanMl1PcHtbbHmnjQQXn3lCyz83fel5ci5RnKXEEzuwTBURNuy5OZI8U8OLz2Dcjt0o6RMXTdOIvtVlPuiFZcjK9Wzj1uCQjFhpGtkooyqXwIvoLo0TYNEZL2WLGeyq7Te5rZEEAZ2RQHNuOFVfUbr15wFjpxuqRwcEkV90wsiSNc5Crm55cHYhmOrwQ4sETyhQElB9Nh73YwSkn0hlZL1o/i2dDQvRtqvXap5sUV3dOtQoB5FxEEpr5nPbg+F+kmC7Ft1KvsgafDEIdYJNj3WxWDQMIrCGCZQ/kykhGF/2N0wySsdF7pHzkcYNNXwU5qKB4yEf4Rr8azb3aXLR3sRhkhVVLy+gqpWE4NINUL3cqCyKHT7d5htDgnFlYImFpuc536/XFQbKOfwNaVrSDaq7EoAFebIX+SYXcuaGtOj2EBVfUDVBVlaY9HpssE/sgaFMXEnVBR/ISu/8P1yequg8W8wuEvRPTFoW5Fpvs8h5XlcqZpemHoABasOcTKW6wAOM7pBumiZN6QZ53uRq59elhGB4YueoemengqN55QnWfLl7D3dk7L89PZfyD8wno3sfDq2e2x33BAVdCRyan4q9GAL1oalwWS/pQBI8DZXrmboaRsVGNgSVrkiVbc95OLTfEYxKlcYBTam7FVo/9EcmtOeOqe5qMXitu5YFVMJ5Pz5xKrW1m8zkZjbr+w01LYdTATUALo3JLesm+3L23PXcINlT2MenybtW8ovpiS4Y1wNIXEmbImob21FBZP4XEIbFUG42Ydj+fJ7cHDgO1RWzYS6KFrHTNZ/SYLHCRRFz5ibpMRmSPZ3vylBobmPbILgl0/1GmuuHiGFjb0JBddafrMUoDVbBpP3dweJi6JZbEd2KmS9erNk66Dj+JBPprbDr4dpN9Dk0yrAhHCmsPB+84mnZI8ekaLPeRLnV8Vg6oT3+0bGYW8mGfHpt48HmhUyQX+JqgyD2ZIo10/6TsLR61ZX0gPd+FQtZHfaOF6kkkAdVbyfpekn2tP/iSojGsOfBT9HdMmhFkxGZJW4xypkg13JM1kw9akXP/XBFVQevnfrA1HqBR/0X554yOgSjvzy2P1u7Tir3G8EB2Z9zHUepK0OvaWoWecgNx9QjOMgYbxPOFgBfyCp02L0eTZIZpXAUb2kmks8kT2xz8ir6rXejaNbsrSa+hwLEmpE+zNHeYzdpcXV9yZuZFrMB/Vz3Tyh6n8qu0tfsEHMt77isD/vQu3mb+hzHMkeL27s5ee6dpwwAJ3ofZ/1LXp4bNY9E5Gb7NLWFrdKR6Jr6FCOkxGPtysQxU/GGNMl75t51wY5DKbluMZfANs9egczf/9SKg8va1QvQiWjK7S/HHB6d+QwyQIOucJo7Ceddstjg5z2zDt+w6YdPM6J9kg8kF3wu7MESQwO60b/QJEwCCTlhbcGAxfgVL9PZu8eZjsDLOvvngWULv2oXP3wt7N2y/nR3jhziQEooWGLXakJ+Ufrn10YOp0nC/z385MT7osyp+VE/e70aea1VN1Vju1ZkuzIfugRVd2J6sLSTS7pNrAJKLFybBHxhxIhxpJVxRh2IEjchbZ6jI0N2L4ll5QecmqTWXeyzovlG+4KI3hJybaXQprgtqrYgDr5tT7Tf6LvxeU96Rt+yrOQ+chax7OfSSLWR5xgk1T4zNt1tLMN7p+mNAvBCytxSwDMcQQauhxduyqePfWv7TO67Qq1JThbh0+TNv7022j42N3H5Q1dSo1y0nzA8L7iARI7DYOCJ+2/QySv74okWXWnFh9l8ezLrmYfsxyQr1p2GKaJgb7lHuWidNBuB76hfHXNAesfRkcwGjgf+GaludjEw8MQGXVgKG9Y3JKT+C0xMW87Awuxqc6EkcgZx/403/Uxnr+iRCKkfUO7BRt9RZfoH6OCIfrY2NYh753SHVpGQZ0UvMpqNJhaE9u4IkNkfZbcPLoZjg5oW9GA2vGL6Zfs/QZ05hYJrx+ndfdAduJhSjMZ4SCuWCVf9BtrwHav4uc/bI2mUpwWoN2RsgamzXYP2ecUKXbe6qA4RdhGgGeab7RoOWA5Fzfa4/KMudQO7LLtbl6UVldRJcHAjDQPfkxo/Vk93n3oqAf5DUKqn0wB05ZCxNGVh7mU6Mef5q/fGrFXxiSHaalEPQOy4ZQiTakpt4TcntcfwQAOtL5aFyyX/+cWG+2Oz1NZoRyXDB114m7lt6ZHXjx/4cWtK4hzKBVPBErhj9bkJcYWEPGYeAa4Syw0oiT+OH/j8UR61ZmSOVInk0dEHqbiJZ1Hh7m0g1TN/6A1dHKfxnCfKBg2V4+KMDnWVvaSisdyyJypJgasxPGQR++NhtP7Xz3O9urYJDI5cjEWTbKCHLmBXW2W6sGNgEqYAqwWHFa6/OqGAefNT0e4UJKXbIJlOpJeprDa8xydwxnL53llb4gf1Dmb+al80rR6gnki7gWucVF2XIdOO84+ACC5pwsSoXpkJ/Cw9jVwPymPPWNHSGx8jT8azDTl6Zs/v90joNfO8k/AUhTL6PlK7wy09eyUug+PkAExtVy9twPgDQQOB/R1oRdhGDgZrjgSRUG7PJFqc+xzvFLHF0dzhBeVy2nsyOSKc3uCngfzwy+X8GJmlODfO1+5my6CqjBfyR5u5gReEhsve6fGdLYIAp6oC2rI9bV+cD3v9hDiV/0BJS/vgO7Cfrw8uguKxTMxpP2pOQKKBlgBNq3Ed6yizXaLEnx2eK5O5OagGWzQb2eSkYZ1ECzRqw3jjTFI3PLSa5ux1kjeTmVjNPQ32KZoOLuGJhDV9CG+67BfaCXAUd0/LUy0uv5mQyvaCvIw/+RTKuiwuCSi9bI36XE72Em48V5bNW0xNwHxxWG/HNtMxRch2jtZdX5Oiy6XfgKYUWZBmNMSGCe7JOOjElAkAkVRo9rT5EXKg5Km4FCH7JYVdfoe+kih6jXWZK3JZhCS2Kx67Wta4+SXK1M75K2NDAjPTaEOtp4ZS6Ob/ntZ9FAmEP0x/p56lZ4EcyqAg6W0B7fZnnKl6aQdnkvtjzZC0+PIE5dAgMvx/+PDyJ11vPEJ+gXWRA++CvsRBByqwtSEorzkXbGEEnh7Z8wmXNB4lJMxsjSeP2jyiERRpQXEBnMJ4Bm0iHPXja7twZQhIVJIrFG5xCk2+f7pIqLG5PgtFWVUv+dXVLmbrsaGQAedhKfdDus/45exe2ExIKQoG7mnHFcXl0UmxvLcFgzVJE1SYpEyEww6u/Ps0dasjdiZzxtBtfa1Sxro7J5GTlIDReRrkWU+bsHX/a4liOPl+8JIaNutsUEkv2E/s+ji3w7OVzdC3t27NZE+Xu9E6Iw5CFRx+0gJeyMG6ntpEuG3LzB0fGNjKwP3/vso/rtiUDDUGRITWUuLxluGT1inMD1ck2hu8Q6GevUnF5TfisXi1aDoJvRMHWI1MU1hW1VoNPz6fy/jF0P1BhoCRDkLcRAYmCV4yLjByboSFGJpR+iE+zAywpAAStumIMfHb2wqTzBAZad1R/DP9tkKiY01ywzeuR7bOUQChel2CWxm1SVK49o7PY/AG8aqr3rVcF/3jXzwrQqylFPJ1EneeDCAYin9wABzDQLJhDvVrk4lV67ry9kFg7AJWMB3z7gTNN2U57cEcjtTCcsvYKMrwgsIYxhqw9M+7n8QS4paOfCY90b5cMy+oVd4ChdPT6XN55wYARSxEE9EMVCB+ojpxkV01+YovXuYPwf6e5WAGkzv0NzSVR0GJpFMCmHTBp4UjcoOnYxEzkeJL+QldboUQo2RvP6V1CByEiXxGcQlDm6PaY+HKcHipNizUzvSLr+k1/OpmJS0XY+MQAk3/WnKs3JsaBukPXJOnTZaPaKT95Z0VB1zNqYwk5E9I8FRSCu5gvMp+t37BlJV7le3ReqyaYJs3YSjYtHtC1VTR/0XOAEmMRxrHqjaRtJtKIFmKn4/biZ/pKV0GvLs3CSJWvT5QAdbVOp0jab/R3c3ErXhQLIDsOQTD9NenLxspaE+Da4DlG3nay+po2Yg9ZD2GAM+RouURhd2rx634PUrItlpMKXuU70kxLhunUlvBUnkP1cDC7peRucEyCtS/ibt5UXbHJBaWIFhsYZG3mafOJzKVC0Ath7IoPHLz6OXxVMSKcGAD0BqZ15TqoGfigf0akuhMT2ij74Y4XapAG2pyDAtxVY9yFMlYWIq8aR80NFrY9tnYpNeHGr7csLM/vPqQ+iYjTDfxLkqvkU6bBljqy9nK4SNKUpuKZUnTH71JEO933P5XH87MIA+qS34s5Qz4uSPOYmXgyH7t5c07wYz8Dybafm6uyUVNTNgr+F4UEvAu8aB2lrGpbIoZ08DaM3j5ryRNXltYXGKNZBoYIePQCO38x9OLeHY4uq3FTTJwYE5o8LYuHmQkpVJwfu+ZssAZZkTiByuUEf72iw6PYwTxr7Zikc1DfX43imDy+qlSf2+VGjOeYn77lZEJTlIRCemKbrR05ezJwZHQOhinotC9ZfT0drSRnpIrnmrCLvfSp8doa4vvqhCrXhqD82aIT/gVrQtMPhB+H9qY+iZf07nHXBNik+miTRdG2U1Ce0Qp+LtOslwpJU8MX7JrfPfwTVO4lF9wTZhdqc0nWrjtHvQP7Wac92skj+pjvtS6+t8b6V/DE0owhqjFyVN4Illca3RNyEs4Qunk7YveHRQWQYiWC4hAf9j+UVkXUnOFrZzjKWvSr+2Q/iXsgAMX/kFjhmoyHPR/COhOSnV9X/ixdBJSQGkkviJyFo30f37tFdv5aLj/moBYOB8dU5iBcyyig38OHSoIR0jpMbPRiy6MWfQ5CuCkvxJlsj3N2qW9newq7bXEP2auu4/NB29iExNd2Gzr9F23x5G6wW9/5SYfaeZ7iLGziBjBqTvUBVVmveFONI/WoQpKtnv2Ld7bgTOCztqThYm45FfqS/uZSZ3/HvxP8Kn79EJy6j01q4lw5sXurmQ1+X7jA1qmOkY1tavIua7XWx7of3PVseXt6gUAvaDxsdy7dm7ZJJeo/3fCk5DHAACjH5MpAMDdv2df/fttw9Mh/L8ZWQvpb/t+IwZjtq9QE+Ja3ZuDsToB6Bczq0TVTpz8Or4/efgpJ8kUboUH2jTgZjnPRh5bvsfKWIyWCYqGKt5C62OS5PIMn7De+BRv3gkT6j80o0JCBeHJEBC+sFonMG484gmK4mWiw3zDEFRbiCr1iv59NyQ7aufuBpziv5pEADSwJCoLAhoIL7aVhh0hLL87wqj2OSK8zHHEUHA4YkVTIG6QFwCjZgX/TqylTLHJqtXzZVekRIMlJV+tNIPXqmNhkFcikJ8AzSOZ+ZQWTqVArSQYgwg9hiSo7TCe4mIkQrGcBsnM4kFrK+FAO4t64k4tDJZ5sdINoYcHehIPEnCLIXN0sE0lbXmhWijZxI+EVqVuLGnP6gwsIlKEjYPIQn7/L/Y19h0WAgAAAA==); }MultigatewayMultiorchMultiorchMultiorchTopo Cell2Topo Cell1Topo Cell3Global TopoCell1Cell2Cell3Figure 5: Multi-shard and Multi-cell clusterMultigatewayMultigatewaydefault:0-infMultiorchMultiorchMultiorchtg1:0-8MultiorchMultiorchMultiorchtg1:8-inf \ No newline at end of file diff --git a/public/img/site/arch-ha.svg b/public/img/site/arch-ha.svg index cfc0376..75bf060 100644 --- a/public/img/site/arch-ha.svg +++ b/public/img/site/arch-ha.svg @@ -1,4 +1,4 @@ AppMultiGatewaydb1@primarydb1db1db1@replicadb1MultiOrchHigh AvailabilityHA cluster can uselocal storage for improvedperformanceOptional: Consistentreplica readsEventually consistentreplica readsFigure 3: HA and Performance \ No newline at end of file + @font-face { font-family: Excalifont; src: url(data:font/woff2;base64,d09GMgABAAAAABi0AA4AAAAAKegAABheAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGhwbhxwcgXQGYACBFBEICsA0r14LUAABNgIkA4EcBCAFgxgHIBtTICMDZWTWSfaXB9yh+IoPQC1Wx+pa1IVJDM0Ji4QxPFvapf3x4Ce/zmVoYAANdDRcnYY2s4bnt9n7/8P/dCogWBg5sYk0EbEKqxDtlfNuLspY19XWF+nS7WJ3ukr1qlbNP/h77rz7v02JWvgTiq6YmfmbJFSt6EES8fdz2+qApmpPkNiIgZS+HP+nqgIrbv13h6LiQhIqdictuZTO4jIxeRk9ZVjEVVoBkF2yhEb2Z7O5lJLkgEuZpvyfbf8uiUOVEzQmvJhWVqnySJvqVynTz550c0+6e+eugK9gz4Fn8oEXk9mdpkgD/IeDzn+3gr+/TN13dKspQKVZwEoFCfnOv/r2Xbd/P61b6VYbtQKYiZZGpXa8xbOMBzCCIQnGNEIRgZiUW+gWOJtgQTwV0ddZZQABgAIIU1SUD4gvQM8DAEmYJLhln+YEolOvpwmILp7qRiBaKzpagAgOqD3qAeh29rQAwtEw5TjwFUJjDjc0/uAA2cJfY+AAb/+GgXg7bSQ5psou/v/dha5NpemeQuPB7ITklBtQNL35XqbhR3t7DVjSSX93CsILZ9yBUwwUQ0buD7zeneA9CcAyfkgIFwIPQ0BERUPHwMLGwScgJiElp+BTCRB/RKKyE6sIASscAMQwooQ4a4jXkL5B0nR5FIaMgYaCSUS1Ymc54sC1uATm/99lUICgGAsYkRkpFEgFgEb0o51YLdMaIU0Hbwler7UVgHP3VLUAGlC12aY+Tj+IE4R0ZayqMppQUm0QOtdEUdGJxRJIMdaTmADAlEgQiCLWO4FrhI2T+Ni56KlA0ZklgBN1jm2AJiAcD53gzLzYHJdzDMEjtLR8AKTyTKCjCC8gNWRV48GSAcaATO/U9ZMC/r3C6NoB23TR0xmSNVkAI/JOnAAyZsnybABIMCAoZMJFiqNjYCWXDuygHrhBN+h9CyCAFkzRM0EFaAKez6H7x99+tbRw03nP69SqWQMEYIcyTwDgN4EMKVpPOiYoswH6AYJBGUCMYkNO+N7y1MLG9wYEiE9CoU4Ox8XO4aa0pztKq6QBsfJIji8/OoEWwMnONYgkqjSD0CuQHq0tSrVk2iK8STxvrqXCqpBEWqIn2tP2f9OZgH1MBs+1Lcpc5zJl7BZBlIqClfymnHRngqwM3dWwuogLkP9LRcMAJzb4obXDfb+Sci2LeBs6cx7wP6cjSZ6rdub9Bf4wKoSD4NEv7bLT8j/aGsLE7DI9K7arciepUTXI7rT/JJoLN5MPWBGEf0c1aO8gI5jECmDBMACXszKd0pVKGI6/eIYupZQi2mi9HFen4Ran5dt9mIZTNqfHPxKmRAXpSVcR+EESnDoCes73pCTZjAYtb+6jT06Cl8wcQRTMgoDxgMWnd+IXWl9jqiRlGzboqNO+J4naUVQbxFaVVAxYJJAkyeLTp4BfQYqtnfWbusK8u/dQs1fJWC9BXf4G1wrQXWMCIXBM08RkAC4iYCBQtVgA/AVG3sjzaOnxzLqIDCYM0MzK8MhROJWy4ePE6zlwaI7LNFZIIXxpPOBIc1JUpNja4hHVcEH2bd9ogcYECQPXYwTvMC3BADRGBCGYU2q9zlzLqJrYmmbPozMKI+8L5Q+jHCdeL5BpYgttop5DCsjG+bz2xSjncZ6BkTfAh7IbwaG0EhAwwKGEwj5fiVdozJFBKgLClEXw7Vsn9kltRJSoxFt3tC7u84XfmLwRAgzPZCoAkqIiKWBfQshbYhLwu4T2+YKxQTSsAjIIWESOIVvN65DVjeA9tEqkNa0FLdQ45T1+1TCjtffDtrJ9arGv2n17bD81voLGbnB6xheM9qswdI9KWkunkeNgQsQxj/AvMQ3Ya8F3V+SFagp5wyhCMgxiI603ndmkqpxv0hJvUHtDzORqot3V41l3CZBVKsJE8CF63YopU0P24k1n24WMbEIYgrNWYUD3ixVAw4Dv0SVRZ514oapC1Sae5PQYDOJHadV5QF7RoAGx5rJhQbTH08YnmXeN5muaQYDDukImLtQEZk73MqrcpODgAtUxBdhdUhKkV5j8X2WYTtnoSy7mUQqiv0gUbeEBkdQCNBWl/dLxkx9vAia+GR6YS/IQ+kJgj+WTinMfBUyb3Wf12WHqSDTc5lo/HZGR5r1AgClKKERJHjp/0SzAZPGARab7FkkELBTlznYyjAKc3I25zp7ycC7v1XfJPIxJ14CyuUem5CAVhHPKKlmlHG3zF28wPb/fGzkmFEJMKQrwBi6gAcE+ZWAjUvTSWhDov01uRuzVMrXE19Zzg+3D7IJSKo3Ufb61bmGlf+8NJmscL1zb4PwsmHB7/owmk/Bfx97qXUIDo7lk4tfHS4fsLw9JOt/MtN8cPeeJ+FF91i3KDkjbIi2ihjD9uU1Uitg9HwZ6neqCWJym5JwiXqhljMZZoJQerj+c3yivUp+Lvk6PsLv5G5F0mGxVXnbbAXYBJRk7S18k9XZBjWcIqGF0pXSpucdPGi55eCljXXYqkOSFakHoBmdnF9e8s7FincSf0G1NKYeITGdlBcUvNP9CdXnsz5RrKuGySWqqjeYiXjPKA7reyrRvjg/yiNZmmMwiFsUCODHVIFFc2mTOkjpWmAXRX3LkR1CSIZlLMmKVrUagCMP+7VeK3Iba0sdp/Iiv6k8CjR9y6nNtYckzR+FUnx88RnBcgJAkUWeicWsGAY2E1ECIgP8ImE4u3F4oNpmsodHbNolgVsY2QzVNB199DZNFlOQOJdqlXJ62+Xqq9sOtj6t8Pm+ayIE9JCCCTYZjBLOnweYkKAxschfdzySqaf6TKOVNrITpMFXg22BuRMqxMlvZT5AiqsX7WFQKggU/TEmiOrXSutjn0z2+xUcwK0xcI6HDmOEG1aZCgKmpqkpipoygjivO5puRsXocDbdbY65t6bPZnZRTrWJXRptEqirVrHXRk9D3fci/mUffgMAlSsxIFmjArGvFJI2rGnsbkrz1SyY7sbczPqe2qkS7iUFxBVERuNul3GzS8QI7bVNJjJqoCi6gnVr9jjpTdZWjx5ljBMHxpKoB+/b7DHAeUaWS1SCpJSEA9OFAxkJVoDYOb6NhWRZJyQ5zpqxq5q+LMYJogv9Ag52ZhkeyggkaXXlwF3YaGr0/dZB09x8mwrt7B8/PXveGgoCBJF2Snc48NQFsQUeholEwcm72c3W9RU+r+To7mExBpOpcpssRDQbOBwQ6l0kUkpRUo0RaBz83DM5K+txfc0a+Naa2DVjAh8FsYojkQvXn2fmcelDT0oQ/5ZEAZJ+U73OrVfrG/tmSOE4MFQrwk/EH7/XXZxMDCPoMZDxfBWuI7eToDKTG9+lH2VQqHZj4X89hPytdl6iSlUouDed9NaznxFsvcZHFjLWVm5QHKKTr5SdCZzs5JoJ5ww+vNhkXQ2w6eDghoLEUTDZnMCUtMnq9Iw17J1qaR+cc6/xMSbBSLNYxUX6R7+abZepP781zlFDDoE5kt+pTAKBRuryckrYttfd46+vqfXZJfBNWLp/qq9WxZRUnCXGzS0v+w3H2WTCLOBDeUEhZG7/hAd7LRznv0OFEZ3DPY+lP0v9vcVPMdDM+n74Qlpw7Snu5Da61EeChjDOdlPssyl6z3C2zbLil0nJ0j8Nj32BBQAYNtgsNoyA7kRtRScUx/GzJP0V7fuzp8QjtI7uGLBvHvu1a1Jx35OkF6GvkG1EFx09OYyPqX2QEp3M0wjRw8FB2FtEdkiz2+3eFWUegf/w4+yxUPWX7B4I2+mVEVbyRzLeY2dIMcNXO16W/g4UJ+Q6iTK3khGZOoaktPU40cdXD2W4kiGWbtn/iQWeyAIF3PVozuWEv/p5chigSSOV77v3ffEe8CN+yrqM75m/8dOqF+R9/v+uHtdH/dlJbLCj7SHbli6pRPCk6bAS7jWXhMsnIGVsvDgTDiAnnyq3nTbkQFZqcu9g1kK+YyeLYhGHnyjT6H3fasAqTY2ncjlqKp0mcorwpabEiLmHKgaSQqYeJ5X+MTj3g2Cg7KYWk+s/r4jUmgWuM7PnL1D3dVU9Q5xpMIjCbMLBeWPJ3fzyD+mclpoZMvTBtoVfEocA0sdc+uu8x4odEaIHlWr+WB377wZDOWSBrHohirf5HunlyCVnxJJXSdsBl0Bb6tYDWX4cE+GdTUJT59F73TEGa51FiWoZa3fyH9yG3Bf0m5Brdcr8RxWtQlBhKIT9Npu8Niils4YRUSUdanXIbz8keIZ+SOM+l0dr6R6n3jVSW3zNSmRpeUTIwRxR+4WjU0P3lS05uecZFs8+MfJ+Vot4+exIII6nH/+qwUSYkpLU50GrjYt4GDpkyg0Z8XlW1j7Hfh22/WJr3pHPHo63BJsNzTjE0ALW6D3G+AFg93ccLhSDYJdpAg1nDpxapIDL03q9hkelMG57gZG88vwd9jLpl+varx6rCQkBeyHO54VZYgXsLMIA1UMJC/4lP9TlbufVFI/pCnaS2XYbCXQwcPCM3PWuZ7zf3XCb8jajOwGQA6OIxU51zWckEk1T8939PTIXrM+xRuhbJKEAc6GqETTPn9Ap7svpTBWA7hfMWw93oikSsgGAgYAU5ZZHTeK3Rl/gxwzLB/WP/sdGTBwZF21Wz1q5bfwGfHDO+M1x1uBVn5u828I69rsZq3TUBQUipxEg/RDo0Zjj1Q+2sG455uKud/EyxyuHz6QIr7lJFmxb2tqOMqk4Un4E46Zd+T+rbN7SSPlF+vmBXf3MW6GTsTOOgJZQTL1PQb/bIU7ocmGzyKF2whz87L/7K6SOf7nPaB6kXzJUr4YEN3yenVxHL2eVEuFnqY8TIwlnC8L9/K6e13RiUq5ByJvZLDlr6HSb+aD/ICagYv8+UpmsDFkuKQGfTrHSTS9PsqG3sarAeSMhSom3GXzmkXRkw1vHli0WBw/tFRlcJzqrNNjKjl3JbbAp9zClQhqvE68BxpdeXbihs8ZIcbMSJOEeMsvkkZr2vLYXg/xwcyh0g2lVIuU2P71N+byZxCKj2p/bkOiV3AF+nFth7GIripPxQcgHkgMcQ9m7GE2GTh0AjWuRekBGifsoi6Lng+Q7JXMTKDy2qtytjqoS8D8YhBM5rFUOZNKJJHJDJ7jgiA99aJ2a+S7E/1bzPrtgQjOV2ACwA6TfyTWUt7fkK3azQOIhIzxXbE3YozOBz+XnkSkQ5d8Ha3h0ZqT7ZBK6x2MAe/XqGjF22LD4Lz1Gqkn5GPO975xWtQ/N5bh7AeYZ3MHabPiFqIXB4AGuM2cbD4S3xIB4qGS1jpPsNqp1Sq6tnIBAq4fWPFvAkqMEYooVCCGt8hKkKa01JerDDOyWf5mu6UDHVww+/IDZOqPMyhnpFYW7fRmjve7mH0oO4W5LTfUN31/b2jz0ENeySYEhPKkwRr0z7Fc72/6xXo4kWUY/nbM5BN6PNbJdyldpcyj2aCvLMz2bOC6pa9coVkYK0eD6QUdHk1GEYHF7MamfOaB+f6uIvBGRgzko4yFSOhO7C6aaife4BisgFk8TgJDqjE/iuaLiWmcMNhAJNnwVVKYat9EyMWb9R831x0Up+Bl9RJFhBy8S9BHi1a7/5lDLqPZ7Oz9Dm1Jcwr0Jzqq1IDxaVgosczT/qxtWLAIlcZQlICSEWQ9lzUaeY+y+V23CLuY4k+R9PXyShL0fs/crfvawbvUPsCo17ybq0qPCCXMZ437lxJ9Py6M+tQcpM4jfmOznfMQtBMXVMlPWgknHzBWpuWTXAK/P7XTsur5lIVo2PIZOPYyfX/DF83z/qC1gfv/thxMt06Egj3hOFCXpKwF5W+PkbB56jWYkYMfOdvgzKVIp/EoIhvRgaxqvKYDFK4YRP/3eI10UBu4rSqPROV2orQvMkYm2K11/RGKf5X2FLC91iOzUetdt9XM5/mheUuIa7A7YQndWRwC/3tLKmISkrTfCgcqwtK9kXl1WA8LiRTXfO0/a50t5hLxi/afCoFJzpQTsvKxOnDzD6FP7ZjW9/rCNJ4eyfI1e2cTnfRdTuAIdJw88WDQT0cVmG/r59Bdz5Pt6MobijUCNPmLVUEHW0fdRjh2fvfef9pyx8U/jhe/9VnFZuz4a6wuKiPdQMgnXyrG0O++nFdUlq8BCLDdztvnxhFwFP0Ejmk7Fb6YDTxTbHFDZv0gozKvisL4wjTxUIuDFATC9l4bLglbPC4xfFWUnR+XVPM2IsAE8OI+O7PzbZXz9oNCuM8fG292s+Z95UyvScMm9C1xZk36ASiDWbM73rad2yqk23gn4H9zHB95Law6cbfv8ioDHKVkelXCHzFysAgqOGRobBqSykCObRXgWw8Rr9cPkhCLy9kGg+7mEyVmEudDsieTy5leOdv02SHwjFsExtYNWJ6edSGWnvQAWbaXes0S6O6PPphWKZecxFgu93A6pUjNmxfEwk/cP3zI/c5taLwQRFKASHBjSABWz++B1oroCKkcjnRDD5QlAvT+INz8cjFhI1mPoZtsYGISbZwV3UvnHQB3aXK7fCD+N4lOGisujNL2fyAz59zIlpZydmT107uDpljFAA5X0j3eRL6T7pfHtrafAcuJIYnm3sYW7J3BKZ9s8ofCs5j9wOh4NZaZFly8BRmCRk1dSydMW+B6x8BUqQ62KiHeyQjLYdxi+9beQ1Unw6QmQY/pedalDTYiDDkcs+ua0+N7TyXQ1DjUe8LDmsLOQEJPpTVgdu4QLrv7a9xNU3BNYf0PmvT05ZnDweaf4ouXmu5HG1O0yW6p/Ls2nMZN32WkjhDAnyPvM50zlsJPipyRCp+f8jjWCzx+2+kfsV089C2kcANSLIUUw0zv//PNtExUY7vcKsrynz/m1JUtxwRG3BEeFBOdYQVzWyYdbarxPEXJvV7DygekJOpW+bS+sDq3xGaUYO/rCCwo9UUKFd2/l7lhcNlHHwRNEKK4ey3zJ3CYmtWgo8POry2Pg9UxOJNMSG8GAj0JnYl1WaiL+kuw9ryZJvR6O7grem63NEumiza1KMNv9WrMzGw3LkfvhRY5eV61iIz/r/WOfLq5cWPv3vaM79/Bh96TTGbJPPmwc4moki1eTHKvJsX44113DyGlF62HXzniGWnU8Z09R+WsfbHeKHuGtU4TcO6yb2fAAWVDw1Mw7zS8x0DSnzoOhNdVTYQ/tR3bum7vo5Flwn58DYxO0sbfnsmHR7m2weuEFBsTjdkt/nVwsccNLsXm/Z7iOD0ZH7hwWQiZxDRUOesBXhCyyILARWquJCHT+6/E8RpV+m1EhS/DU/fIQhuPJdNHmo2leDS6RaHrxiFYA7GPPUZ+c1JUL7wW6+dAFQQHKgtD8GEYhB2Lho0adbH868Ugjytm8RXSm69Gs2uv6wDDeWRsfuaXQ9RqepZHnMbd1eZpXcEKZDMXCWhsjIF/VTdesWtkbGQ5th1JfKVCuYef1YF9NZIp1rxq8JNOSl6jw1076IzSBPRdUs6ZmQ6s3h2Udif4a25dyv0A4dsLRFpSj0SeYLU9xusSOuDtxpl61RySmlsSs/TByZvGaOlQsrL4uLmnQVJCu/35/5tN+Cqv9HymlBlp/6Nty7mvcqNrMWZ0xYkT1HIFGk9yW1Rf0Lx6ncgkNJH0XExBGTfEQkYDjueKZqj2q7yFUNBii6DZsG5LfFA3D4sm8Y7Ghtvot5l4h9QG3p2Bl7Ko+MVFK7SP+ReMtv7GJufF/Ktz7kc57ih36bLN++03WqYKqmf4RX7jd0zghx0CA9W5yPupYzwd1jxypjEXJe6kLsRzrrXeagEriZ/0kKuAEW3aodtlwp939ZaOoiv6CUIIKZS7LTuVzb/A9vziKPgK9u150Oec38HtNQNSmO135sGGqqlac70zPVjimptfHJVxwcQE1rDXlWVXY0+635eZidNXTv6CMR2KDNMz6fc1VGT/gQbMjvAABTvYELAABM7/xr9tt3f7Nxf849ABDAFozfZbg2LEH/fdX49wi+6Te5mMYQAL3wKiccBKCbEoW1G4Af+J0S0RoBE+Xt60bUvcHpLWD1OV1avqlFj2dklQhISDzu9/x+7+piRHuEYQpEtU5CNBBbvjB5rZixWXje/AsApTxvRAXUjguOJWLsJdmItf83AQ3xcxWgTvj7KNAaURdTCAHNxHNwk8kwCMfXYTCaQ2GIQINhOEquMLwkSkRVRQBMelR+M7OXejVategQzKFarc4nJRU8cq+4R7vIFPteR4QIIx7PIpf0cqubKk8hEiMY/TWIGD1GgOPxyBo6NnujbBYZ4i01VE2LaGDu1itgvSGq8wj9DWAA8whhG4w6okvsKLOKVYZLKnQLUVynidrLrFP7FVYzVGOXyqwS8p2l/PZNUwAA); }AppMultigatewaydb1@primarydb1db1db1@replicadb1MultiorchHigh AvailabilityHA cluster can uselocal storage for improvedperformanceOptional: Consistentreplica readsEventually consistentreplica readsFigure 3: HA and Performance \ No newline at end of file diff --git a/public/img/site/arch-multi-db.svg b/public/img/site/arch-multi-db.svg index 443615b..70029a0 100644 --- a/public/img/site/arch-multi-db.svg +++ b/public/img/site/arch-multi-db.svg @@ -36,7 +36,7 @@ - MultiGateway + Multigateway @@ -138,7 +138,7 @@ - MultiPooler + Multipooler @@ -493,7 +493,7 @@ - MultiGateway + Multigateway diff --git a/public/img/site/arch-sharded.svg b/public/img/site/arch-sharded.svg index 3911fe4..481d723 100644 --- a/public/img/site/arch-sharded.svg +++ b/public/img/site/arch-sharded.svg @@ -1,4 +1,4 @@ AppAppMultiGatewaydb1db1t1default:0-inftg1:0-8tg1:8-inftg2:0-infdefaulttg1tg2t2t3db1t1t2t3Sharded TableGrouptg1 has two shardst2 is sharded within tg1Default TableGroupUnsharded, required for all databasest1 is unsharded within defaulttg2 is an unsharded TableGroupt3 is unsharded within tg2db1 is a single databasefrom App's perspective.t1, t2, t3 appear astables within db1.Figure 5: Sharded deployment \ No newline at end of file + @font-face { font-family: Excalifont; src: url(data:font/woff2;base64,d09GMgABAAAAABvEAA4AAAAAMSwAABttAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGiIbi0QcghQGYACBJBEICslotjULYAABNgIkA4E8BCAFgxgHIBsoJiMDNZLTaoHsrxLoMac21VOklAWblAHPMFCDUFxi2eKOzxw66F/ITMY2xE850vD83P7Pje0ug41aw6gcIW7NRo0oAYVR4RjRBj4Rm7CKMF4ZFd+XWPHFqmc1PP/9cp53/+IYj8SCZhCKQZgmW08xLjrCmdisVWP6sf8TSYhFu7dXUHG2TlTW+ADJ3qezV37pfK3h7gJsh7lCMqToUqXoV+1MO7MjsHklA93/3/CBYCX1P4B////LqUlXzfXPjMBOCsYAOk22LgBYceHk3ddjD/fkml4lmeOAJMuUZBtjAVDSLPz9XGn3nyIWBkiesIzCnDF/3uLLX3Z/Yw6AcpgckSRsx+/UApBDlI2LrKswrTtZ4zt1tbY1znQZboJVmzWjJyJi/T2j+gIIABTQDEPgMDmKygvEl0AfCgCSAGroYhmfBoTnFkcVEN4dxZVA+FFQXwOEUAAACen1vjpqAMGVFAAI3B2GnxFCCwHcThtK0G37FJvAYi2fBxU59ldVY92eK5erfXJ3NVdZ0spWVwNQuCTusfzzqLbVBgSKuBqw7FdGdsPJ3BaAWX4w19f06wP4/I3CSY1tdfc6TEGY89hJ4ubDyQI44ISaA5l5pbGSMgb8KW5R8bYhfCg8Iho6FjYOLh4nAkKu3IhJSMl4UvKSECnMBwMBq7+QpP0hSWFETujNCD58qxnFg5shu4hkzfEwJaXgYKLiKkazGskDQXlhVZUAPhGYXnHGoAKAgOg9goyCVGRMRwBI11ZGBpdJlr+sZGArGwQlxbvK5LCskwFcOzbFX8j2WzP47AgOqLsMigi0YJMMsuDA1RE8EtALGQAYsBHqjOTIijowy3d5Q0ywt+dB6ceztACIvh1FDDxsvQIOAKAADYNAwzeYQsULpWUMJqo5whvRZ5Eh0eQQM62QXOyzb4ZJkDgOCdKMpUQAUJdMvCklIYPdEJjhr9uBdwd9QjOY61DzbCMAiN9WPE8Q3RlNWvXAIWROsgAQR6cM7QT5koDkcEP9ypQIjgKRltb4D3DDXtU4BtbuxH7cOESPPghIxvEOJKJ6GIoMpefz4CdYKJVIGnomCdKVa9LSj7FFfQQQY3SqAlXH59ioG6647JILRvzhf8456YidttsWBFqhHojy90cm6jSDKDOANk9QZkMjOuCJiIBVCMS4aN4gJ3NLbisgQ+2NJm4stITvn5VWE85343DSuTq3hJSi5KS0YI6CHxpNU3JSM3RCF3m8TuDmRfdnhqpz4kxJ5iB3Es+da5KQ2DleCtR52axUqLuL9ljPcdZQKZfT1CnvrhapVIoVKsUskUKRzhDi7VXYcwMoEHwZQCvpdWRKw4uC8DS/x9yx8ET0Fsjukjy126qJxMNdOkveCHFex/7COLNe1FsPSWkw1GEskqnooDnkKHTH4fVHF9gz79z0hH9k+UmABE2RIVskoWM/M0DA4APeHXb/H84Z90PWPFNWVFhUilSy2SzCMOc5p1bbr/kxo5punU7ZWXyMm/K8sTs8fHUQzLbpiB4QqGFFMzQDzCN5efTC54s3HMZZr+Vb5fWAt/PDeW3uQuLbeOHoo8gxaAtgd0l6xStnM+Db17uVq2kpHlGLNPJw4vC70vUP3Ka2DYMEm1FhLBJ+WowFOFdZjobz8r5XjDre4FZr32s6H0wL0dzmMj/Nt8piL2WlsiXbg1rQWyTYDSNmfKozF71vvPnmGf/I1I6YhEmsBYhM96/SL7uFS4fEVVyak1GhGPb9+eeru3hUFlXIwLfGf+d3GpADSj1DokN4N39jgJ2nrfGFF7Cwe4hcv2a6jOpnJGWwGc3epYe66hM/sDA+FR2h0d8BboYsChy/dTFe04lZJguBLkQXjDqpPr4Nhbvi1e4oXceRh/ea8p0GChGwBS2kIFO7NHW3pz0+HD4O70V72QEqccq5o+t0kBSEQSoB5RJQ030geqL4GTeJK2uhZNyQEYDk6ckToC8AfGeyeeXWELZ9YldxK2QWLWNNrNFaDvprLscILdUNswa00O/icVzO56jqT+xVW3+HKi2/nGvkyIW5C6SrZiIYlWoPVSNcrY5QCYjeKvh8rsOGdIOWSun19zBEiIsRTv4lqSVJyjk5R+trfbh6Pne//baZqTynwh92/GffpMwz9j0xkcTniwoK9SnRvOafeqdzccfm7yhXewhv6UNzDoiUNElBbYGg4Kgg4u8YGWgzcxiOykAuGDcEfchXCjbm9EN0n4wC6QzbM69e56meYFczFVT9IWpJR6euvlVM2+ybT7QvYKXvnd6w+ewW1r7vnxaUTpR7loUZMcPSw7dSFrTThP/JJvHWBgn8ulN2aYTg7bgwTpxOk+0fWFikjVtBPBMos5PCtjMlZEpwqD2qSazjYl1hYfREWhcbFC1c5BpmD/tLUiL8ErPzl2VMTvNBg+7iHD91Gj1WuCAHPkm5rY8E+8Mk9pA0qo+rn6l8/hz44XPO57h5JN5w0wStPpt1/IGHEzkWaLmJm3szoRlxfepuLsuapN0awcnE7YhWsudMpVelaFlRZGlmb0uc1zBpEK+EoC3kAV4hwcMxosULOhS7sDeXgQPp/Pxihykuo1IsUqlibom0UyoBubm+tHgajhBSSThOaaCLhia0PjSU3VU+SO7i1eFA60uicscoUVwILoJU449oo4BPsEy77PmXQi8gVNnSoRhhVtnDC3xG3BzQBrcjpWDRnonRO4srCbcS2y/wpfnWeHySucoUWxLNkO0XFsggt2y5opXZ/A2H5zdewN/JhpS5RfgqEgtwiTRM+pIO/3x8zQvtlS5J18t09/XRC2xuNKjF/bzoAZgG6RDdhfWPMVXKY/985EWbXOPUwlqFEU0CX8llN9l4Uvn55vOyWazQkPFhlAfY31tTKc8VnYNAv+VhH0iAyPnFi1n7cpWtpwhppmQL6dbqgJ3MtDzC1y6pvnvKCHCh4nF97+zmYnV0diQ5ZxOv2L5lqhFi3XrwAI2eK+GFCvSd2H5dB1wVST26/yYTQSMsHdropLs3Z0np0foGs57HKp8DL6LrJE6ASbZuyqZy6Ke+VWInRAL4ZCtAyNkHLU9SmnnvNmO7Lneid613+LL2KtLRLqMhU65aOHPaHxqy5BmExxUoAYg+E/ebMQLSAlIFEUL2PZIN9qLxYqntihatnbF5iDIQWfpymjdfHAvzBRJgQvNuYTlLu2wjlYf+/pd1NpvVdeTgIRIob0+mI4Txc97eJKo0uMNdsj+ReFUJH4c5q8OlMB/mEvxrRqYk9dLSpcM5llQ5v45VKcdZCKpIfbrVwgY/ZMMDti9EGFc6rjPXc13je+W2xEDqWtYFPhcirOEDb++VxEw+E47GnVlRuopu4sdUr1xuVZNJ4p2GrBobfCCQA1VQ+KpAt9LA2ETzubwGC8ocrYmkab1KnroAy6pzRS/yTS5k1JU17zYwSj6nSpxsb1NpNOhsXqyWLiWmrsqcD2Sq1/9Obw019TI9kz6D0DueNC2obb5LI2MJXbiPaCa1AAbIgZMi5coct3B0mzTDMEhK11/OKpky/H1xhDCcyCO03DNr/0heuZwVXxzfxcmM03enTqb8P07NRffMRLDMWDz3EFctjNxmZ/dxMnNofcQMlwKvVIJ2ygovBecntO/s2KRkaVkXBIub4g/unkheOHtjNOEUjAWwSX4de20O1ISexHktpwEJ8ExudPDJlDAqFmadU2pTivTajDsd6z3CqBRJLHJX1fUC6ST/yBStB+H75toxeKOtTRMoh0958cSo1NXreJvZjuiHq0qaCYcCYgDaJH94Yl2hX+7OlnOzuYnEHn519L768cebwBhM2wVIFLLwIDXOVlQAqfkjhGHRpYMezJ0v56idAdu+W0MoOy1mj1Q3npFgo8B44XN6vzSodNCF3qow53rjbOkIRzN9vis5T4dEt/AkoKC15AXbMVLBINNXE2k8ONFRPD3hLCpPpUQO/HwNM5Xn2e1so0jD4ROjEmYkLEIguQgOhgNpLSsrKpgHGToTbGzIh26Bb4rGcjbW3KiGHccPMpLGNi2Hu6rqLOp5uBFeSCxVZ69ZRGblqJiIdBJ4QL3hvnCf9vFTWvK5VTpkwxfPFkZOLwbLm0zpIsQTkWI91X8almqjuJ3m4XlNoOnwDU6O1SjHkQstd4o0LSd6of/igkx9uGnhF++OzqrRUQ/tkJvDdk9Q27QNup+nV40mQG81VQbPSb30br3HvfKxc1fpNYTRX16231ev7VTd7whb6NaMy3iRKszdfVvSyGQ3XbTchYMXQ52FOJ2rOUAmKR7sREdzEjkwivdDJpKXxu9sL1hEr3qjV81Kk53E97ACccgIr9+09K1XaFG8dOBBpmfSAXkW/79MOpdl5yiTRSSI0VjFKyYG6bxhRJDr51sZ3HUFGL99kBAQz2hBbuSMeFygC0pme6jcPakn68ZxEU+OncGuG4Ryw8t+UgMGKL/IXPGLKz/2LZ/zcSt2N3/doO1E9mjJtD5evkfPWT2YK5+2plrCi4NaCh8q+pPIkyadAHiXDwnmW9KKvOhuMomf49PUFr5MS2aq69MMkJyAS5Fbx4x7r4iTvWdsWRVs25mW5x73D9ikHBBK/P3PLtmxaJpqDjYRS7vx9QRwYrKfQXroqBuc4UHGe5fO1/t5z6gjNKzb83l6jE/q9tTCL0X9OFJoQB92C0tGk8jIKXMLCuYTlrzM5P4eZtwNL+oZ6gaL5n7TzH/4ynlgw+pzfblSiAfJoWBRikYdckDuX+CIGskQRdzZ9eTUh+LsjoLo/V7/XX+lUTXV4HqX5LixH9KDanrQfhzj9II+I6eQGg87koEvjBhQW0Y5b9SGyPHjM7ptnVmSe8kcsyDg7CSV9u9BM1ZgSJkTOVBKcVQ5W2Q3XGpiEZvAsjnGb/TtuPwn/aNvOGbKIGUCqXx/WZTK4GQ7SnY8MzTdbSwneGfoDELwQszeUOik340MX44oWlfAHPu+4TN58AKtNjXVhZAhbT70ymD51NzEF5y5kB5N13xGnbzgQjIlAUXhiduuMClLBxNJsdqyyo8zBSmpnGeekr3JZpwHAy2m4q55RNM1doaFKLDVL4/bLr5p60zlAtsD/6x09xRXoHdy1WvD07iwriEp/Q4wsi25w3NzakxFoqjppG1XXg+x7QMuj1yQ+mH5ZlzMTUW2f4AWjhziatKD+DfPdWpkSflm7G9Ws8HIgbCBXwIkKY9yph2dD8cHNc3pR9f8x/bL8X+C2XOLhJdOMvsGoZtwCbUEi/MUVy5yXnYItBE6lwnynk+LYlCfFmLekKEFps10C9rqFe/stpGu2En8jQhNN12dpuYBQTB117N6M+VfF9KSdGiRvpu3nEOm3MMH7S8q2sjYJGVbL0zM/NAw8G6Nr0H3mZMLdUKT7Vs5BwBWTpe64SEItgmX02BW74lZcogM/fwwIDiBacYR0tgrzq3Hv8fbRdq6KzuLAvxApt9nse5mQLZ9NdABs/g1YV9X0cXt8FZrbcqOHXgcs+HLhFKSESbxCcdNxJMQkMbzrR7bI245k4c+6UTdClp3croxxShV75t0zXRn5Fr+qbsa9yLmPLqsyfiibS2pJCaIZUzHcMmBlszCrpwaF0wfdhDSxEATUC3bXGNREFMPggbGYDwHn0c59tWCP7JebGlMwUQjO+hO6/ltmVGXT27fuzHN2kX9y1i4AO5c/sf4hCJiPjufCFe7SvUYWRAmCHz+KJ9We71LLEfymdiDdPzE85jz75tAurLgzGuma4Ja2e2SAxqqwhIMNlV1SmllY0Xs5uhkGb5W/5BDGkqEsfqDX2Z59W4S6m15aKw6Vc8MncOtMUu04SfAJLQQpwG7ZG4H7VBA9+x0rC8NSevTi6aSmOUKs4Xg+Rn8L/bfe+ct1o+qX9gFy32xjHqAKZFper5hUk1dlkQT5h8JEekZztboAYkR7BefQy4H5XOnL2kZSIyTphK4+lwdu//wPTJ2ydR9Gm6XyWPuI45f3DNzluKzeHYeQB29A4xhwx6iGgLbOrHK8LU8FGeKAgK4Dk6UbPwlR8rwG1UsDYR+eadQQxbi056lqYbA9GqPtmj6ldVba60BUBuy987caSbg6PuiPbbY1qUm43q64FzIyi4L2NwesivBhYQ/tjLOva4ndHzizInvNdHVxWCbQBdcDCXi2Og5P1pugFXPSIKm1LqNdUq59GjXLzbl0lR+LqbGFc9E1tkZODspFhq1oN54o9idAC1n2AfslPUUNk59T417imWCfwgk4opBxGmq5ADjFPDDuxxPdHI5wp6Qj59TjcjtCkQZFjznv6MfGgO52k+3iBjJ6m7pktc8Oa+UPO6nhNU0l5TcVi4cknZY+HCSF5sJH0WWKdHa2UoBLd0v38dzYcP896Wzabrtjfxd4Dj+nsZJMb/ialI61wvyMuzzKZL0xtKTMGb5CtUfuTkL+Il8SY7TfFoS+hXgvG2bjCdkIT/zNB662jRtHvMK1F4cizRjIRY0uD9rhx0tFwISuciktPgRc6HUDnyaM/cllVtxk7mU5PIKR5/lQp+HWKfJHrvFrnD3s0pU9tlL40MCszMYZ1rPnkljmt49XeMjSyIeMd5OP8+cAHKpR4XJbwoZN77gjTULO3mTPB6rz4hL/h0vP3MUGXkfMbL4Se9rz5ADsDZq+G3Q1wRoeyXOEYI5NeeBDazAc9c3f8Ynj8OISTNaEymjFs8YBENaMHwAryiRxZgIR+99leK8NARY5ZRKmXuCTF3gn+nirLa4PQvFONUvBTU1dJP5xJmQYfsuMf9jps+4xdwB2ERMKw4GHhknZSUVMcnxTm8Kj9Ymj1egydkIjxtcdfscbaMtfgZ7+pkbOodcwrnbZeUlJ6FapV464WkTru69huQKp94PXlDL5ZwPKh0A20i9n2Z1Klu5LN201o3Z3KlSd0ZP5A6okidInuMUsqOu32GF2zbM+OUjC1cVuO3OfwUnZetSocaAyFAHNZEQO3La3M7+eGFpjDd4i5113HUKvqCRgCOoXKaSsZsJgNPINoZPqF6pFiQW8FkH9H0fJQi43klMmMhCk+EFYYFRsyJjSaFZZR8Tw00ARw4g45p2G6zf31QaJfqoKPMvJfuZN2QiLWeSO6FxNbKxSwacVauS3MtpTaKilTd9HoPXmKC46O3g03WPDygrQ8xlVMplMr9bAhCU6h8cAMexkByYR/umZONU2t78rRAY+wsnnIq+HY8VGCfYU4J5PHEsxz1rrUuWFxTOMtSChcfufnYVkTZ0FrCZ1pTF6u6gVmkLFMHMZM5y+mMYUF2dMSuWhQldnyhO/c2tnnzBlyDxh2B/ZQWYzuafuQ11OFExEvmsECb/5dPCc3GHp+IQE4nqS92HLTZDiEG0ZYjaega0guF82Rr4bSSP0pszKXTV13tZyr3vOeF17HGpo1e3LLIcJWRDmUdcVyooTcfTxmqac3zb4UJiYKq+mbk6aXVw/It++Ob4THIdHAjC4oMnzQU7YJKAVVLK0uQqNsfyJXiCWBMemsL2S6wd0B90N5MXu+ISECJD90p0osKbFg7ptl+SZkyWXleLhyp6Kre7mdJZycgxSPhUVAZuol7lh81f0fIKr/LNGs9l4y3d488EG38fX93h8r7YHiCK88zgmVVGsmZdKSRJ8/NxP7WfmdarJ3h4kyFS9avtlWCVw26/nnGI6WEibSSAEiGUkkvUT311jm2gYv0NbgGx3ylTXtbESK6nhKxGiXCXGKuILOpbHrbkcLQz1xxrTNss/0COo6/toLWCFbbHcbtyKBOodUjSqUT+LtjTcQAqSG12xyWrWpmP4M7g25nxGJuNJ8PYZGIXvDNCEENQ3Qfnr41maL9Dziga/RU2opO9YYo5rB8slPbT9BzcNgmFHyyhQkPr+Ovn5XRO4uCIwvmxHMomU8dsEls+Bzh41HkRUetH/x1HQ8wID9YDjYF9Sa4KeuY6vE1Ndvlff2ij75oEbbpQE2q0jTjjqx/lylJxsBh5HbhD3xjLTZmJS361s+HrlYszP/63I/11Vrh24l2MWSueMgVwVP/myEd2y8ltCk5shu74VaLrNtuNO7oIdhblqKp0bxlv2M8DsZfIA69v0/y7/lcwveCjkbGNn2ekq0hJW4Q/ikMC3lp3aH4yNJW3m9AGzuaj/95KVue3hSdYa0VTwHUKHovUzH48tdgpBY5pa3EXDW/vCg3e1OsEGcjpVLzfB7YkcLoJEfnBMnmkf8rfNs8TRNeDlhIXi6fqz98xBM0foon9vRUqdBzV9OYbKxvcxpgn9p1T5QmsW5r4rtOBBBIDmfU9CEJ0gspZs/aueXvvm8Qpc91q4eWciw9T8cu2idCj8XTsjkrTrE8z5M0Lv6XZwCwS6wI0eAycpiEi8gXtaNnSmZODo6BVMF5BZXpLmJnTsEZmWp5rhxG32EuXGadxlNxVIGadOA7vzXI95Ve8KjB1e8R9aG366wJ1z2ZTbYhFoo0x/jXKbXJOiSwDt+tEi+ViysSIBb+N6xu5aowQCwovOedUaQpIsfxpnsyP00x471dIPs3H9E/r8jtXMr9FJJWi+uj5qe1OLpKE1pjakJdwpNzutDXm96DwSGKMVEgCul0pn+R1IbUXuPIupaRJt7JTfMu5Ew6ce4TBDlVn2Zj/J2K/UmvqByNOZJKRQmoj6T8Sb971ofeXI3E9j0bKPxMQB++jZTtn4W3zmOD/O3cWRiDkzLiZ2N901k/MLhmwM/9zyeYqTZqFAwd5roxXIv+4WR4+Fh+CkUuy0rlc89TfboSR+8ChW0JsF8v81xh6ikmRvLqdvVCVxHs71Txah8mo0v7DN39LJ94Aehyni6z41P9U/2xjJ/fc2fFO+Ib18UJy65Xq5SQ4++++3lQV5X7jA0a2Kk7R0VtsXzXgLQ30v7rsxOJpqg0AsEL1D6j9pdr39Og/Ahl5DAAw2jJdAADA3cFnbf1Pb0OfdiMAEMAWhn+GzgGL8d23yf/RJfVvNobqefjrwFgQUNRK7GLRZpno+hUvB/vazSdIBVHauRcBaDIMIENAzWLKRhlbfsRJDWLLBuU6v6gp4i20PiVKHmUEnOu1z/HmnXCh3mEYBSFZKjo0EJEsAREIjzOPWiUw7jyjBEU2ux0VULOLb1iCagMX5VnS/zg3/ZVE+7sC8OZ/xA0AqIEUMwEC6oizqCojcRCOw3Ewmq1xCC9dcSgZWxxODBniK70BMGhW+F/0YcqVmKxGPV8pipVq2NBcwCFjgTvUsVDpLRLITwB6opj+qFazK9N0IwnGIELPKgnaPpzSeQoipbPT10tlkijKSlmZmkUdcbsWBsuNWJkn9DRAJfEgAX0MmaCNXSiy5UUcmjfx28Q1qpCSzJ7VLWAxkWJsrPQq4gcBlY39gAMAAA==); }AppAppMultigatewaydb1db1t1default:0-inftg1:0-8tg1:8-inftg2:0-infdefaulttg1tg2t2t3db1t1t2t3Sharded TableGrouptg1 has two shardst2 is sharded within tg1Default TableGroupUnsharded, required for all databasest1 is unsharded within defaulttg2 is an unsharded TableGroupt3 is unsharded within tg2db1 is a single databasefrom App's perspective.t1, t2, t3 appear astables within db1.Figure 5: Sharded deployment \ No newline at end of file diff --git a/public/img/site/arch-single-db.svg b/public/img/site/arch-single-db.svg index 1fc0421..1983224 100644 --- a/public/img/site/arch-single-db.svg +++ b/public/img/site/arch-single-db.svg @@ -60,13 +60,13 @@ - MultiPooler + Multipooler - MultiGateway + Multigateway @@ -143,7 +143,7 @@ Publish - MultiPooler address + Multipooler address @@ -162,7 +162,7 @@ Discover Databases - and MultiPoolers + and Multipoolers diff --git a/src/content/homepage.md b/src/content/homepage.md index f840656..5f719aa 100644 --- a/src/content/homepage.md +++ b/src/content/homepage.md @@ -6,11 +6,11 @@ Multigres adds horizontal scaling, connection pooling, and cluster orchestration ## Components -- **MultiGateway** — PostgreSQL wire-protocol proxy. Accepts client connections, parses SQL, applies routing rules, and routes queries to poolers. -- **MultiPooler** — connection pooler managing pools per PostgreSQL instance, session state, prepared statements, and transactions. +- **Multigateway** — PostgreSQL wire-protocol proxy. Accepts client connections, parses SQL, applies routing rules, and routes queries to poolers. +- **Multipooler** — connection pooler managing pools per PostgreSQL instance, session state, prepared statements, and transactions. - **Pgctld** — PostgreSQL process manager: start/stop/restart instances, base backups, WAL archiving. -- **MultiOrch** — cluster orchestration with Raft-based consensus, primary election, and failover coordination. -- **MultiAdmin** — administrative API for cluster management operations. +- **Multiorch** — cluster orchestration with Raft-based consensus, primary election, and failover coordination. +- **Multiadmin** — administrative API for cluster management operations. - **Operator** — Kubernetes operator for deploying and managing Multigres clusters. ## Learn more diff --git a/tools/naming_linter.sh b/tools/naming_linter.sh new file mode 100755 index 0000000..13588f5 --- /dev/null +++ b/tools/naming_linter.sh @@ -0,0 +1,36 @@ +#!/bin/bash +# naming_linter - Enforce consistent capitalization of the Multigres names +# Multigres, Multipooler, Multiorch, Multigateway, and Multiadmin. +# +# These are single words: only the leading "M" is capitalized (or the whole +# token is lower/upper case). The camel-cased forms "MultiPooler", +# "MultiGateway", "MultiAdmin", etc. (and their leading-lowercase variants +# "multiPooler", etc.) are forbidden. +# +# Allowed: Multipooler multipooler MULTIPOOLER +# Forbidden: MultiPooler multiPooler +# +# The check matches "[Mm]ulti(Pooler|Orch|Gateway|Gres|Admin)", which flags the +# PascalCase and camelCase forms while leaving the correct single-word forms +# and the SCREAMING_CASE constant form (e.g. ID_MULTIPOOLER) untouched. + +set -euo pipefail + +cd "$(git rev-parse --show-toplevel)" + +# The offending internal-capitalization pattern. +PATTERN='[Mm]ulti(Pooler|Orch|Gateway|Gres|Admin)' + +# Scan all tracked files. Exclude this script (it necessarily spells out the +# forbidden forms above). node_modules, build/, and .source are gitignored, so +# git grep skips them automatically. +if matches=$(git grep -nE "$PATTERN" -- ':!tools/naming_linter.sh'); then + echo "ERROR: found camelCased Multigres names. The names are single words:" >&2 + echo " use Multipooler / Multiorch / Multigateway / Multigres / Multiadmin" >&2 + echo " (only the leading M is capital), not MultiPooler / MultiAdmin / etc." >&2 + echo >&2 + echo "$matches" >&2 + exit 1 +fi + +echo "naming_linter: OK — no camelCased Multigres names found."