Я взагалі великий шанувальник AWS ... але RDS, не так вже й багато.
@RolandoMySQLDBA зазначив, що це досить непогані моменти.
Єдиною перевагою, яку я бачу в RDS порівняно з MySQL на EC2, є можливість робити точкові та клацаючі знімки, клони та відновлення в момент часу, але це майже не достатньо, щоб компенсувати втрату контролю та гнучкість, і вони більшість, звичайно, не виправдовують ціну, що вона вища. RDS є певним чином сексуальним, але ви в кінцевому рахунку не можете довіряти тому, що ви не можете в кінцевому рахунку виправити, оскільки ви не можете дістатися до всіх рухомих частин.
Мені не подобається мати SUPERпривілей. Мені не подобається, що я не можу створити хвіст журналу помилок. Мені не подобається, що я не можу запустити "top" або "iostat" на моєму сервері баз даних, щоб побачити, як ядра та накопичувачі насолоджуються навантаженням. Мені не подобається не мати доступу до двигуна федеральної пам’яті. Мені не подобається думка платити за гарячу резервну машину резервного резервування (кілька AZ), яку я навіть не можу використовувати як репліку читання. Звичайно, є цілком розумні пояснення, чому всі ці обмеження повинні бути встановлені, щоб MySQL був успішно упакований і проданий як RDBMS-in-a-box. Єдине, що RDBMS в коробці "вирішує" цілу низку проблем, яких у мене немає ... і стає на шляху, викликаючи нові проблеми.
Але абсолютним вимикачем угод для RDS є повна відсутність доступу до бінарних журналів та реплікації. Бінлоги, особливо на основі рядків, - це фантастичний інструмент відновлення для незначних катастроф, але вони вам не допоможуть, якщо ви не можете отримати до них доступ. Хочете налаштувати локальний сервер у вашому офісі як репліка читання виробничої бази даних в RDS? Щось взяти з місцевих резервних копій, чи мають звіти мати під рукою для відновлення аварій, чи трапиться щось немислиме з вашими даними, які живуть в RDS? Це ідея, яка одночасно очевидна і геніальна.
На жаль, прямий доступ до реплікації недоступний. Звичайно, ви можете платити за читання реплік ... але лише як інші екземпляри RDS. Не цінні пропозиції у моїй книзі.
Оновлення: одна суттєва зміна RDS для MySQL 5.6
Я все ще вважаю за краще запускати власний сервер (навіть в EC2), а не запускати RDS з ряду причин, включаючи відсутність підтримки визначених користувачем функцій , неможливість використання Fedrated Engine Engine і неможливість мати такий доступне додаткове підключення для аварійного доступу ... проте ...
Amazon внесла суттєві зміни в MySQL 5.6 для RDS, що усуває одне з моїх основних заперечень - можливо, моє найбільше заперечення: бінарні журнали тепер доступні, і ви можете запускати екземпляр, який не є RDS, як ведений, або підключати інші утиліти до сервер, який читає потік бінлог.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html
Офіційно документація вказує на те, що вони це відкривають, щоб ви могли налаштувати підлеглий для здійснення живої міграції - ви синхронізуєте іноземний майбутній головний сервер із наявного екземпляра RDS за допомогою mysqldump, а потім підключаєте його до RDS як підлеглий щоб отримати пряму трансляцію оновлень через потік реплікації, поки ваша програма не буде перенесена на новий головний майстер - але неофіційно ви можете це робити постійно, доки ви не очікуєте, що вони підтримуватимуть вас ... мені здається розумним.
Це було підтверджено в недавньому Вебінарі в розмові, яка починається близько 56:45:
"Ви можете зберігати його у тираженому стані нескінченно ...
"... поки ви берете на себе відповідальність за підтримку реплікації ..."
"Ми не заважаємо вам робити поточну реплікацію, якщо ви цього хочете".
Ця нова можливість була достатньою для мене, щоб відмовитись від заперечення проти використання RDS у наших екземплярах MySQL, що підтримують загальнодоступний веб-сайт, де ми не використовуємо FEDERATEDбагато або взагалі деякі інші речі.
Тому я все ще не за це, але я вже не проти цього, оскільки наявність прямого потоку бінарних журналів змушує мене в кінцевому підсумку контролювати дані в режимі реального часу та відповідальність за те, щоб жодних транзакцій не було загублений у катастрофічному перебої знову зі мною, тому що я як DBA знову контролюю - саме так я і хочу. Якщо третій постачальник не вказує пальцями на нього, або подає позов проти будь-якого іншого, не повертає втрачені дані, якщо вони зникають через чорну діру всередині чорної скриньки.
Здається, керівництву подобається «ідея» RDS і не заперечує проти різниці у вартості, тому ми зараз запускаємо всі нові веб-сайти з RDS за ними.
Зізнаюся, точне та натискання часу в момент відновлення - це приємна особливість у RDS ... вона не змінює та не порушує вашу існуючу машину - натомість вона запускає абсолютно новий екземпляр, використовуючи резервну копію, найближчим часом до вибраного моменту, а потім застосовує необхідні бінлоги, щоб привести цю нову машину вперед до визначеного вами моменту.
Що стосується цього, але в іншому напрямку, можливо, також зараз використовувати подібну стратегію для переміщення живої бази даних MySQL в RDS ... Ви можете підключити RDS-майстер (імовірно, як правило, це буде щойно розгорнутий екземпляр) як підлеглий існуючої системи, щоб екземпляр RDS мав живу версію даних під час переходу до неї. На відміну від доступу до бінлогів RDS для зовнішньої реплікації, яка працює лише в 5.6, внутрішня реплікація підтримується в RDS, починаючи з 5.5.33 та 5.6.13.