Hybridmiljöer, där en del av databasinfrastrukturen är lokaliserad och en del av den finns i ett offentligt moln är inte ovanliga. Det kan finnas olika anledningar att använda en sådan installation - skalbarhet, flexibilitet, hög tillgänglighet, katastrofåterställning. Hur implementerar man denna inställning på ett korrekt sätt? Detta kan vara utmanande eftersom du måste tänka på flera pusselbitar som måste passa ihop. Den här bloggen är avsedd att ge dig lite insikter i hur en sådan konfiguration kan se ut.
Anslutning
Vi går inte in på detaljer här eftersom det finns många sätt att konfigurera anslutning mellan din lokala installation och det offentliga molnet. Det beror på vilken infrastruktur du har på plats, vilket offentliga moln du vill använda och många andra faktorer. Mängden alternativ kan börja med BGP-aktiverade routrar, via hårdvaru-VPN, mjukvaru-VPN som hamnar på SSH-tunnlar som ett sätt att tillfälligt ansluta ditt nätverk till instanserna i ett offentligt moln. Vad som är viktigt, vad du än ska göra, bör det slutliga resultatet vara fullständig och transparent anslutning från ditt lokala nätverk till instanserna som finns i det offentliga molnet.
Hög tillgänglighet
MySQL-replikering är ett utmärkt sätt att bygga högt tillgängliga system men det kommer med betydande begränsningar. Det viktigaste att tänka på är författaren - du kan bara ha ett ställe att skicka dina texter till - mästaren. Oavsett hur du vill designa hela miljön måste du noggrant överväga placeringen av mästaren. Troligtvis vill du att det ska vara en del av miljön som innehåller applikationsvärdarna. Låt oss överväga följande inställning:
Vi har en lokal installation med tre MySQL-noder och två extra slavar belägen i det offentliga molnet, som fungerar som ett katastrofåterställningsmedel för företaget, är det helt klart att den skrivbara noden ska samlokaliseras med applikationsvärdarna i den privata delen av molnet. Vi vill hålla latensen så låg som möjligt för de anslutningar som betyder mest.
Den här typen av design fokuserar på tillgängligheten för databaserna - om noderna som finns på prem inte kommer att vara tillgängliga kan applikationsvärdar kanske ansluta till fjärrdelen av installationen - databasnoder finns i det offentliga molnet. Helst skulle du använda någon sorts proxy för detta - ProxySQL är en av lösningarna som kan spåra topologin och konfigurera om efter behov baserat på den befintliga replikeringskedjan.
Om du vill överväga mer av en aktiv-aktiv installation där du har applikationsnoder över både privata och offentliga, måste du göra några kompromisser eftersom skrivningarna måste överföras via WAN, från det offentliga till det privata molnet (eller vice versa, om din huvudsakliga plats där du verkar i det offentliga molnet).
Återigen, ProxySQL är den valda proxyn. Vad som är bra, ProxySQL kan konfigureras som ett ProxySQL-kluster, vilket säkerställer att konfigurationsändringarna som införs i den ena noden kommer att replikeras över återstående ProxySQL-noder.
Fejlhantering
Låt oss överväga ett par felscenarier. Före allt måste vi komma ihåg att MySQL asynkron replikering inte är klustermedveten, därför är nätverksuppdelningen något som måste hanteras manuellt - det kommer att vara upp till användaren att fatta beslutet och dra växeln för att främja en av slavarna i den miljö som finns tillgänglig. Det är också upp till användaren att se till att miljön som har förlorat nätverksanslutningen kommer att bete sig som den ska och inte fortsätta att fungera.
Om den privata delen av molnet blir otillgänglig, som vi nämnde tidigare, kommer manuell åtgärd att krävas för att främja en av slavarna att bli en ny mästare. Då kommer alla återstående webbapplikationsservrar som finns i det offentliga molnet, med hjälp av lokal ProxySQL, att få sin trafik omdirigerad till den nya mastern och alla återstående slavar. Å andra sidan, med tanke på att vi förlorade tre av fem MySQL-noder, vill vi skala ut den offentliga molnkonfigurationen - ClusterControl kan hjälpa dig att effektivt lägga till ytterligare noder till ditt kluster.
Ett annat scenario kan vara att skribenten har kraschat medan anslutningen mellan vår lokala installation och det offentliga molnet fungerar bra.
I ett sådant scenario vill vi befordra en av slavarna att bli en ny mästare. Beroende på kraven kan vi också vilja att den nya mastern ska främjas mellan noder i en given del av miljön. ClusterControl har förmågan att vitlista eller svartlista noderna för failover, vilket säkerställer att du har full kontroll över failover-processen och att du kan välja vilka noder som ska betraktas som kandidater för en ny master och i vilken ordning.
Vi hoppas att den här bloggen gav dig en uppfattning om hur hybridmolnkonfigurationen för MySQL-replikering fungerar och hur den kan skydda dig i händelse av databas- eller nätverksfel.