Introduzione
La configurazione classica di WordPress prevede, in linea di massima, un database MySQL ed un server a gestire il tutto in maniera unificata: col trascorrere del tempo, come abbiamo sottolineato in più occasioni, la gestione di un sito a database singolo finisce per risultare inadeguata, e può essere utile valutare scenari differenti di configurazione.Il passaggio ad un’architettura di questo tipo, in cui sostanzialmente c’è un singolo sito fatto in WordPress e più database di “appoggio”sincronizzati tra loro, è alla base della configurazione di cui parleremo oggi (e che cercheremo di descrivere nel dettaglio).
Quello che si può fare nella pratica per realizzare questo tipo di possibilità è provare ad utilizzare una configurazione scalabile, in cui si sfruttano la database replication ed un particolare plugin (HyperDB). La database replication è un meccanismo master-slave in cui non c’è più un solo database MySQL, ma almeno due – di cui il secondo ed i successivi vengono attivati ed usati all’occorrenza. Questo ovviamente comporta un comportamento di sincronizzazione del sistema, che deve mantenere allineati tutti i db con gli stessi dati per evitare perdite degli stessi, errori imprevedibili e via dicendo. Qual è il vantaggio di tutto questo? L’architettura può aiutare a migliorare le performance non tanto in scrittura quando, di fatto, in fase di lettura dello stesso, ed è peraltro estendibile a più database “clonati” da quello originale.
Partiamo dal presupposto che la tua configurazione includa due server di applicazioni WordPress con bilanciamento del carico che si connettono a un server di database MySQL separato (consulta i prerequisiti per un tutorial su come configurarlo). Non è strettamente necessario disporre di server delle applicazioni con bilanciamento del carico per seguire questo tutorial, ma il server di database MySQL dovrebbe essere separato dai server delle applicazioni.
Prerequisiti
L’architettura in questione presuppone l’uso di più VPS che comunicano tra di loro, e nello specifico configurate come segue:
- haproxy-www: un server di bilanciamento indicato come HAProxy , che farà da entry point
- wordpress-1: istanza di WordPress
- wordpress-2: istanza di WordPress duplicata
- mysql-1: istanza del database MySQL
- mysql-2: istanza duplicata di MySQL
A livello generale, il client accederà al sito mediante il server bilanciato, che poi dirotterà la richiesta su uno dei due server WP indicati e farà infine accesso al database. Le richieste di lettura saranno indirizzate a seconda delle necessità e del carico di lavoro sul server su una delle due istanze, mentre quelle di scrittura le manderemo soltanto sulla prima (che poi si auto-sincronizzerà sulla seconda).
Set Up della configurazione master-slave
Prima di poter configurare il nostro WordPress per funzionare da più server di database, dobbiamo impostare la nostra replica MySQL in modo che funzioni in automatico. Sulla VPS di mysql-2, installiamo MySQL Server:
sudo apt-get update
sudo apt-get install mysql-server
Impostiamo la password di root ed andiamo al passaggio successivo.
Configure Existing MySQL Server as a Master
Sull’istanza di mysql-1 (che sarà il master) editiamo il file di configurazione di MySQL:
sudo vi /etc/mysql/my.cnf
ed andiamo ad impostare le seguenti righe:
bind-address = mysql1private_IP
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
ovvero:
- bind-address: l’indirizzo IP della VPS mysql-1
- server-id: l’identificativo del server, in questo caso 1
- log_bin: posizione del file di log
che poi vuol dire, nella pratica:
bind-address = <span class=“highlightâ€>mysql1privateIP</span>
server-id = 1
logbin = /var/log/mysql/mysql-bin.log
Riavviamo l’istanza di MySQL:
sudo service mysql restart
Ora possiamo connetterci all’istanza via MySQL
mysql -u root -p
Inseriamo la password e poi creiamo l’utenza slave che andrà ad accedere:
CREATE USER ‘repl’@’<span class=“highlightâ€>%</span>’ IDENTIFIED BY ’<span class=“highlightâ€>repl_password</span>’;
GRANT REPLICATION SLAVE ON . TO ‘repl’@’%’;
Fare un backup di mysql-1
Sempre dalla console MySQL, diamo il seguente comando per bloccare il database in sola lettura:
FLUSH TABLES WITH READ LOCK; SET GLOBAL read_only = ON; EXIT
e poi facciamo un dump con il nome masterdump.sql:
mysqldump --lock-all-tables -u root -p --all-databases > masterdump.sql
Mediante scp possiamo inviare il file in questione sull’altra istanza, nella cartella /tmp:
scp masterdump.sql user@mysql2private_IP:/tmp
Adesso facciamo login su mysql-1:
mysql -u root -p
sblocchiamo l’istanza
SET GLOBAL read_only = OFF;
UNLOCK TABLES;
ed interroghiamo lo status scrivendo:
SHOW MASTER STATUS;
prendiamo nota dei valori di File e Position:
| File | Position | BinlogDoDB | BinlogIgnoreDB |
| mysql-bin.000001 | 408 | | |
Configurare l’istanza mysql-2
Ora vorremo importare il database master nell’istanza slave per sincronizzarli in preparazione per la replica. Su mysql-2, importiamo il dump masterdump.sql:
mysql -u root -p < /tmp/masterdump.sql
Successivamente, configureremo mysql-2 come slave di replica. Su mysql-2, modifica il file di configurazione di MySQL:
sudo vi /etc/mysql/my.cnf
Cerchiamo le seguenti due righe:
bind-address = 127.0.0.1
server-id=1
e cambiamole come segue:
bind-address = mysql2private_IP
server-id = 2
Salviamo tutto, a questo punto e riavviamo mysql:
sudo service mysql restart
Adesso rientriamo nella console del database:
mysql -u root -p
ed impostiamo i seguenti valori:
- MASTER_HOST: IP dell’istanza mysql-1
- MASTER_USER: , repl
- MASTER_PASSWORD: password per repl
- MASTERLOGFILE: Impostiamo il valore di FILE precedentemente rilevato, ovver ad es. mysql-bin.000001
- MASTERLOGPOS: Impostiamo il valore di POSITION precedentemente rilevato, ovvero nel nostro esempio con SHOW MASTER STATUS la colonna riportava 408
Per avviare l’istanza in questione, a questo punto, basta lanciare il processo con:
START SLAVE;
e per verificare lo status, cioè se effettivamente funziona:
SHOW SLAVE STATUS\GCome configurare HyperDB su WordPress
Secondo la strutturazione del database che abbiamo visto, ci sono due istanze “ombra” dello stesso database e sono destinate ad usi diversi (anche se non perfettamente distinti, in effetti):
- aggiornamenti in scrittura al db: master;
- richieste di lettura: master e slave
Possiamo fare tutto da SSH: prima di tutto ci scarichiamo il file del plugin ufficiale dal repository, e poi lo scompattiamo (in questo modo dovrà solo essere attivato dal backend di WP):
cd ~;
wget http://downloads.wordpress.org/plugin/hyperdb.zip
sudo apt-get install zip
unzip hyperdb.zip
Adesso ci dobbiamo copiare il file db-config.php nella root del sito e poi personalizzarlo a dovere:
cp ~/hyperdb/db-config.php /var/www/html/
pico /var/www/html/db-config.php
La seconda volta che vediamo l’occorrenza della stringa DB_HOST, è il db slave e dovremmo configurarla su questa falsariga:
$wpdb->adddatabase(array(
‘host’ => DBHOST,
‘user’ => DBUSER,
‘password’ => DBPASSWORD,
‘name’ => DB_NAME,
‘write’ => 0, ‘read’ => 1, ‘dataset’ => ‘global’, ‘timeout’ => 0.2, ));
La prima occorrenza nel file della variabile DB_HOST coincide con la definizione del db master, e ce ne accorgiamo dal valore di DBHOST pari al riferimento DBSLAVE1`:
‘host’ => DBSLAVE1
Adesso il DB_SLAVE_1 deve essere riferito all’interno del wp-config.php classico: andiamo a cercare il db host ed impostiamo la variabile mysql2private_IP al posto di localhost:
define(‘DBSLAVE1’, ’<span class=“highlightâ€>mysql2private_IP</span>’);
Then save and exit.
Infine, copiamo il file db.phpnella cartella wp-content , e rendiamolo in sola lettura per sicurezza:
cp ~/hyperdb/db.php /var/www/html/wp-content/
sudo chmod a-w /var/www/html/wp-content/db.php
e per sicurezza impostiamogli pure i ruoli utente corretti con chown:
sudo chown -R www-data:www-data /var/www/html/
Fatto! Da adesso la configurazione del database di WordPress dovrebbe funzionare.
Foto di copertina: Boitumelo Phetla on Unsplash
👇 Da non perdere 👇
- Informatica 🖥
- Internet 💻
- Marketing & SEO 🌪
- Programmare 🖥
- Svago 🎈
- 💬 Il nostro canale Telegram: iscriviti
- 🔵 Come configurare al meglio il file httpd.conf di Apache
- 🟢 Guida generale all’uso di memcached (ed agli hosting che lo supportano)
- 🟡 Perchè è difficile cambiare idea (dopo averla espressa in pubblico)?
