Wir verwenden Route53 für unser privates DNS, insbesondere die Multivalue Answer Routing Policy, ohne Health Checks für Dump/Lazy Load Balancing.
Das hat bei uns gut funktioniert, bis uns gestern ein merkwürdiges Verhalten auffiel.
Wir haben einen Datensatzsatz für ro.mysql.foo.bar.com, der die IPs unserer schreibgeschützten MySQL-Replikate enthält.
Wenn Sie ein DIG ausführen, spiegelt es dies wider;
dig A ro.mysql.foo.bar.com
;; QUESTION SECTION:
;ro.mysql.foo.bar.com. IN A
;; ANSWER SECTION:
ro.mysql.foo.bar.com. 4 IN A 10.2.2.2
ro.mysql.foo.bar.com. 4 IN A 10.2.2.3
ro.mysql.foo.bar.com. 4 IN A 10.2.2.4
Das erwartete Verhalten ist, dass MySQL, wenn ro.mysql.foo.bar.comes auftrifft, sich zufällig mit einem der drei Hosts verbindet, und zwar auf eine Art dumme/zufällige Art und Weise, die die Last ausbalanciert. Das hat bis gestern problemlos funktioniert.
Wenn ich renne
mysql -h ro.mysql.foo.bar.com -e "select @@hostname;"
Ich würde erwarten, dass die Ausgabe zwischen , , und @@hostnamevariiert10.2.2.210.2.2.310.2.2.4
Stattdessen wird der Datenverkehr nicht zufällig über die drei IPs umgeleitet, sondern es wird eine verwendet und nur eine genutzt.
+-----------------------------------+
| @@hostname |
+-----------------------------------+
| 10.2.2.3 |
+-----------------------------------+
Wenn wir es aus dem DNS entfernen 10.2.2.3, wird es nicht mehr verwendet. Wenn wir es wieder hinzufügen, wird es nur noch einmal verwendet 10.2.2.3.
Wir betreiben unseren eigenen Resolver über PowerDNS (den wir auslaufen lassen), aber soweit wir sehen, liegt dort kein Fehler vor, der DNS-Cache von PowerDNS wurde ebenfalls geleert.