Den_KP,

Казалось бы, чего тут сложного. Коннект к одной базе, селект, сохранение данных в буфере. Коннект к дугой, данные из буфера заинсертить. Как связать серверы - есть варианты от "открыть доступ к СУБД наружу" до VPN или SSH-туннелей. А можно через вебсервер передать POST-запросом с соблюдением некоторых ограничительных мер. Тут мало интересного.
Другое дело, переливать ли всю большущую таблицу (или определенные её столбцы) целиком или только добавленные/изменившиеся строки. А ещё ж записи могут быть и удалены. Как узнать, что именно изменилось - вести лог изменений или, может, проще копию изменений делать в отдельных таблицах. Вопрос целостности данных, опять же. Прелили, к примеру, таблицу А, потом Б, а на таблице В то ли канал сдох, то ли сервер в ребут ушел... Сразу и не понятно, с какой точки продолжать процесс и как. В этом смысле, наверно, надежнее будет перегонять набор взаимосвязанных записей из разных таблиц (вроде транзакции). Опять же, какой-то лог синхронизации должен быть, наверно, чтобы после восстановления продолжить (сам лог тоже, кстати, при аварии может не записаться при самом отвратном стечении обстоятельств). Ну и приоритеты, когда одна и та же запись обновилось на обоих серверах и поля приняли различные значения - кто тут главнее будет при синхронизации.

Давно как-то решал немного похожую задачу (раз в сутки делать копию некоторых таблиц). Если интересно, сделал вот каким образом. По крону на одном сервере скриптом формировал файлик с текстом SQL-запросов (по сути, дамп), потом этот файлик и другой, с контрольной суммой (вроде, хеш md5 использовал), по FTP закидывал на другой сервер. Там, тоже по крону запускался скрипт, проверял наличие файла в обусловленном месте, его контрольную сумму, отрабатывал запросы, и, при успешном завершении, удалял присланные файлы.