Kun WordPress-sivuston liikenne kasvaa merkittävästi, tietokanta muuttuu usein ensimmäiseksi pullonkaulaksi. Vaikka välimuistit, CDN:t ja Redis vähentävät kuormaa, lopulta MySQL- tai MariaDB-palvelin joutuu käsittelemään suuren määrän kyselyitä. Tässä vaiheessa database replication ja read/write split voivat tarjota merkittävän suorituskyky- ja skaalautuvuushyödyn.
Read/write split tarkoittaa käytännössä sitä, että kirjoitukset ohjataan yhteen tietokantaan ja lukukyselyt useille replikoille. Näin kuorma jakautuu tehokkaammin ja järjestelmä pystyy palvelemaan huomattavasti enemmän käyttäjiä ilman yhtä massiivista tietokantapalvelinta.
Mitä database replication tarkoittaa?
Replikoinnissa yksi tietokanta toimii pääpalvelimena (primary) ja yksi tai useampi palvelin toimii replikoina (replica).
Arkkitehtuuri:
WordPress
↓
Primary Database
↓
Replication
↓
Replica 1
Replica 2
Replica 3
Primary vastaanottaa kaikki kirjoitukset.
Replikat vastaanottavat kopion datasta ja palvelevat lukukyselyitä.
Miksi replikointia tarvitaan?
Yhdessä tietokannassa kaikki tapahtuu samassa paikassa:
- SELECT
- INSERT
- UPDATE
- DELETE
Kun liikenne kasvaa:
- CPU kuormittuu
- levy-I/O kasvaa
- lukukyselyt hidastuvat
- vasteajat kasvavat
Read replica -arkkitehtuurissa:
SELECT → Replica
INSERT → Primary
UPDATE → Primary
DELETE → Primary
Lukukuorma jakautuu useille palvelimille.
WordPress ja tietokantakuorma
Tyypillinen WordPress-sivu tekee:
- options-haut
- post-kyselyt
- metadatahaut
- käyttäjähaut
- taksonomiakyselyt
Suurin osa näistä on:
SELECT
Juuri siksi read replica -arkkitehtuuri toimii hyvin.
Perinteinen tietokanta-arkkitehtuuri
WordPress
↓
Single MySQL Server
Yksinkertainen mutta rajallinen.
Kaikki kuorma osuu yhteen palvelimeen.
Read/Write Split -arkkitehtuuri
WordPress
↓
Database Router
↓
Primary Database
↓
Read Replicas
Kirjoitukset menevät primaryyn.
Luvut voidaan jakaa replikoille.
HyperDB WordPressissä
Yksi tunnetuimmista ratkaisuista on HyperDB.
Se mahdollistaa:
- read/write splitin
- useita tietokantoja
- failoverin
- replikoinnin hallinnan
Esimerkki:
$wpdb->add_database([
'host' => 'primary-db',
'write' => 1,
'read' => 1
]);
Replica:
$wpdb->add_database([
'host' => 'replica-db',
'write' => 0,
'read' => 1
]);
Lukukyselyiden jakaminen
Tyypillinen flow:
WP_Query
↓
SELECT
↓
Replica
Tämä vähentää primaryn kuormaa merkittävästi.
Kirjoitusten käsittely
Kaikki muutokset menevät primaryyn:
INSERT
UPDATE
DELETE
↓
Primary
Näin data pysyy eheänä.
Replication lag
Yksi tärkeimmistä haasteista.
Tilanne:
UPDATE
↓
Primary
↓
Replication
↓
Replica
Replica ei välttämättä päivity välittömästi.
Viive voi olla:
- millisekunteja
- sekunteja
- pahimmillaan minuutteja
Read-after-write ongelma
Esimerkki:
User updates profile
↓
Data written
↓
Immediate read
↓
Replica not updated yet
Käyttäjä näkee vanhaa dataa.
Ratkaisu read-after-write ongelmaan
Monet järjestelmät käyttävät:
Recent writes
↓
Read from Primary
Tietyn ajan jälkeen:
Read from Replica
WooCommerce ja replication
WooCommerce vaatii erityistä huomiota.
Tilaukset:
Checkout
↓
Write
↓
Immediate read
Liian aggressiivinen read split voi aiheuttaa ongelmia.
Monet WooCommerce-ympäristöt ohjaavat kriittiset operaatiot aina primaryyn.
Redis vähentää replica-kuormaa
Arkkitehtuuri:
WordPress
↓
Redis
↓
Replica
↓
Primary
Useimmat kyselyt eivät koskaan päädy tietokantaan asti.
Failover
Jos primary kaatuu:
Primary Down
↓
Promote Replica
↓
New Primary
Tämä voidaan automatisoida.
Managed Database -ratkaisut
Pilvipalvelut tarjoavat usein valmiit replikoinnit:
- Amazon RDS
- Google Cloud SQL
- Azure Database
- MariaDB Enterprise
Näissä failover ja replication ovat usein sisäänrakennettuja.
Tietokantayhteyksien optimointi
Suuret sivustot hyötyvät:
- connection poolingista
- persistent connections -ratkaisuista
- query cachingista
Monitorointi
Seuraa:
- replication lag
- query time
- CPU usage
- IOPS
- connection count
Tärkein mittari on usein:
Replication Delay
Milloin replication kannattaa ottaa käyttöön?
Tyypillisesti kun:
- miljoonia sivulatauksia kuukaudessa
- erittäin raskaita queryjä
- paljon samanaikaisia käyttäjiä
- WooCommerce suurella liikenteellä
Pienillä sivustoilla Redis tarjoaa usein paremman hyötysuhteen.
Yleisimmät virheet
- replica lagin unohtaminen
- kaikki kyselyt replikoille
- WooCommerce ilman primary-pinnoitusta
- ei failover-suunnitelmaa
- huono monitorointi
- read-after-write ongelmien sivuuttaminen
Paras käytännön arkkitehtuuri
CDN
↓
WordPress Cluster
↓
Redis Object Cache
↓
Database Router
↓
Primary Database
↓
Read Replicas
Tässä mallissa suurin osa liikenteestä palvellaan välimuistista, ja tietokanta käsittelee vain välttämättömät kyselyt.
Yhteenveto
Database replication ja read/write split mahdollistavat WordPressin skaalautumisen huomattavasti suurempiin liikennemääriin kuin yksittäinen tietokantapalvelin. Suurin hyöty syntyy lukukyselyiden siirtämisestä replikoille samalla kun kirjoitukset pidetään keskitetysti primary-tietokannassa.
Kun ratkaisu yhdistetään Redis object cacheen, kunnolliseen monitorointiin ja replication lagin hallintaan, WordPress pystyy käsittelemään erittäin suuria käyttäjämääriä vakaasti ja tehokkaasti.