Probleme de întârziere la replicarea MySQL în paginile wp-admin
Am un mediu care rulează WordPress 3.0.1 cu o bază de date Master și două slave. Folosesc HyperDB pentru a forța toate scrierile să meargă către Master, iar toate citirile să se facă de pe cele două slave.
Întâmpin diverse probleme în paginile wp-admin unde datele sunt scrise pe master, iar WordPress încearcă să citească de pe un slave, iar datele încă nu au ajuns pe slave. Un exemplu este când folosesc hook-ul 'dbx_post_advanced' pentru a pre-setă unele categorii și termeni de taxonomie personalizată pe postări noi. Am verificat că atunci când configurez HyperDB să citească și să scrie doar pe Master, hook-ul 'dbx_post_advanced' funcționează corect.
Momentan analizez următoarele opțiuni pentru a rezolva această problemă:
- Dedic doar un server web pentru tot traficul wp-admin
- Configurez acel server să citească și să scrie doar pe Master
- Configurez load balancer-ul să direcționeze toate URL-urile /wp-admin către acel server web
- Configurez HyperDB să citească/scrie doar pe Master pentru paginile wp-admin
- Configurare Replicare Semisincronă MySQL
- http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html
- Această soluție probabil nu va funcționa, deoarece replicarea semisincronă va aștepta doar până când UN slave își finalizează scrierile, nu ambele slave în cazul meu
Anunțați-mă dacă aveți sugestii pentru această problemă.
Mulțumesc, Dave
Nu ai menționat o versiune specifică a HyperDB, așa că presupun că folosești trunk @337290.
Funcția SRTM (send reads to master) din HyperDB funcționează în două moduri. În primul rând, ține evidența tabelelor care au primit scrieri în timpul scriptului curent și trimite toate citirile ulterioare pentru acele tabele către serverul master. În al doilea rând, îți oferă o metodă pentru a forța toate citirile să meargă către master.
În primul caz, este totuși posibil ca o citire să ajungă la slave după o scriere în același tabel. Dacă citirea este un join sau un alt tip de interogare care poate plasa numele tabelelor departe de începutul interogării, aceasta ar putea să scape. Dacă poți inspecta interogarea care merge incorect către slave, verifică dacă acesta este cazul. Dacă da, încearcă să mărești lungimea substr
aici:
if ( preg_match($pattern, substr($query, 0, 1000)) )
Este important să înțelegi că funcția SRTM ține evidența doar în timpul unui singur script. Deci dacă scrii un record (în primul script) și apoi ești redirecționat (acum în al doilea script) și încerci să citești acel record din baza de date, probabil vei citi de pe slave în acel al doilea script.
În final, să abordăm ideea cu is_admin()
. Este o idee bună, simplă și efectivă. Adaugă ceva de genul acesta în fișierul tău db-config:
if ( is_admin() )
$wpdb->send_reads_to_masters();

Aș recomanda să implementați o altă copie a site-ului dumneavoastră cu detalii de conexiune diferite la http://admin.example.com/ Această zonă de administrare ar folosi detaliile de conexiune principale și ar efectua operațiuni de citire și scriere pe serverul principal, fără a întâmpina probleme legate de indisponibilitatea datelor. Puteți forța URL-ul de administrare să fie diferit prin setarea unor flag-uri în wp-config.
define('WP_SITEURL', 'http://admin.example.com');
define('WP_CONTENT_URL', 'http://admin.example.com');
Site-ul pentru public http://example.com/ ar funcționa așa cum o face în prezent.

Asta ar necesita mult mai multă muncă. După un timp, URL-ul tău admin.example.com ar începe să circule pe internet. Ai nevoie să adaugi multe filtre pentru a schimba URL-ul și să te asiguri că template-ul tău folosește URL-uri canonice, are meta date noindex corecte / reguli robots.txt pentru admin.example.com, etc. Ar putea fi periculos din perspectiva SEO și dezastruos dacă URL-ul ar deveni public și vizitatorii ar începe să acceseze acel URL (ocolind slave-urile tale de citire, etc).

admin.example.com ar putea fi configurat să afișeze doar wp-admin și să nu servească niciodată o pagină, trebuie să modifici DocumentRoot dar este posibil. Dacă URL-urile de pe frontend nu ar lega înapoi la admin.example.com, ai putea pune admin.example.com în spatele unei autentificări HTTP basic pentru securitate suplimentară și pentru a preveni crawling-ul.

Nu aș recomanda asta. Am fost pe această cale și am descoperit că a cauzat multe dureri de cap. Am fost mult mai mulțumit după ce am făcut câteva reguli nginx pentru a proxy request-urile wp-admin
către o altă mașină.

Ați analizat replicarea MySQL bazată pe Tungsten Replicator http://code.google.com/p/tungsten-replicator/? Aceasta îmbunătățește replicarea nativă MySQL și reduce întârzierea slave-ului etc. http://vbtechsupport.com/1318/.
O carte minunată de rețete cu exemple de configurare pentru a vă ajuta să începeți la http://code.google.com/p/tungsten-replicator/wiki/TungstenReplicatorCookbook
