Розгортання нульового простою - схема перехідного ДБ

Досягнення нульового простою розгортання торкнулося цього ж питання, але мені потрібні поради щодо стратегії, яку я розглядаю.

Контекст

Веб-додаток з Apache / PHP для обробки на стороні сервера та MySQL DB / файлова система для постійності.

Зараз ми будуємо інфраструктуру. Все мережеве обладнання матиме надмірність, і всі основні мережеві кабелі будуть використовуватися в з'єднаних парах для відмовок. Сервери конфігуруються як пари з високою доступністю для апаратної відмовостійкості і будуть збалансовані навантаження як для відмов віртуальних машин, так і для загальної продуктивності.

Моя мета - ми можемо застосовувати оновлення до програми без будь-якого простою. Я сильно постраждав при проектуванні інфраструктури, щоб забезпечити 100% час роботи; було б дуже прикро, щоб потім мати 10-15 хвилин простоїв кожного разу, коли застосовується оновлення. Це особливо важливо, оскільки ми маємо намір мати дуже швидкий цикл випуску (іноді він може досягати одного або декількох випусків на день.

Мережева топологія

Це короткий підсумок мережі:

                      Load Balancer
             |----------------------------|
              /       /         \       \  
             /       /           \       \ 
 | Web Server |  DB Server | Web Server |  DB Server |
 |-------------------------|-------------------------|
 |   Host-1   |   Host-2   |   Host-1   |   Host-2   |
 |-------------------------|-------------------------|
            Node A        \ /        Node B
              |            /            |
              |           / \           |
   |---------------------|   |---------------------|
           Switch 1                  Switch 2

   And onward to VRRP enabled routers and the internet

Примітка: сервери БД використовують реплікацію master-master

Пропонована стратегія

Щоб досягти цього, я зараз думаю розбити сценарії оновлення схеми БД на дві частини. Оновлення виглядатиме так:

1. Веб-сервер у вузлі А знімається в режимі офлайн; трафік продовжує оброблятися веб-сервером на вузлі B.
2. Зміни перехідної схеми застосовуються до серверів БД
3. Веб-сервер Оновлена ​​база коду, очищаються кеші та вживаються будь-які інші дії з оновлення.
4. Веб-сервер A розміщено в Інтернеті, а веб-сервер B - в автономному режимі.
5. Оновлено базу кодів веб-сервера B, очищаються кеші та вживаються будь-які інші дії з оновлення.
6. Веб-сервер B представлений в Інтернеті.
7. Остаточні зміни схеми застосовуються до БД

"Перехідна схема" буде розроблена для встановлення сумісної БД з перехресними версіями. В основному це використовує представлення таблиць, що імітують стару схему версії, тоді як сама таблиця буде змінена на нову схему. Це дозволяє старій версії взаємодіяти з БД як звичайна. Імена таблиць включають номери версій схеми, щоб гарантувати, що не буде плутанини щодо того, в яку таблицю писати.

"Кінцева схема" видалить зворотну сумісність і налагодить схему.

Питання

Словом, чи спрацює це?

більш конкретно:

1. Чи виникнуть проблеми через потенціал для одночасних записів у конкретній точці зміни перехідної схеми? Чи є спосіб переконатися, що група запитів, що модифікують таблицю і створюють сумісний з видом назад, виконуються послідовно? тобто будь-які інші запити утримуються в буфері до тих пір, поки зміни схеми не будуть завершені, які, як правило, становлять лише мілісекунди.

2. Чи існують більш прості методи, які забезпечують цей ступінь стабільності, а також дозволяють оновити без простою? Також бажано уникати "еволюційної" стратегії схеми, оскільки я не хочу замикатися на зворотному сумісності схеми.

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

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

Виробництво одне

Це середовище є вашою поточною реальною версією програмного забезпечення, яке використовується користувачами. У нього є власні веб-сервери, сервери додатків, сервери баз даних та простір таблиць. Він діє незалежно від будь-якого іншого середовища. Балансир завантаження, який володіє кінцевою точкою роздільної здатності домену для цих служб, в даний час вказує на ці веб-сервери.

Виробництво два

Це, в основному, середовище інсценізації випуску, ідентичне виробництву One. Ви можете здійснити оновлення випусків тут і зробити тести на корисність перед початком події. Це також дозволяє безпечно виконувати зміни вашої бази даних у цьому середовищі. Балансир навантаження зараз не вказує на це середовище.

Виробництво ДР

Це ще один дублікат в окремому центрі обробки даних, який знаходиться в іншому регіоні світу. Це дозволяє вам перебоїтись у разі катастрофічної події, виконавши перемикач DNS на балансовому завантаженні.

Йти жити

Ця подія суттєво оновляє запис DNS, щоб перейти до виробництва два від виробництва один або навпаки. Потрібно деякий час, щоб розповсюдитись на всіх серверах DNS у всьому світі, щоб ви залишали обидва середовища деякий час. Деякі користувачі МОЖУТЬ працювати в існуючих сесіях над старою версією вашого програмного забезпечення. Більшість користувачів налаштовуватимуть нові сесії на оновленій версії програмного забезпечення.

Міграція даних

Єдиним недоліком тут є те, що не всі дані під час цього вікна доступні для всіх користувачів на той час. У базі даних попередньої версії чітко важливі дані користувачів, які тепер потрібно безпечно перенести на нову схему бази даних. Це може бути досягнуто за допомогою добре перевіреного сценарію експорту та міграції даних або пакетної роботи або подібного процесу ETL.

Висновок

Після того, як ви повністю завершите свою подію випуску, виробництво Two тепер є вашим основним, і ви починаєте працювати над встановленням наступного випуску в Production One для наступного циклу розгортання.

Недоліки

Це складна установка середовища, і для її успішного використання потрібна велика кількість системних ресурсів, часто в два-три рази. Керувати цим способом може бути дорого, особливо якщо у вас дуже великі системи важкого використання.

Ваша стратегія є надійною. Я б тільки запропонував розглянути можливість розширення «Перехідної схеми» на повний набір «таблиць транзакцій».

За допомогою таблиць транзакцій SELECT (запити) виконуються проти нормалізованих таблиць, щоб забезпечити правильність. Але всі ІНШЕРТИ, ОНОВЛЕННЯ БІЛЬНОГО ЗАБЕЗПЕЧЕННЯ та ВИДАЛЕННЯ завжди записуються в денормалізовані таблиці транзакцій.

Тоді окремий паралельний процес застосовує ці зміни (можливо, використовуючи Збережені процедури) до нормалізованих таблиць відповідно до встановлених бізнес-правил та вимог схеми.

Здебільшого це було б практично миттєво. Але розділення дій дозволяє системі пристосувати надмірну активність та затримки оновлення схеми.

Під час змін схеми в базі даних (B) оновлення даних активної бази даних (A) потраплять до її таблиць транзакцій і негайно застосовуються до її нормалізованих таблиць.

Після відновлення бази даних (B) транзакції з (A) будуть застосовані до неї, записавши їх у таблиці транзакцій (B). Після того, як ця частина виконана, (A) можна буде збити і зміни схеми застосувати там. (B) закінчив би застосовувати транзакції з (A), одночасно обробляючи свої транзакції, які були б у черзі, як і (A), і "живі" будуть застосовані так само, коли (A) повернувся.

Рядок таблиці транзакцій може виглядати приблизно так ...

| ROWID | TRANSNR | DB | TABLE | SQL STATEMENT
    0        0       A    Name   INSERT INTO Name ...
    1        0       A    Addr   INSERT INTO Addr ...
    2        0       A    Phone  INSERT INTO Phone ...
    3        1       A    Stats   UPDATE Stats SET NrOfUsers=...

"Таблиці" транзакцій насправді можуть бути рядками в окремій базі даних NoSQL або навіть послідовних файлах, залежно від вимог до продуктивності. Бонус полягає в тому, що кодування програми (в даному випадку веб-сайту) стає трохи простішою, оскільки вона пише лише в таблиці транзакцій.

Ідея слідує тим самим принципам, що і бухгалтерія з подвійним записом, і з подібних причин.

Таблиці транзакцій є аналогом бухгалтерського "журналу". Повністю нормалізовані таблиці є аналогом бухгалтерського «бухгалтерії», при цьому кожна таблиця є дещо схожою на «рахунок» бухгалтерського обліку.

У бухгалтерії кожна транзакція отримує два записи в журналі. Один для облікового запису "списана", а інший для "зарахованого" рахунку.

У RDBMS "журнал" (таблиця транзакцій) отримує запис для кожної нормалізованої таблиці, яку слід змінити цією транзакцією.

Стовпчик БД на наведеній вище таблиці таблиці вказує, з якої бази даних походить транзакція, що дозволяє фільтрувати рядки в черзі з іншої бази даних, а не повторно застосовувати їх, коли повертається друга база даних.