А от точно так же, як ви робили М-М реплікацію, ви можете також зробити, щоб у вас був такий ланцюг — коли кожний Master є Slave для попереднього. Просто ви тоді не врубаєте Slave на попередньому Master, і все. (UPD — а, неправильно написав, тут вам потрібно робити кільце). Чи я неправильно зрозумів, и ви хочете два М-М кластери, щоб один в Фін, а другий в США?

UPD — чи всі 4 Master? Ви повинні бути впевнені, что дані будуть різні, без дублювання. Це складніше. Якщо залишатись в рамках стандартної процедури реплікації, це може бути топологія «кільце». Але думаю, слід дивитись в бік Galera Cluster чи подібного.
UPD2 — мало хто робить MultiMaster на дефолтному механізмі реплікації, тому що ви ризикуєте отримати розсинхрон, якщо впаде один з серверів надовго. Каскадне взаємооновлення (два M-M кластери) виглядає надійніше. Також майте на увазі, що я «зварювальник несправжній» — в проді таке не робив, тільки на віртуалках балувався в учбових цілях. Тож хай мене хто поправить, якщо є DBA.

З Wordpress пригадую пару проблем з практики:
1. Без query_cache кілька разів підряд виконувався довгий запит, сайт вмирав по 504. Увіткнули query_cache — покращало, але все ще погано.
2. Були погані індекси в БД — використали плагін Index WP MySQL For Speed. В результаті поганий запит виконується 3 — 4 секунди замість 50+. Автори плагіну написали статтю, як внести такі самі зміни вручну.

Ви можете перевірити за допомогою mysqladmin, чи ваш цей випадок — треба дивитись, в якому саме статусі висить довгий запит. Підозрюю, що кеш не працює вірно, якщо звернення йде по мережі, але тут вже діагностика на місці потрібна.