Add latest changes from gitlab-org/gitlab@15-1-stable-eev15.1.0-rc42

1 files changed, 3 insertions, 87 deletions

diff --git a/doc/administration/gitaly/faq.md b/doc/administration/gitaly/faq.md
index a5c2c7d1469..f6571295200 100644
--- a/doc/administration/gitaly/faq.md
+++ b/doc/administration/gitaly/faq.md
@@ -1,90 +1,6 @@
 ---
-stage: Create
-group: Gitaly
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+redirect_to: 'index.md'
+remove_date: '2022-08-24'
 ---
 
-# Frequently asked questions **(FREE SELF)**
-
-The following are answers to frequently asked questions about Gitaly and Gitaly Cluster. For
-troubleshooting information, see [Troubleshooting Gitaly and Gitaly Cluster](troubleshooting.md).
-
-## How does Gitaly Cluster compare to Geo?
-
-Gitaly Cluster and [Geo](../geo/index.md) both provide redundancy. However the redundancy of:
-
-- Gitaly Cluster provides fault tolerance for data storage and is invisible to the user. Users are
-  not aware when Gitaly Cluster is used.
-- Geo provides [replication](../geo/index.md) and [disaster recovery](../geo/disaster_recovery/index.md) for
-  an entire instance of GitLab. Users know when they are using Geo for
-  [replication](../geo/index.md). Geo [replicates multiple data types](../geo/replication/datatypes.md#limitations-on-replicationverification),
-  including Git data.
-
-The following table outlines the major differences between Gitaly Cluster and Geo:
-
-| Tool           | Nodes    | Locations | Latency tolerance                                                                                     | Failover                                                                    | Consistency                           | Provides redundancy for |
-|:---------------|:---------|:----------|:------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------|:--------------------------------------|:------------------------|
-| Gitaly Cluster | Multiple | Single    | [Less than 1 second, ideally single-digit milliseconds](praefect.md#network-latency-and-connectivity) | [Automatic](praefect.md#automatic-failover-and-primary-election-strategies) | [Strong](index.md#strong-consistency) | Data storage in Git     |
-| Geo            | Multiple | Multiple  | Up to one minute                                                                                      | [Manual](../geo/disaster_recovery/index.md)                                 | Eventual                              | Entire GitLab instance  |
-
-For more information, see:
-
-- Geo [use cases](../geo/index.md#use-cases).
-- Geo [architecture](../geo/index.md#architecture).
-
-## Are there instructions for migrating to Gitaly Cluster?
-
-Yes! For more information, see [Migrating to Gitaly Cluster](index.md#migrating-to-gitaly-cluster).
-
-## What are some repository storage recommendations?
-
-The size of the required storage can vary between instances and depends on the set
-[replication factor](index.md#replication-factor). You might want to include implementing
-repository storage redundancy.
-
-For a replication factor:
-
-- Of `1`: NFS, Gitaly, and Gitaly Cluster have roughly the same storage requirements.
-- More than `1`: The amount of required storage is `used space * replication factor`. `used space`
-  should include any planned future growth.
-
-## What are some Praefect database storage requirements?
-
-The requirements are relatively low because the database contains only metadata of:
-
-- Where repositories are located.
-- Some queued work.
-
-It depends on the number of repositories, but a useful minimum is 5-10 GB, similar to the main
-GitLab application database.
-
-## Can the GitLab application database and the Praefect database be on the same servers?
-
-Yes, however Praefect should have it's own database server when using Omnibus GitLab PostgreSQL. If
-there is a failover, Praefect isn't aware and starts to fail as the database it's trying to use would
-either:
-
-- Be unavailable.
-- In read-only mode.
-
-A future solution may allow for Praefect and Omnibus GitLab databases on the same PostgreSQL server.
-For more information, see the relevant:
-
-- [Omnibus GitLab issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5919).
-- [Gitaly issue](https://gitlab.com/gitlab-org/gitaly/-/issues/3398).
-
-## Is PgBouncer required for the Praefect database?
-
-No, because the number of connections Praefect makes is low. You can use the same PgBouncer instance
-for both the GitLab application database and the Praefect database if you wish.
-
-## Are there any special considerations for Gitaly Cluster when PostgreSQL is upgraded?
-
-There are no special requirements. Gitaly Cluster requires PostgreSQL version 11 or later.
-
-## Praefect database tables are empty?
-
-These tables are created per the [specific configuration section](praefect.md#postgresql).
-
-If you find you have an empty Praefect database table, see the
-[relevant troubleshooting section](troubleshooting.md#relation-does-not-exist-errors).
+This document was moved to [another location](index.md).