Насколько я понял из документации Amazon aurora, даже если главный узел Aurora синхронно записывает журнал WAL на 4 из 6 узлов хранения. Если нет переключения ведущего, ведомое устройство Aurora синхронизируется только с использованием асинхронной доставки журналов непосредственно с ведущего узла.
Если это правда, я бы предположил, что клиент может записать и зафиксировать значение на главном узле, а затем немедленно отправить запрос только для чтения одному из подчиненных и наблюдать старое значение вместо последнего значения, которое только что было записано. .
это означало бы, что он может поддерживать только режим изоляции моментальных снимков на ведомом устройстве.
это кажется очень большим ограничением! И я хотел убедиться, что это правильно.
Сериализуемая изоляция - сложная проблема для кластеров. Я не знаю никого, кто действительно поддерживает это. И если бы был один из них, я не знаю, готов ли я согласиться с последствиями для производительности, которые могут возникнуть с ним.
Выполнение следующего на экземпляре aurora, похоже, указывает на то, что поддерживается только REPEATABLE-READ
.
mysql> SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT @@GLOBAL.tx_isolation, @@tx_isolation;
+-----------------------+-----------------+
| @@GLOBAL.tx_isolation | @@tx_isolation |
+-----------------------+-----------------+
| REPEATABLE-READ | REPEATABLE-READ |
+-----------------------+-----------------+
1 row in set (0.00 sec)
mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT @@GLOBAL.tx_isolation, @@tx_isolation;
+-----------------------+-----------------+
| @@GLOBAL.tx_isolation | @@tx_isolation |
+-----------------------+-----------------+
| REPEATABLE-READ | REPEATABLE-READ |
+-----------------------+-----------------+
1 row in set (0.00 sec)
Из-за возможной согласованности из-за задержки репликации; если критически важно, чтобы вы получали данные в реальном времени, вы должны читать против мастера.
Я запустил это на раб.
Спасибо, REPEATABLE-READ по-прежнему вводит в заблуждение, потому что REPEATABLE-READ на одном узле MySQL будет означать, что вы увидите последнюю завершенную запись :(
Задержка реплики для Aurora очень мала по сравнению с репликами чтения, отличными от Aurora, но все же имеет ненулевое значение, которое вы можете отслеживать с помощью метрики CloudWatch AuroraBinlogReplicaLag
и AuroraReplicaLag
- более подробно документированной в https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Monitoring.html. Что касается вашего вопроса, Аврора не пишет синхронно во все 6 копий хранилища - только в 4. Сверхглубокое погружение в блог из 4 частей о том, как работает эта система хранения, можно найти на https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-quorum-and-correlated-failure, и я призываю всех его прочитать. Вы также можете узнать больше о репликации Aurora на https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html. но Стив Бузонас прав - если вам нужны гарантированные чтения после записи SERIALIZABLE
, то вам нужно читать из конечной точки экземпляра записи: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html
вы запускали эту команду против мастера или против подчиненного?