Belastingsverdeling verhoogt de systeemprestaties, vooral vanuit het oogpunt van de toepassing, waardoor meerdere computers dezelfde gegevens kunnen verwerken. Het werkt zodanig dat de belasting wordt verdeeld over clientquery's naar replicaknooppunten naast het primaire of hoofdknooppunt, terwijl databasewijzigingen alleen naar het hoofdknooppunt worden geleid. Alle wijzigingen aan het hoofdknooppunt worden vervolgens doorgegeven aan elke replica met behulp van PostgreSQL Streaming Replication.
Hoe kunnen load balancers PostgreSQL beïnvloeden?
Het gebruik van load balancing zorgt ervoor dat clienttoepassingen verbinding maken met de load balancing-server en dat de gestarte verbindingen worden gedistribueerd naar de beschikbare PostgreSQL-knooppunten, afhankelijk van het type queryverzoeken. Dit helpt de uitstaande belasting van een bepaalde PostgreSQL-server te benadrukken en bevordert een parallelle verdeling van de belasting tussen de beschikbare knooppunten binnen het cluster.
Met PostgreSQL zijn er al een handvol bestaande oplossingen om dit te laten werken. Deze oplossingen kunnen naadloos werken of load balancing kan werken met de huidige topologie - met primaire en stand-by nodes - maar load balancing wordt geïmplementeerd in de applicatielaag zelf. Load balancing staat voor uitdagingen met synchronisatieproblemen, wat de fundamentele moeilijkheid is voor servers die samenwerken. Omdat er niet één oplossing is die de impact van het synchronisatieprobleem voor alle use-cases elimineert, zijn er meerdere oplossingen. Elke oplossing pakt dit probleem op een andere manier aan en minimaliseert de impact voor een specifieke werklast.
In deze blog zullen we deze load balancers bekijken door ze te vergelijken en te zien hoe gunstig het is voor uw PostgreSQL-workload.
HAProxy-taakverdeling voor PostgreSQL
HAProxy is een gebeurtenisgestuurde, niet-blokkerende engine die een proxy combineert met een zeer snelle I/O-laag en een op prioriteiten gebaseerde, multi-threaded planner. Omdat het is ontworpen met een doel voor het doorsturen van gegevens in gedachten, is de architectuur ontworpen om te werken in een lichtgewicht proces dat is geoptimaliseerd om gegevens zo snel mogelijk te verplaatsen met zo min mogelijk bewerkingen. Het richt zich op het optimaliseren van de CPU-cache-efficiëntie door verbindingen zo lang mogelijk op dezelfde CPU te houden. Als zodanig implementeert het een gelaagd model met bypass-mechanismen op elk niveau, zodat gegevens niet naar hogere niveaus gaan, tenzij dat nodig is. Het grootste deel van de verwerking wordt uitgevoerd in de kernel. HAProxy doet zijn best om de kernel te helpen het werk zo snel mogelijk te doen door enkele hints te geven of door bepaalde operaties te vermijden wanneer het vermoedt dat ze later gegroepeerd zouden kunnen worden. Als gevolg hiervan laten typische cijfers zien dat 15% van de verwerkingstijd wordt besteed in HAProxy versus 85% in de kernel in TCP- of HTTP-afsluitmodus, en ongeveer 30% voor HAProxy versus 70% voor de kernel in HTTP-keep-alive-modus.
HAProxy heeft ook extra functies voor taakverdeling. De TCP-proxyfunctie stelt ons bijvoorbeeld in staat om deze te gebruiken voor databaseverbindingen, speciaal voor PostgreSQL met behulp van de ingebouwde ondersteuning voor controleservices. Ook al is er ondersteuning voor databaseservices, deze voldoet niet aan de gewenste statuscontrole, vooral niet voor een replicatietype cluster. De standaardbenadering bij het inzetten voor productie is om TCP-controle te gebruiken en vervolgens afhankelijk te zijn van xinetd met HAProxy.
Voordelen van het gebruik van HAProxy voor PostgreSQL
Het beste van HAProxy is dat het lichtgewicht, gemakkelijk te configureren en te gebruiken is, en het doet zijn werk zoals verwacht. Het gebruik van HAProxy bovenop een PostgreSQL-cluster is meerdere keren geïmplementeerd en ingezet door grote organisaties naar verschillende KMO's/MKB's voor hun productiegebruik. Het is al lang bewezen voor productie en hoge werkbelasting, niet alleen voor databases, maar zelfs voor andere netwerkdiensten zoals webapplicaties of voor geo-load balancing (verkeer verdelen over meerdere datacenters). Met HAProxy bovenop PostgreSQL, kunnen gebruikers reacties vertragen of beperken om de belasting te parallelliseren en correct te verdelen over alle beschikbare knooppunten in het cluster. Het ingebouwde mechanisme met HAProxy stelt de gebruiker ook in staat om hoge beschikbaarheid naadloos in te stellen en gemakkelijker te schalen als belasting nodig is en single point of failure (SPOF) te voorkomen.
Nadelen van het gebruik van HAProxy voor PostgreSQL
HAProxy biedt geen filtering van zoekopdrachten en evenmin analyse van zoekopdrachten om het type instructies te identificeren dat wordt aangevraagd. Het ontbreekt aan de mogelijkheid om een lees-/schrijfsplitsing op een enkele poort uit te voeren. Voor het instellen van een load balancer bovenop HAProxy moet u op zijn minst verschillende poorten instellen voor uw schrijfbewerkingen en verschillende voor uw leesbewerkingen. Dit vereist toepassingswijzigingen om aan uw behoeften te voldoen.
HAProxy biedt ook een zeer eenvoudige functie-ondersteuning met PostgreSQL voor gezondheidscontrole, maar dit bepaalt alleen of het knooppunt actief is of niet, alsof het gewoon het knooppunt pingt en wacht op een teruggestuurde reactie. Het identificeert niet welke rol een knooppunt probeert om de gevraagde verbindingen van de client naar het gewenste knooppunt door te sturen. Daarom begrijpt het niet of geen functie in HAProxy om de replicatietopologie te begrijpen. Hoewel een gebruiker afzonderlijke listeners kan maken op basis van verschillende poorten, voegt het toch wijzigingen aan de toepassing toe om te voldoen aan de behoeften van de taakverdeling. Dit betekent dat ofwel het gebruik van een extern script met xinetd de oplossing kan zijn om aan de vereisten te voldoen. Toch is het niet geïntegreerd in HAProxy en kan het vatbaar zijn voor menselijke fouten.
Als één knooppunt of groep knooppunten in de onderhoudsmodus moet worden geplaatst, moet u ook wijzigingen aanbrengen in uw HAProxy, anders kan dit catastrofaal zijn.
Pgpool-II voor taakverdeling van uw PostgreSQL
Pgpool-II is een open-source software en wordt omarmd door de enorme PostgreSQL-gemeenschap voor het implementeren van taakverdeling en het gebruiken hiervan om als hun middleware op te treden van de applicatie tot aan de proxylaag, en verdeelt vervolgens de belasting nadat het het type verzoek per query of databaseverbinding volledig heeft geanalyseerd. Pgpool-II bestaat al zo lang sinds 2003, dat oorspronkelijk Pgpool heette totdat het in 2006 Pgpool-II werd, wat dient als een bewijs van een zeer stabiele proxy-tool, niet alleen voor taakverdeling, maar ook tal van coole functies .
Pgpool-II staat bekend als het Zwitserse zakmes voor PostgreSQL en is een proxy-software die tussen PostgreSQL-servers en een PostgreSQL-databaseclient zit. Het basisidee van PgPool-II is dat het zich op de client bevindt, waarna leesquery's moeten worden afgeleverd bij de standby-knooppunten, terwijl het schrijven of wijzigen rechtstreeks naar de primaire gaat. Het is een zeer intelligente oplossing voor taakverdeling die niet alleen de taakverdeling uitvoert, maar ook een hoge beschikbaarheid ondersteunt en pooling van verbindingen biedt. Het intelligente mechanisme maakt het mogelijk om de belasting tussen masters en slaves te verdelen. Schrijfbewerkingen worden dus naar de master geladen, terwijl leesbewerkingen worden doorgestuurd naar de beschikbare alleen-lezen servers, die uw zogenaamd hot standby-knooppunten zijn. Pgpool-II biedt ook logische replicatie. Hoewel het gebruik en belang ervan is afgenomen naarmate de ingebouwde replicatie-opties verbeterden aan de PostgreSQL-serverzijde, blijft dit nog steeds een waardevolle optie voor oudere versies van PostgreSQL. Bovendien biedt het ook pooling van verbindingen.
Pgpool-II heeft een meer betrokken architectuur dan PgBouncer om alle functies te ondersteunen. Aangezien beide pooling van verbindingen ondersteunen, heeft de laatste geen functies voor taakverdeling.
Pgpool-II kan meerdere PostgreSQL-servers beheren. Het gebruik van de replicatiefunctie maakt het mogelijk om een realtime back-up te maken op 2 of meer fysieke schijven, zodat de service kan doorgaan zonder servers te stoppen in het geval van een schijfstoring. Omdat Pgpool-II ook geschikt is voor het poolen van verbindingen, kan het een limiet bieden aan de overschrijding van verbindingen. Er is een limiet op het maximale aantal gelijktijdige verbindingen met PostgreSQL en verbindingen worden na zoveel verbindingen afgewezen. Het instellen van het maximale aantal verbindingen verhoogt echter het verbruik van bronnen en beïnvloedt de systeemprestaties. pgpool-II heeft ook een limiet voor het maximale aantal verbindingen, maar extra verbindingen worden in de wachtrij geplaatst in plaats van onmiddellijk een fout te retourneren.
Bij taakverdeling:als een database wordt gerepliceerd, levert het uitvoeren van een SELECT-query op een willekeurige server hetzelfde resultaat op. pgpool-II maakt gebruik van de replicatiefunctie om de belasting van elke PostgreSQL-server te verminderen door SELECT-query's over meerdere servers te verdelen, waardoor de algehele doorvoer van het systeem wordt verbeterd. In het beste geval verbeteren de prestaties evenredig met het aantal PostgreSQL-servers. Load balance werkt het beste in een situatie waarin veel gebruikers veel zoekopdrachten tegelijk uitvoeren.
Met behulp van de parallelle query-functie kunnen gegevens worden verdeeld over meerdere servers, zodat een query tegelijkertijd op alle servers kan worden uitgevoerd om de algehele uitvoeringstijd te verkorten. Parallel zoeken werkt het beste bij het doorzoeken van grootschalige gegevens.
Voordelen van het gebruik van Pgpool voor PostgreSQL
Het is een type software met veel functies, niet alleen voor taakverdeling. De kernfuncties en ondersteuning van deze tool zijn zeer on-demand en bieden pooling van verbindingen, een alternatieve go PgBouncer, native replicatie, online herstel, in-memory querycaching, automatische failover en hoge beschikbaarheid met zijn subproces met behulp van watchdog. Deze tool is al zo oud en wordt voortdurend massaal ondersteund door de PostgreSQL-gemeenschap, dus het oplossen van problemen kan niet moeilijk zijn om hulp te zoeken. De documentatie is hier je vriend als je vragen zoekt, maar het zoeken naar hulp in de gemeenschap is niet moeilijk, en het feit dat deze tool een open source is, dus je kunt deze vrij gebruiken zolang je voldoet aan de BSD-licentie.
Pgpool-II heeft ook SQL-parser. Dit betekent dat het de SQL's nauwkeurig kan ontleden en de query kan herschrijven. Hierdoor kan Pgpool-II het parallellisme versterken, afhankelijk van het vraagverzoek.
Nadelen van het gebruik van Pgpool voor PostgreSQL
Pgpool-II biedt geen STONITH (schiet de andere knoop in het hoofd) die een knooppuntafrasteringsmechanisme biedt. Als de PostgreSQL-server uitvalt, blijft de service beschikbaar. Pgpool-II kan ook het single point of failure (SPOF) zijn. Zodra het knooppunt uitvalt, stopt de connectiviteit en beschikbaarheid van uw database vanaf dat punt. Hoewel dit kan worden opgelost door redundantie met Pgpool-II te hebben en watchdog te moeten gebruiken om meerdere Pgpool-II-knooppunten te coördineren, voegt dat extra werk toe.
Voor pooling van verbindingen, voor degenen die zich alleen richten op pooling van verbindingen, is Pgpool-II helaas niet zo goed in pooling van verbindingen, vooral voor een klein aantal klanten. Omdat elk onderliggend proces zijn eigen pool heeft en er geen manier is om te bepalen welke client verbinding maakt met welk onderliggend proces, wordt er teveel aan geluk overgelaten als het gaat om het hergebruik van verbindingen.
JDBC-stuurprogramma gebruiken voor taakverdeling van uw PostgreSQL
Java Database Connectivity (JDBC) is een Application Programming Interface (API) voor de programmeertaal Java, die definieert hoe een client toegang kan krijgen tot een database. Het maakt deel uit van het Java Standard Edition-platform en biedt methoden om gegevens in een database op te vragen en bij te werken, en is gericht op relationele databases.
PostgreSQL JDBC Driver (kortweg PgJDBC) stelt Java-programma's in staat verbinding te maken met een PostgreSQL-database met behulp van standaard, database-onafhankelijke Java-code. Is een open source JDBC-stuurprogramma geschreven in Pure Java (Type 4) en communiceert in het PostgreSQL-native netwerkprotocol. Hierdoor is de bestuurder platformonafhankelijk; eenmaal gecompileerd, kan het stuurprogramma op elk systeem worden gebruikt.
Het is niet vergelijkbaar met oplossingen voor taakverdeling die we eerder hebben aangegeven. Daarom is deze tool uw API voor de applicatieprogrammeerinterface waarmee u verbinding kunt maken vanuit uw applicatie voor welk type programmeertaal dit ook is geschreven dat JDBC ondersteunt of op zijn minst een adapter heeft om verbinding te maken met JDBC. Aan de andere kant is het gunstiger met Java-toepassingen.
De taakverdeling met JDBC is behoorlijk naïef, maar kan het werk goed doen. Voorzien van de verbindingsparameters die het load balancing-mechanisme kunnen activeren dat deze tool te bieden heeft,
- targetServerType - staat het openen van verbindingen toe naar alleen servers met de vereiste status/rol in overeenstemming met de bepalende factor voor de PostgreSQL-servers. De toegestane waarden zijn any, primary, master (verouderd), slave (verouderd), secundair, preferSlave en preferSecondary. Status of rol wordt bepaald door te kijken of de server schrijfbewerkingen toestaat of niet.
- hostRecheckSeconds - bepaalt hoe lang in seconden de kennis over een hoststatus wordt opgeslagen in de JVM-brede globale cache. De standaardwaarde is 10 seconden.
- loadBalanceHosts – hiermee kunt u configureren of de eerste host altijd wordt geprobeerd (indien ingesteld op false) of dat verbindingen willekeurig worden gekozen (indien ingesteld op true)
Dus met loadBalanceHosts die een booleaanse waarde accepteert. loadBalanceHosts is uitgeschakeld tijdens de standaardmodus en hosts zijn verbonden in de aangegeven volgorde. Indien ingeschakeld worden hosts willekeurig gekozen uit de reeks geschikte kandidaten. De basissyntaxis bij het verbinden met de database met behulp van jdbc is als volgt,
- jdbc:postgresql:database
- jdbc:postgresql:/
- jdbc:postgresql://host/database
- jdbc:postgresql://host/
- jdbc:postgresql://host:port/database
- jdbc:postgresql://host:port/
Aangezien loadBalanceHosts en verbinding meerdere hosts ontvangen die zijn geconfigureerd zoals hieronder,
jdbc:postgresql://host1:port1,host2:port2,host3:port3/databaseHierdoor kan JDBC willekeurig kiezen uit de reeks geschikte kandidaten.
Voordelen van het gebruik van PgJDBC voor PostgreSQL
Middleware of proxy is niet nodig als load balancers. Dit proces voegt meer prestatieverbetering toe aan de frontend van de applicatie, omdat er geen extra laag is voor elk verzoek dat moet worden doorgegeven. Als u applicaties gereed hebt en geschreven bent om interfaces met JDBC te ondersteunen, kan dit voordelig zijn en als u niet meer middleware nodig heeft, vooral als uw budget krap is en u alleen de processen wilt beperken die zijn toegewijd aan het enige doel en de functie ervan. In tegenstelling tot toepassingen met veel verkeer en toepassingen met grote vraag, kan het zijn dat proxyservers als uw load balancers optreden en dat er extra bronnen nodig zijn om hoge verbindingsverzoeken correct af te handelen, wat ook vraagt om CPU- en geheugenverwerking.
Nadelen van het gebruik van PgJDBC voor PostgreSQL
Je moet je code instellen voor elke verbinding die moet worden aangevraagd. Het is een interface voor het programmeren van toepassingen, wat betekent dat er werk aan de winkel is, vooral als uw toepassing veeleisend is voor elk verzoek dat naar de juiste servers moet worden verzonden. Er is geen hoge beschikbaarheid, geen automatische schaalbaarheid en er is één storingspunt.
Hoe zit het met wrappers of tools die zijn geïmplementeerd met libpq voor taakverdeling van uw PostgreSQL?
libpq is de interface van de C-toepassingsprogrammeur naar PostgreSQL. libpq is een set bibliotheekfuncties waarmee clientprogramma's query's kunnen doorgeven aan de PostgreSQL-backendserver en de resultaten van deze query's kunnen ontvangen.
libpq is ook de onderliggende engine voor verschillende andere PostgreSQL-toepassingsinterfaces, waaronder die geschreven voor C++, PHP, Perl, Python, Tcl, Swift en ECPG. Dus sommige aspecten van het gedrag van libpq zullen belangrijk voor je zijn als je een van die pakketten gebruikt.
libpq automatiseert de taakverdeling niet en moet niet worden beschouwd als een hulpmiddel voor oplossingen voor taakverdeling. Toch is het in staat om verbinding te maken met de volgende beschikbare servers als de vorige servers die voor verbinding worden vermeld, falen. Als u bijvoorbeeld twee beschikbare hot-standby-knooppunten hebt en het eerste knooppunt te druk is en niet reageert op de bijbehorende time-outwaarde, maakt het verbinding met het volgende beschikbare knooppunt in de gegeven verbinding. Het is afhankelijk van het type sessieattributen dat u hebt opgegeven. Dit is afhankelijk van de parameter target_session_attrs.
De parameter target_session_attrs accepteert lees-schrijfwaarden en elke waarde die de standaardwaarde is als deze niet is opgegeven. Wat de parameter target_session_attrs doet, is dat, indien ingesteld op lezen-schrijven, alleen een verbinding wordt geaccepteerd waarin lees-schrijftransacties worden geaccepteerd tijdens de verbinding. De query SHOW transaction_read_only wordt verzonden bij elke succesvolle verbinding. Als het resultaat is ingeschakeld, wordt de verbinding gesloten, wat betekent dat het knooppunt wordt geïdentificeerd als een replica of geen schrijfbewerkingen verwerkt. Als er meerdere hosts zijn opgegeven in de verbindingsreeks, worden alle resterende servers geprobeerd alsof de verbindingspoging is mislukt. De standaardwaarde van deze parameter, any, wat betekent dat alle verbindingen acceptabel zijn. Hoewel vertrouwen met target_session_attrs niet genoeg is voor taakverdeling, kunt u misschien een round-robin-mode simuleren. Zie mijn voorbeeld C-code hieronder met libpq,
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <unistd.h>
#include <libpq-fe.h>
const char* _getRoundRobinConn() {
char* h[2];
h[0] = "dbname=node40 host=192.168.30.40,192.168.30.50";
h[1] = "dbname=node50 host=192.168.30.50,192.168.30.40";
time_t t;
//srand((unsigned)time(&t));
sleep(1.85);
srand((unsigned)time(NULL));
return h[rand() % 2];
}
void
_connect()
{
PGconn *conn;
PGresult *res;
char strConn[120];
snprintf(strConn, 1000, "user=dbapgadmin password=dbapgadmin %s target_session_attrs=any", _getRoundRobinConn());
//printf("\nstrConn value is: %s\n", strConn);
conn = PQconnectdb(strConn);
res = PQexec(conn, "SELECT current_database(), inet_client_addr();");
if ( PQresultStatus(res)==PGRES_TUPLES_OK )
{
printf("current_database = %s on %s\n", PQgetvalue(res, 0, 0),
PQhost(conn));
} else {
printf("\nFailed... Message Code is: %d\n", PQresultStatus(res));
}
PQclear(res);
PQfinish(conn);
}
int main(void)
{
int i;
for (i=0 ; i<5 ; i++)
_connect();
return 0;
}Het resultaat onthult,
[email protected]:/home/vagrant# gcc -I/usr/include/postgresql -L/usr/lib/postgresql/12/lib libpq_conn.c -lpq -o libpq_conn; ./libpq_conn
current_database = node40 on 192.168.30.40
current_database = node40 on 192.168.30.40
current_database = node50 on 192.168.30.50
current_database = node40 on 192.168.30.40
current_database = node50 on 192.168.30.50Houd er rekening mee dat, als knooppunt .40 (het primaire knooppunt) uitvalt, dit altijd de verbinding naar de .50 zal leiden, zolang uw target_session_attrs-waarde gelijk is.
In dat geval kun je eenvoudig je eigen vrij maken met behulp van libpq. Hoewel het proces van vertrouwen op libpq en/of zijn wrappers gewoon te ruw is om te zeggen dat dit het gewenste mechanisme voor taakverdeling kan bieden met een gelijkmatige verdeling naar de knooppunten die je hebt. Deze aanpak en codering kunnen absoluut worden verbeterd, maar de gedachte is dat dit gratis en open source is, en dat je kunt coderen zonder te vertrouwen op middleware en vrijelijk de manier waarop je taakverdeling werkt, kunt ontwerpen.
Voordelen van het gebruik van libpq voor PostgresQL
libpq-bibliotheek is de applicatie-interface van de programmeur die is gebouwd in de programmeertaal C. Toch is de bibliotheek in verschillende talen geïmplementeerd als wrappers, zodat programmeurs kunnen communiceren met de PostgreSQL-database in hun favoriete talen. U kunt direct uw eigen toepassing maken met uw favoriete talen en vervolgens een lijst maken van de servers die u van plan bent te verzenden, maar pas na de andere, als een storing of time-out uw belasting naar de beschikbare knooppunten stuurt die u van plan bent om de belasting te verdelen. Het is beschikbaar in talen zoals Python, Perl, PHP, Ruby, Tcl of Rust.
Nadelen van het gebruik van libpq voor PostgresQL
De implementatie van load-parallellisme is niet perfect en je moet je eigen load-balancing-mechanisme per code schrijven. Er is geen configuratie die u kunt gebruiken of aanpassen, omdat het alleen een programmeerinterface is voor de PostgreSQL-database met behulp van target_session_attrs param. Dat betekent dat u bij het samenstellen van een databaseverbinding een reeks leesverbindingen naar uw replica/standby-knooppunten moet hebben en vervolgens query's moet schrijven die naar de schrijver of het primaire knooppunt in uw code gaan, of het nu in uw toepassing is of u moet maken uw eigen API om de load balancing-oplossing te beheren.
Het gebruik van deze aanpak vereist absoluut geen middleware vanuit het front-end applicatieperspectief naar de database als backend. Dat is natuurlijk licht van gewicht, maar wanneer u de lijst met servers verzendt bij verbinding, betekent dit niet dat de belasting wordt begrepen en gelijkmatig wordt verzonden, tenzij u uw code voor deze aanpak moet toevoegen. Dit maakt het alleen maar lastiger, maar er zijn al bestaande oplossingen, dus waarom het wiel opnieuw uitvinden?
Conclusie
Het implementeren van uw load balancers met PostgreSQL kan veeleisend zijn, maar hangt af van het type applicatie en de kosten waarmee u te maken heeft. Soms, voor een hoge belastingsvraag, vereist het de noodzaak van middleware die als een proxy fungeert om de belasting correct te verdelen en ook toezicht houdt op de knooppuntstatus of -gezondheid. Aan de andere kant kan het serverbronnen vereisen, ofwel moet het op een speciale server worden uitgevoerd of vereist het extra CPU en geheugen om aan de behoeften te voldoen en dit brengt kosten met zich mee. Daarom is er ook een eenvoudige maar tijdrovende manier, maar biedt de verdeling van de belasting naar de beschikbare servers die u al heeft. Maar het vereist programmeervaardigheden en begrip van de functionaliteit van de API.