Probleme de întârziere la replicarea MySQL în paginile wp-admin

17 ian. 2011, 19:44:35
Vizualizări: 1.66K
Voturi: 6

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

Anunțați-mă dacă aveți sugestii pentru această problemă.

Mulțumesc, Dave

2
Comentarii

Tocmai am observat că cea mai recentă versiune de HyperDB conține o nouă funcție numită send_reads_to_master(), care ar trebui să rezolve problema mea din punct de vedere tehnic. Totuși, nu sunt sigur în ce condiții ar trebui setat acest flag. Nu apare nicăieri în cod, din câte pot observa. Are cineva o idee despre asta?

Dave Morris Dave Morris
17 ian. 2011 23:47:40

Am observat că ai discutat asta și pe lista de mailing wp-hackers. Ai reușit să obții o soluție funcțională bazată pe send_reads_to_master() și is_admin()? Dacă da, poate ai vrea să postezi un răspuns aici cu câteva detalii.

Dougal Campbell Dougal Campbell
28 feb. 2011 20:31:59
Toate răspunsurile la întrebare 3
0

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

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.

18 mar. 2011 15:20:47
Comentarii

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

gabrielk gabrielk
31 mar. 2011 21:45:45

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.

Tom Tom
1 apr. 2011 13:10:40

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

Mark Jaquith Mark Jaquith
7 iun. 2011 06:53:43

@Mark Jaquith ce fel de probleme ai întâmpinat?

Tom Tom
7 iun. 2011 09:58:08

Am avut plugin-uri care nu funcționau. A trebuit să modificăm cookie-urile. Au fost o grămadă de momente mici de genul "de ce nu merge asta?". A fost mai simplu să faci proxy-ul să recunoască cererile către wp-admin și să le trimită la serverul corect.

Mark Jaquith Mark Jaquith
8 iun. 2011 20:39:05
0

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

20 sept. 2011 10:27:03