Erre is nehéz 1-2 mondatban válaszolni, de megpróbálok. Elnézést, ha valahol keverem a Pgsql-lel. És elnézést a hosszért.
Klasszikus szerverhosztingról (IaaS) írok. PaaS, SaaS kicsit másabb.
Először is vegyük ketté: A.) béna szolgáltató, B.) profi szolgáltató
A.) Simán rápakol több ügyfelet ugyanarra a DB szerverre. Akár Mariadb, akár Postgresql, akár MSSQL, akár DB2 stb. Próbál a DB adta lehetőségeken belül limiteket beállítani. Például: connection/sec, query/hour, update/hour stb. De ezek kb. annyit érnek, mint halottnak a csók. Közös lónak túrós a háta. Mindig.
Amit még megtehetnek, hogy tényleg dedikált DB szervert raknak a feladathoz. Megfelelő mennyiségű cpu, ram területtel. Továbbá a lemezrendszer is nagy teljesítményű (akár full SSD SAN) és jól elosztott.
Mit jelent a jól elosztott? Több tablespace van, a data, index, log, temp mind külön lemeztömbre / LUN-ra / RAID tömbre / SAN storage-ra kerül. Azaz a DB fájlai más helyen tárolódnak. Egy intenzív Temp használat nem nyírja ki a többi tablespace-t, nem okoz I/O várakozást. Ezt még lehet cizellálni akár ügyfelenként is, de akkor már átlépünk a B.) verzióra.
Pár link a témában, amit most találtam:
- http://underpop.online.fr/m/mysql/manual/mysql-server-administration-us…
- https://mariadb.com/kb/en/server-system-variables/
Ha hiba / teljesítmény probléma van, akkor általában az ügyfelek elkezdenek panaszkodni. Aztán a szolgáltató meg nyomozhat, hogy vajon kinek a DB-je nyírja a rendszert. A szolgáltató részéről proaktivitás minimális.
B.) Ügyfelenként van külön DB szerver. Ügyfél által igényelt beállításokkal és paraméterekkel. Nem okoz gondot, ha egyik ügyfél OLAP, másik OLTP, harmadik DW (data warehouse) módon használja a DB-ket. Szépen hozzá lehet igazítani a használati profilok alapján. Erősen szabályozott a QoS cpu, ram, disk szinten is.
Ügyfelen belül is lehet másik DB szervert beállítani, ha a beállítások, költségek, teljesítmény igények indokolják. Elvileg egyik ügyfél / DB sem zavarhatja a másikat - nem okoz gondot, ha egyik pörgeti a lemezeket. A lemezrendszer jól elosztott és jól konfigurált. Természetesen ez a megoldás jóval drágább, mint az A.) verzió. PaaS, SaaS esetén csak ez játszik.
Klasszikus szerver upgrade - nagyon erősen zanzásítva:
Egy normális helyen van legalább dev, test, prod környezet - persze lehet mellette UAT, stage, preprod is más-más célra. Külön szerverekkel / vm-ekkel / konténerekkel. Az upgrade része, hogy az ember elolvassa az upgrade notice-t, guide-okat, elolvassa a changelogot. Ennek figyelembe vételével kockázatelemzést végez (hol bukhat el a frissítés). Van rollback planje
Majd először a dev környezetet frissíti. Elemzi a frissítés során keletkezett logokat, elemzi a monitoring rendszerből jövő adatokat, megvárja a fejlesztők visszajelzését a frissítésről.
Ha minden oké és az esetleges hibák elhárultak, akkor felkészíti a test környezetet is a frissítésre. Végigmegy ott is a lépéséken. Felírja az esetleges problémákat, megoldja - akár közösen a fejlesztőkkel. Próbál jóslást végezni, hogy a prod rendszerben mi borulhat meg, minek a teljesítménye változhat.
Majd ha minden oké a test rendszerben és felülről is rábólintanak, akkor jöhet a prod rendszer frissítése. Ha jók a folyamatok a cégnél, van CI/CD, van monitorozás, akkor - elvileg - nem szabadna a prod rendszerben nem várt hibával találkozni. Olyan simán kell mennie a frissítésnek, mint a sicc.
Lehet itt behozni devopsot, agile-t, attól még a folyamat érdemben nem változik. A legkisebb kockázatú rendszert frissítjük először, majd megyünk tovább a nagyobb kockázatúak felé. Csak akkor lépünk tovább, ha minden problémának tudjuk az okát és meg is oldottuk őket. Dokumentálunk, ahol csak lehetséges. Nem húzzuk az upgrade folyamatot hónapokig. Ideális esetben egy ilyen upgrade-nek 1-3 hét alatt le kell futnia - multinál / nehéz ügyfeleknél lehet ez hónapok kérdése is. Csak az meg szart se ér.
Hogy hogyan kell jó dev, test rendszereket építeni, mikor lesz használható, arról meg könyvet lehetne írni. Szerintem. :)