Несколько недель назад я запустил экземпляр RDS Aurora A-Z. Он автоматически создал два экземпляра: основной и реплику только для чтения.
На прошлой неделе я использовал интерфейс командной строки mysql для входа в основной экземпляр mysql и успешно создал новую таблицу. Сегодня я использовал интерфейс командной строки mysql для входа в основной экземпляр mysql, попытался внести изменения и получил сообщение об ошибке, в котором говорилось, что база данных доступна только для чтения. Затем я заглянул в консоль AWS RDB и обнаружил, что основная и реплика поменялись местами. Главный доступен только для чтения, а реплика является писателем.
Я заметил это часа 2 назад, и ситуация не изменилась. Таким образом, этого не происходит из-за окна обслуживания (поскольку окна обслуживания длится всего 30 минут).
Почему это могло произойти? Что я должен сделать, чтобы этого не случилось в будущем?
Они могли переключиться из-за технического обслуживания. Есть ожидает обновления до Aurora 1.7.1 от 20.09.2016 для одного из моих скоплений полярных сияний сейчас (15.10.2016, SELECT @@AURORA_VERSION; показывает 1.6). Было бы разумно, если бы сначала были обновлены реплики, затем было инициировано событие аварийного переключения, а затем было бы обновлено главное устройство, но я предполагаю - я не могу найти это явно указано в документации.
Или, возможно, произошел сбой исходного мастера, что привело к аварийному переключению с последующим восстановлением исходного мастера.
В любом случае вы должны найти доказательства что-то в журналах событий экземпляра, если предположить, что это было недавно - см. «События» в левой части консоли RDS.
Но что касается того, почему они переключились, а затем не переключились обратно, то на этот вопрос потенциально легче ответить - я не думаю, что есть причина ожидать, что они переключатся обратно.
В любой момент времени один из ваших экземпляров является «главным», но, в отличие от собственной репликации MySQL / MariaDB, называть его «мастером» неточно, потому что все экземпляры в кластере Aurora имеют общее хранилище резервных копий. - у них нет отдельных копий данных, все они одноранговые узлы, обращающиеся к общему и реплицированному внутреннему хранилищу. Вместо ведущего и ведомых / реплик, один из них писатель (может читать и писать), а остальные (если они существуют, допустим один экземпляр "кластера") читатели (только для чтения), но любой из экземпляров может стать писателем из-за события аварийного переключения (которое может быть инициировано по причинам, отличным от фактического сбоя). Можно установить приоритеты экземпляров, чтобы отработка отказа вызывала переключение на предпочтительный экземпляр (экземпляры в кластере Aurora не обязательно должны быть одним и тем же классом экземпляров), но это кажется актуальным только тогда, когда количество узлов больше двух.
По сути, однако, дизайн Aurora выглядит так, что вы не должны думать о своих экземплярах, как будто какой-то конкретный из них является главным ... и инфраструктура дает возможность не иметь значения.
Кластеру Aurora присвоено имя кластера, присвоенное вами, и буквенно-цифровой идентификатор кластера, присвоенный системой, а каждому экземпляру в кластере присвоено имя, назначенное вами.
Aurora, как это стандартное поведение для RDS, создает имя хоста в DNS для каждого экземпляра на основе имени, которое вы даете экземпляру, и идентификатора кластера, но в кластере Aurora созданы два дополнительных имени хоста - одно, которое соединит вас с писателем. , и другой, который свяжет вас с одним из читателей (или он также свяжет вас с единственным членом кластера, который на самом деле является писателем, когда в кластере только один член).
Итак, скажем, ваше имя кластера prod-db, допустим, ваш системный идентификатор xyzzyexample, и скажем, созданные вами узлы названы node-1 и node-2... и регион us-east-1.
Имена хостов экземпляров выглядят так:
node-1.xyzzyexample.us-east-1.rds.amazonaws.com # instance 1
node-2.xyzzyexample.us-east-1.rds.amazonaws.com # instance 2
Но имена хостов, которые вы должны использовать для доступа к Aurora, не те.
Те, которые вам следует использовать, если у вас нет особой причины поступить иначе, например, привязать задание к определенной реплике, выглядят следующим образом:
prod-db.cluster-xyzzyexample.us-east-1.rds.amazonaws.com # writer
prod-db.cluster-ro-xyzzyexample.us-east-1.rds.amazonaws.com # reader
Они реализованы как CNAME в DNS, управляемом RDS, поэтому каждый раз, когда вы подключаетесь, вы получаете ответ, соответствующий текущей конфигурации вашего кластера. TTL составляет 5 секунд для адреса записи и 1 секунду для адреса считывателя, так что вероятность того, что ответ будет правильным, довольно высока. Используя эти адреса для подключения, вам не нужно беспокоиться о том, что машины меняют роли.