web-dev-qa-db-fra.com

Problèmes de latence de réplication MySQL dans les pages wp-admin

J'ai un environnement fonctionnant sous WP 3.0.1 avec une base de données principale et deux esclaves. J'utilise HyperDB pour forcer toutes les écritures à aller vers le maître et toutes les lectures à lire des deux esclaves.

Je rencontre plusieurs problèmes dans les pages wp-admin où des données sont en cours d'écriture sur le maître, et WordPress tente de lire à partir d'un esclave, mais les données ne sont pas encore parvenues à l'esclave. Un exemple de ceci est quand je crochets 'dbx_post_advanced' pour prédéfinir des termes de taxonomie de catégories et personnalisés sur de nouvelles publications. J'ai vérifié que lorsque je configure HyperDB pour lire et écrire à partir du maître seul, le hook 'dbx_post_advanced' fonctionne correctement.

J'examine actuellement les options suivantes pour résoudre ce problème:

  • Ne dédiez qu'un seul serveur Web à tout le trafic wp-admin
    • Configurez ce serveur pour lire et écrire sur/depuis la base de données principale uniquement
    • Configurez l'équilibreur de charge pour acheminer toutes les URL/wp-admin vers ce serveur Web.
  • Configurez HyperDB pour lire/écrire sur le maître uniquement pour les pages wp-admin
  • Configuration de la réplication semi-synchrone MySQL

Faites-moi savoir si vous avez des conseils à ce sujet.

Merci Dave

mysqlhyperdb
5
Dave Morris

Vous n'avez pas mentionné une révision HyperDB, donc je suppose que trunk @ 337290.

La fonction SRTM d'HyperDB (envoi de lectures au maître) fonctionne de deux manières. Tout d'abord, il garde trace des tables ayant reçu des écritures pendant le script en cours et envoie toutes les lectures ultérieures de ces tables au maître. Deuxièmement, cela vous donne un moyen de forcer toutes les lectures au maître.

Dans le premier cas, il est toujours possible pour une lecture d'atteindre l'esclave après une écriture dans la même table. Si la lecture est une requête de jointure ou un autre type de requête pouvant placer des noms de table loin du début de la requête, il est possible que celle-ci échoue. Si vous pouvez inspecter la requête qui ne va pas correctement à l'esclave, voyez si c'est le cas. Si c'est le cas, essayez d'augmenter la longueur substr ici:

if ( preg_match($pattern, substr($query, 0, 1000)) )

Il est important de comprendre que la fonctionnalité SRTM ne garde trace que pendant un seul script. Ainsi, si vous écrivez un enregistrement (dans le premier script), puis que vous êtes redirigé (maintenant dans le deuxième script), puis tentez de lire cet enregistrement dans la base de données, vous lirez probablement l'esclave de ce deuxième script.

Enfin, laissez-moi aborder l’idée is_admin(). C'est une bonne idée, simple et efficace. Ajoutez quelque chose comme ceci à votre fichier db-config:

if ( is_admin() )
    $wpdb->send_reads_to_masters();
3
Andy

Avez-vous examiné la réplication MySQL basée sur Tungsten Replicator http://code.google.com/p/tungsten-replicator/ , elle améliore la réplication native de MySQL et améliore le décalage des esclaves, etc http://vbtechsupport.com/1318/ .

Un livre de recettes exceptionnel contenant des exemples de configuration pour vous permettre de démarrer à partir de http://code.google.com/p/tungsten-replicator/wiki/TungstenReplicatorCookbook

0
p4guru

Je vous conseillerais de déployer une autre copie de votre site avec des détails de connexion différents pour http://admin.example.com/ / Cette zone d'administration utiliserait les détails de connexion du maître et ferait des lectures et des écritures au maître, souffrez de problèmes dus à l’absence de données. Vous pouvez forcer l'URL d'administrateur à être différent en définissant des indicateurs dans wp-config.

    define('WP_SITEURL', 'http://admin.example.com');
    define('WP_CONTENT_URL', 'http://admin.example.com');

Le site frontal http://example.com/ fonctionnerait comme il le fait actuellement.

0
Tom