Esta nota es una anterior publicada en este sitio relacionada con el uso de la base de datos de MySQL por parte de GitHub. Esto te ayudará a ver la importancia de un curso de MySQL. Si quieres leerla, puedes dar clic en este enlace. Ahora continuamos con el tema. 

Anteriormente, GitHub utilizaba DNS y VIP para el descubrimiento del nodo maestro de MySQL. Las aplicaciones cliente se conectarían a un nombre de host fijo, que DNS resolvería para apuntar a un VIP. Un VIP permite que el tráfico sea enrutado a diferentes hosts para proporcionar movilidad sin atarlo a un solo host. El VIP siempre sería propiedad del nodo maestro actual. 

Sin embargo, hubo problemas potenciales con el proceso de adquisición y liberación de VIP durante los eventos de conmutación por error, incluidas las situaciones de cerebro dividido. Cuando esto sucede, dos hosts diferentes pueden tener el mismo VIP y el tráfico se puede enrutar al equivocado. Además, deben ocurrir cambios en el DNS para manejar un nodo maestro que se encuentra en un centro de datos diferente, y esto puede demorar en propagarse debido al almacenamiento en caché de DNS en los clientes.

La última configuración en GitHub incluye el kit de herramientas Orchestrator, Consul for service discovery, además de GitHub Load Balancer. En esta arquitectura, cuando una aplicación cliente busca la IP del maestro en el DNS a través de su nombre, se resuelve a través de Anycast. La ventaja de utilizar Anycast es que, si bien el nombre se resuelve en la misma dirección IP en todos los centros de datos, el tráfico del cliente a esa IP se enrutará al maestro más cercano. El maestro más cercano es el que está ubicado en el mismo centro de datos. Este enrutamiento está a cargo de GLB, que conoce los backends maestros activos actuales de MySQL.

Además de MySQL también puedes aprender a dominar .NET Core, para lo que té será útil tomar un curso de C# y un curso de visual basic.