Skip to main content
Frecuentemente publicamos actualizaciones de nuestra documentación. Es posible que la traducción de esta página esté en curso. Para conocer la información más actual, visita la documentación en inglés. Si existe un problema con las traducciones en esta página, por favor infórmanos.

About geo-replication

Geo-replication on GitHub Enterprise Server uses multiple active replicas to fulfill requests from geographically distributed data centers.

Multiple active replicas can provide a shorter distance to the nearest replica. For example, an organization with offices in San Francisco, New York, and London could run the primary appliance in a datacenter near New York and two replicas in datacenters near San Francisco and London. Using geolocation-aware DNS, users can be directed to the closest server available and access repository data faster. Designating the appliance near New York as the primary helps reduce the latency between the hosts, compared to the appliance near San Francisco being the primary which has a higher latency to London.

The active replica proxies requests that it can't process itself to the primary instance. The replicas function as a point of presence terminating all SSL connections. Traffic between hosts is sent through an encrypted VPN connection, similar to a two-node high availability configuration without geo-replication.

Git requests and specific file server requests, such as LFS and file uploads, can be served directly from the replica without loading any data from the primary. Web requests are always routed to the primary, but if the replica is closer to the user the requests are faster due to the closer SSL termination.

Geo DNS, such as Amazon's Route 53 service, is required for geo-replication to work seamlessly. The hostname for the instance should resolve to the replica that is closest to the user's location.


Writing requests to the replica requires sending the data to the primary and all replicas. This means that the performance of all writes is limited by the slowest replica, although new geo-replicas can seed the majority of their data from existing co-located geo-replicas, rather than from the primary. To reduce the latency and bandwidth caused by distributed teams and large CI farms without impacting write throughput, you can configure repository caching instead. For more information, see "About repository caching."

Geo-replication will not add capacity to a GitHub Enterprise Server instance or solve performance issues related to insufficient CPU or memory resources. If the primary appliance is offline, active replicas will be unable to serve any read or write requests.

Nota: Hay un máximo de 8 réplicas de disponibilidad alta (tanto pasivas como activas/geo replicas) que se permiten para GitHub Enterprise Server.

Monitoring a geo-replication configuration

Puedes verificar la disponibilidad del GitHub Enterprise Server al controlar el código de estado que devuelve la URL https://HOSTNAME/status. Un aparato que puede servir el tráfico de usuario devolverá un código de estado de 200 (OK). Un aparato puede devolver un 503 (Servicio no disponible) por distintas razones:

  • El aparato es una réplica pasiva, como la réplica en una configuración de disponibilidad alta de dos nodos.
  • El aparato está en modo de mantenimiento.
  • El aparato es parte de una configuración de replicación geográfica, pero es una réplica inactiva.

También puedes utilizar el Tablero de resumen de replicación disponible en:


Further reading