Я б ще порекомендував відфільтрувати базу mysql, бо вона одна і та ж на всіх трьох вихідних серверах БД. Або ж навпаки додати фільтр лише на бази, що потрібно реплікувати
ПС: також додам, що Oracle відходить від понять «master» та «slave» і радить використовувати source та replica.

Aurora MySQL. Під «повільніщі» я маю на увазі дві речі: дещо вищій CPUUtilization на ARM при однаковій нагрузці та дещо повільніщі запити на запис (commit, insert, delete, update).

Стосовно AWS Aurora та r6g (Graviton2) інстансів, то вони дещо повільніщі за Інтеловські, особливо для маленьких інстансів, а от r7g (Graviton3) виглядає помітно краще за r6g. А так працюють, проблем/багів теж не помічав.

Дякую за статтю.

Зміна структури таблиці в базі даних, що підтримує схему, у більшості випадків ексклюзивно блокує всю таблицю.

Працюю багато з MySQL, і більшість змін схеми не лочать таблиці. Не скажу за всі типи баз, але здається більшість реляційних баз вже вміють не лочити таблиці, наприклад, при додаванні або видаленні колонок та індексів. А це мабуть 90% всіх змін, що трапляються.
Раніше часто використовував

pt-online-schema-change

, зараз рідко. Але іноді без неї ніяк. Дуже гарна утіліта.

Спасибо, что поделились. Всегда полезно учится на ошибках других. Не знаю, был ли в команде ДБА, но, думаю, многие проблемы с запросами можно было попытаться выявить заранее. А MySQL tuner может как помочь, так и поломать.

Валерия, спасибо. Видно, что Вы глубоко разобрались в данной области и смогли структурировать знания в такой короткой статье. Очень позновательно и полезно, жаль не все ее восприняли, как это должно быть.

Я бы потестировал версию для Linux.

Нигде с таким подходом не сталкивался.
А по поводу нервов: человек он такой, что со временем ко всему привыкает. Если первые изменения на базе делаются под аккомпанемент сердечной мышцы и с выступающим пОтом на ладонях, то со временем черствеешь и запускаешь все, особо не задумываясь о чувствах :).