Problemi di Latenza nella Replicazione MySQL nelle pagine wp-admin
Ho un ambiente che esegue WP 3.0.1 con un database Master e due slave. Utilizzo HyperDB per forzare tutte le scritture sul Master e tutte le letture sui due slave.
Sto riscontrando vari problemi nelle pagine wp-admin dove i dati vengono scritti sul master, ma WordPress tenta di leggere da uno slave e i dati non sono ancora stati replicati. Un esempio è quando aggancio 'dbx_post_advanced' per preimpostare alcune categorie e termini di tassonomia personalizzata sui nuovi post. Ho verificato che quando configuro HyperDB per leggere e scrivere solo dal Master, l'hook 'dbx_post_advanced' funziona correttamente.
Attualmente sto valutando le seguenti opzioni per risolvere il problema:
- Dedicare un solo web server a tutto il traffico wp-admin
- Configurare quel server per leggere e scrivere solo dal Master
- Configurare il load balancer per indirizzare tutte le URL /wp-admin a quel web server
- Configurare HyperDB per leggere/scrivere solo sul Master per le pagine wp-admin
- Impostare la Replicazione Semisincrona MySQL
- http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html
- Questa soluzione probabilmente non funzionerà, perché la replicazione semisincrona attende solo che UNO slave completi le scritture, non entrambi come nel mio caso
Fatemi sapere se avete consigli su questo problema.
Grazie, Dave
Non hai menzionato una revisione specifica di HyperDB, quindi assumo che stiamo parlando della trunk @337290.
La funzionalità SRTM di HyperDB (invia le letture al master) funziona in due modi. Primo, tiene traccia delle tabelle che hanno ricevuto scritture durante lo script corrente e invia tutte le letture successive per quelle tabelle al master. Secondo, ti offre un modo per forzare tutte le letture al master.
Nel primo caso, è ancora possibile che una lettura colpisca lo slave dopo una scrittura sulla stessa tabella. Se la lettura è una query di join o un altro tipo di query che può posizionare i nomi delle tabelle lontano dall'inizio della query, potrebbe sfuggire al controllo. Se riesci a ispezionare la query che sta andando impropriamente allo slave, verifica se è questo il caso. Se sì, prova ad aumentare la lunghezza del substr
qui:
if ( preg_match($pattern, substr($query, 0, 1000)) )
È importante capire che la funzionalità SRTM tiene traccia solo durante uno script. Quindi se scrivi un record (nel 1° script) e poi vieni reindirizzato (ora nel 2° script) e poi provi a leggere quel record dal database, probabilmente leggerai dallo slave in quel secondo script.
Infine, lasciami affrontare l'idea di is_admin()
. È un'idea valida, semplice ed efficace. Aggiungi qualcosa come questo al tuo file db-config:
if ( is_admin() )
$wpdb->send_reads_to_masters();

Consiglierei di distribuire un'altra copia del tuo sito con dettagli di connessione diversi su http://admin.example.com/ Questa area amministrativa utilizzerebbe i dettagli di connessione master e farebbe letture e scritture sul master senza soffrire di problemi legati a dati non disponibili. Puoi forzare un URL amministrativo diverso impostando dei flag nel wp-config.
define('WP_SITEURL', 'http://admin.example.com');
define('WP_CONTENT_URL', 'http://admin.example.com');
Il sito frontend http://example.com/ continuerebbe a funzionare come fa attualmente.

Ciò richiederebbe molto più lavoro. Dopo un po', il tuo URL admin.example.com inizierebbe a diffondersi in giro. Dovresti aggiungere molti filtri per modificare l'URL e assicurarti che il tuo template utilizzasse URL canonici, avesse i giusti metadati noindex / regole robots.txt per admin.example.com, ecc. Potrebbe essere pericoloso dal punto di vista SEO e disastroso se l'URL diventasse pubblico e i visitatori iniziassero a raggiungerlo (bypassando i tuoi slave di lettura, ecc.).

admin.example.com sarebbe configurato per mostrare solo il wp-admin e non servire mai effettivamente una pagina, devi intervenire sul DocumentRoot ma è possibile. Se gli URL sul frontend non rimandassero mai a admin.example.com, potresti mettere admin.example.com dietro un'autenticazione HTTP basic per maggiore sicurezza e prevenire il crawling.

Non lo consiglierei. Ci sono già passato e ho scoperto che causava molti mal di testa. Sono stato molto più felice dopo aver creato alcune regole nginx per fare il proxy delle richieste wp-admin
a un altro server.

Alcuni plugin non funzionavano. I cookie dovevano essere modificati. C'erano tantissimi piccoli momenti di "perché questa cosa non funziona?". Era semplicemente più facile fare in modo che il proxy riconoscesse le richieste a wp-admin
e le inviasse al server corretto.

Hai considerato la replica MySQL basata su Tungsten Replicator http://code.google.com/p/tungsten-replicator/, che migliora la replica nativa di MySQL e riduce il ritardo degli slave, ecc. http://vbtechsupport.com/1318/.
Un fantastico cookbook con esempi di configurazione per iniziare è disponibile su http://code.google.com/p/tungsten-replicator/wiki/TungstenReplicatorCookbook
