PowerDNS Метод передачи "Главный-подчиненный"
Чтобы основанный на имени виртуальный хостинг работал правильно, необходимо соответствовать Вашему связывать адрес для <VirtualHost> блоки к тому, что настроено в NameVirtualHost директива. Основанного на имени хостинга не происходит, таким образом, первый блок, который возьмет адрес, получает все запросы.
Как правило, у Вас будет директива как это где-нибудь в Ваших файлах конфигурации Apache (ports.conf, распространено, когда конфигурация разделяется):
NameVirtualHost *:80
Что означает, что Вы хотите vhosts, который будет распределять запросы, по имени должен соответствовать тому, что устанавливается там:
<VirtualHost *:80>
ServerName sub.domain.com
...
</VirtualHost>
<VirtualHost *:80>
ServerName domain.com
# (you might want this too):
ServerAlias www.domain.com
...
</VirtualHost>
Между прочим, почему Ваш <Directory> директивы, управляющие просто domain_net и нет domain_com?
В итоге я использовал кластер mysql galera, со всеми 3 серверами Power DNS, установленными как главные, работает как шарм
В документации говорится: «Собственная репликация используется по умолчанию, если другая операция не настроена специально». ( http://doc.powerdns.com/html/replication.html ) Под Native это относится к репликации, которая является встроенной для используемого вами бэкэнда, где ему не нужно принимать активное участие в самом процессе, а просто использовать данные, которые он представляет. Таким образом, для большинства людей MySQL Native обычно означает репликацию MySQL, хотя технически так же можно назвать комбинацию rsync и mysqldump.
Сервер PowerDNS не поддерживает инкрементные передачи зон (IXFR), но использует AXFR. Для действительно больших зон это будет означать увеличение сетевого трафика между вашими серверами имен. Также у меня нет опыта, что происходит, когда зона больше, чем доступная оперативная память. Тогда сервер PowerDNS может задохнуться.
Главный / подчиненный сервер AXFR может быть настроен только с бэкэндом BIND Zonefile, т.е. в «традиционном» стиле BIND8 / 9,
Обратите внимание, что MySQL представляет собой обычный текст над строкой. Поэтому вам нужно зашифровать, например. не сливайте свои ключи dnssec.
MySQL SSL слишком хлопотный (и вам, скорее всего, придется компилировать его вручную). MySQL через ssh-туннель — лаваш для настройки. MySQL выше всего остального - есть проблема с поддержанием работы туннеля, а подчиненный и ведущий не отключают друг друга.
Лучшее решение — mysqldump поверх scp. Вы можете устранить все проблемы с туннелями и соединениями master-slave.
Вы можете настроить пользовательский nanocron для синхронизации каждые 10 секунд, при малых db это ничего не значит