Problemi di Latenza nella Replicazione MySQL nelle pagine wp-admin

17 gen 2011, 19:44:35
Visualizzazioni: 1.66K
Voti: 6

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

Fatemi sapere se avete consigli su questo problema.

Grazie, Dave

2
Commenti

Ho appena notato che l'ultima versione di HyperDB contiene una nuova funzione chiamata send_reads_to_master(), che tecnicamente dovrebbe risolvere il mio problema. Tuttavia, non sono sicuro in quali condizioni questo flag dovrebbe essere impostato. Non sembra apparire da nessuna parte nel codice, per quanto ne so. Qualcuno ha qualche idea al riguardo?

Dave Morris Dave Morris
17 gen 2011 23:47:40

Ho notato che ne hai parlato anche nella mailing list wp-hackers. Sei riuscito a trovare una soluzione funzionante basata su send_reads_to_master() e is_admin()? Se sì, potresti voler pubblicare una risposta qui con alcuni dettagli.

Dougal Campbell Dougal Campbell
28 feb 2011 20:31:59
Tutte le risposte alla domanda 3
0

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();
30 mar 2011 20:14:30
5

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.

18 mar 2011 15:20:47
Commenti

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.).

gabrielk gabrielk
31 mar 2011 21:45:45

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.

Tom Tom
1 apr 2011 13:10:40

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.

Mark Jaquith Mark Jaquith
7 giu 2011 06:53:43

@Mark Jaquith che tipo di problemi hai riscontrato?

Tom Tom
7 giu 2011 09:58:08

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.

Mark Jaquith Mark Jaquith
8 giu 2011 20:39:05
0

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

20 set 2011 10:27:03