Проблемы с задержкой репликации MySQL в страницах wp-admin

У меня есть среда с WP 3.0.1 с Master db и двумя подчиненными. Я использую HyperDB, чтобы заставить все записи перейти к Мастеру, и все читают, чтобы читать из двух подчиненных.

Я испытываю множество проблем на страницах wp-admin, где данные записываются ведущему, а WordPress пытается прочитать из подчиненного устройства, и данные еще не достигли подчиненного устройства. Примером этого является, когда я перехватываю ' dbx_post_advanced ', чтобы задать некоторые категории и пользовательские термины таксономии для новых сообщений. Я подтвердил, что, когда я настраиваю HyperDB для чтения и записи только из Master, крюк dbx_post_advanced работает отлично.

В настоящее время я рассматриваю следующие варианты решения этой проблемы:

  • Выделите только один веб-сервер для всего трафика wp-admin
    • Настройте этот сервер для чтения и записи только в Master db
    • Настройте балансировщик нагрузки для маршрутизации всех URL-адресов / wp-admin на этот веб-сервер
  • Настройте HyperDB для чтения / записи против Master только для страниц wp-admin
  • Настройка MySQL-полусинхронная репликация
    • http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html
    • Однако это решение, скорее всего, не сработает, потому что полусинхронная репликация будет ждать только до тех пор, пока ОДИН подчиненный не завершит свои записи, а не обе подчиненные в моем случае

Дайте мне знать, если у вас есть какие-либо советы по этой проблеме.

Благодарю, Дэйв

Solutions Collecting From Web of "Проблемы с задержкой репликации MySQL в страницах wp-admin"

Вы не упомянули версию HyperDB, поэтому я предполагаю trunk @ 337290.

Функция SRTM от HyperDB (передача чтения в мастер) работает двумя способами. Во-первых, он отслеживает, какие таблицы получили записи во время текущего скрипта и отправляет все последующие чтения для этих таблиц в мастер. Во-вторых, это дает вам способ заставить все читать мастеру.

В первом случае считывание по-прежнему возможно, чтобы попасть в подчиненное устройство после записи в ту же таблицу. Если чтение является запросом соединения или другим типом запроса, который может помещать имена таблиц далеко от начала запроса, он может проскользнуть. Если вы можете проверить запрос, который ненадлежащим образом переходит к ведомому устройству, см., Если это так. Если да, попробуйте увеличить длину substr здесь:

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

Важно понимать, что функция SRTM отслеживает только один сценарий. Поэтому, если вы пишете запись (в первом скрипте), а затем перенаправляетесь (теперь во втором скрипте), а затем пытаетесь прочитать эту запись из базы данных, вы, вероятно, будете читать из подчиненного на этом втором скрипте.

Наконец, позвольте мне обратиться к is_admin() . Это прекрасная идея, простая и эффективная. Добавьте что-то подобное в свой файл db-config:

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

Я бы посоветовал вам развернуть другую копию вашего сайта с различными сведениями о подключении по адресу http://admin.example.com/. В этой области администрирования будут использоваться сведения о главном соединении, а также читать и записывать мастеру и не пострадать от каких-либо проблем от недоступных данных. Вы можете заставить URL-адрес администратора отличаться, установив флаги в wp-config.

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

Внешний сайт http://example.com/ будет работать так же, как и в настоящее время.

Вы изучили репликацию MySQL на основе Tungsten Replicator http://code.google.com/p/tungsten-replicator/ , она улучшает собственную репликацию MySQL и улучшает ведомое отставание и т. Д. http://vbtechsupport.com/1318/ .

Замечательная кулинарная книга с примерами, чтобы начать работу по адресу http://code.google.com/p/tungsten-replicator/wiki/TungstenReplicatorCookbook