Дерекқорды үзіліссіз көшіру: репликация, ауыстыру, кері оралу

Міндет және табыс критерийлері: не есептеледі үзіліс ретінде

Дерекқордың тоқтауы бизнестің ойлағанынан гөрі үлкен соққы береді. Сатылымдар мен өтініштер жоғалуы, қызметкерлердің CRM/ERP-та жұмыс жасай алмауы, дүкендер мен қоймалардың тоқтауы, клиенттерге қателер көрсету — бәрі мүмкін. Тіпті негізгі қосымша тез қайта жүктелсе де, есептер, бухгалтериямен алмасу, төлем шлюздері мен сыртқы сервистер жиі бұзылады. Сондықтан миграция басталмас бұрын не үзіліс саналатынын және қандай деңгейге шыдауға дайын екеніңізді нақты келісіңіз.

«Дерекқорды үзіліссіз көшіру» практикасында «ештеңе өзгермейді» дегенді білдірмейді. Бұл — пайдаланушылар маңызды операцияларды орындай беретін жағдайды сақтау және деректер жоғалту мен қалпына келтіру уақытын алдын ала шектеу дегенді білдіреді. Кейде шағын деградацияға рұқсат етіледі: есептер баяулайды, фондық тапсырмалар уақытша тоқтайды, деректер витриналары кешігеді. Бірақ төтенше түрде тоқтатуға болмайтын тізімді (мысалы, төлем қабылдау, тапсырыс рәсімдеу, пациент жазу, авторизация) алдын ала бекітіп алу керек.

Миграция басталмай тұрып, қандай жүйелер әсер ететінін тізіп шығыңыз: негізгі қосымша мен API, есептер мен BI, интеграциялар мен кезектер (мысалы, 1С-пен алмасу, ESB, сыртқы серіктестер), фондық жұмыстар, админ-панельдер және мониторинг.

Табыс критерийлерін RPO және RTO арқылы қарапайым тілмен түсіндіру ыңғайлы:

• RPO (Recovery Point Objective) — ең жаман жағдайда қанша деректі жоғалтасыз деп есептейсіз. Мысалы: «өзгерістер 30 секундтан аспауы керек» немесе «деректер жоғалмауы керек».
• RTO (Recovery Time Objective) — жүйе ауысқаннан немесе сәтсіздік болғаннан кейін қанша уақытта қалыпты жұмысқа оралуы керек. Мысалы: «барлық негізгі операциялар 5 минут ішінде қолжетімді».

Екі көрсеткіш бизнес-жетекшімен және IT-мен келісілгеннен кейін репликация түрін, тексерулердің терезесін және қолданушыға байқалмай ауысуға болатынын бағалау оңайырақ болады.

Инвентаризация: бастамас бұрын не жинау керек

Дерекқорды үзіліссіз көшіру репликациядан басталмайды — ол нақты бастапқы деректерден басталады. Нені көшіріп жатқанын және оның қалай қолданылатынын білмесеңіз, тәуекелдерді есептеп, ауысу тәсілін таңдай алмайсыз.

Базалардың тізімі мен параметрлерін жинаңыз: қозғалтқыш пен нұсқасы, диск көлемі, кестелер саны, ірі объектілер (индекстер, партициялау, LOB), сондай-ақ соңғы 3–6 айдағы өсу қарқыны. Жылдам өсетін нәрсені бөлек белгілеңіз: деректер, индекстер, транзакция журналдары, уақытша файлдар.

Жүктеме профилін нақты цифрлармен бекітіңіз, жалпылама сипаттама емес. Әдетте қажет: шыңдық RPS/QPS, оқу мен жазудың үлесі, ең ауыр сұраулар, орташа жауап уақыты мен 95-процентиль. Егер жүйе 24/7 жұмыс істесе, «тың» уақыттың жоқтығы жиі анықталады, бұл свитч уақытын және репликация баптауларын әсер етеді.

Келесі — тәуелділіктер. Дерекқор жалғыз тұрған жоқ: қосымшалар, фондық воркерлер, кезектер, ETL, есептер, сыртқы интеграциялар. «Көрінбейтін» тұтынушыны ұмытпау үшін қысқа реестр жасау пайдалы.

Құжатта кемінде болуы керек:

• базалар мен нұсқалар, көлемдер, өсім, диск талаптары;
• жүктеме шыңдары және критикалық сұраулар;
• тәуелділіктер және қосылу нүктелері (байланыс жолдары, сервис аккаунттар);
• сақтық көшірмелер: түрлері, кестесі, қайда сақталады, қаншалықты тез қалпына келтіріледі;
• шектеулер: өзгерістер терезелері, рұқсаттар, реттеуші талаптар және аудит.

Ағымдағы тосын орындарды және сақтық көшірмелердің нақты дайындық деңгейін тексеріңіз. Қарапайым тексеру: бір базаны таңдап, бөлек стендте тестілік қалпына келтіру жүргізіп, уақытын өлшеу.

Соңында ұйымдастырушылық шектеулерді анықтаңыз: кім продқа рұқсат береді, кім өзгерістерді бекітеді, сертификаттар шығару немесе порттарды ашу қанша уақыт алады. Осындай ұсақ-түйектер жиі кестені жылжытады.

Әдісті таңдау: репликация және ауысу стратегиясы

Үзіліссіз көшіру үшін алдымен репликация түрін таңдап, ауысу (свитч) қалай өтетінін түсіну керек. Бұл кезеңдегі қателік жазулардың ұзақ «тоңдырылуына» немесе күтпеген үйлесімсіздіктерге әкелуі мүмкін.

Физикалық репликация файлдар мен транзакция журналдары деңгейінде база көшірмесін жасайды. Ол көбінесе қарапайым және жылдам, үлкен деректер көлеміне және стандартты жоғары қолжетімділік сценарийлеріне сай келеді, бірақ СУБД нұсқаларының жақындығын және сақтау түрінің ұқсастығын талап етуі мүмкін.

Логикалық репликация өзгерістерді кесте және операциялар деңгейінде тасымалдайды. Ол нұсқаны жаңарту, деректерді ішінара көшіру немесе схема өзгерісі кезінде икемдірек, бірақ баптауы күрделі және триггерлер, реттіліктер, DDL сияқты шеттерге сезімтал.

Репликация бағыты бойынша біржақты және екіжақты болады. Біржақты — миграция үшін қарапайым және қауіпсіз: бір дереккөз және бір мақсат. Екіжақты — екі жаққа жазуды талап еткен жағдайда көмектеседі, бірақ конфликтілерді едәуір күрделендіреді. Тағы бір нұсқа — репликалардан оқу: қосымша репликадан оқиды, ал жазуды мастерге жібереді. Бұл негізгі көзге жүктемені азайтады, бірақ көшіру кешігуін ескеру қажет.

Таңдау алдында практикалық сұрақтарға жауап беріңіз:

• СУБД нұсқасын немесе сақтау түрін (локалды диск, SAN, әртүрлі SSD класы) ауыстыру керек пе?;
• журналда шыңдар жасайтын ауыр жазулар (батчтер, есептер) бар ма?;
• репликаларда оқу кешігуі (секундтар) пайдаланушылар үшін қабылдауға болады ма?;
• кодировкалар, collation және уақыт баптауларын бірдей ету мүмкін бе?

Желі жиі жасырын шектеу болады. Тұрақты репликация үшін болжамды кешігу, жеткілікті өткізу қабілеті және трафик шифрлауы қажет. Егер көшірме сайттар арасында өтсе, алдын ала RTT өлшеп, MTU тексеріп, приоритеттерді орнатып, қызмет көрсетудің терезесінің ретрайлерге кетпейтінін тексеріңіз.

Свитч күрделілігін былай бағалауға болады:

• қанша қосымша мен интеграциялар дерлік тікелей БД-ға қосылады және параметрлерді жылдам ауыстыруға бола ма;
• фондық тапсырмалар мен кезектер екі рет жұмыс істеуі мүмкін емес пе;
• жазуды тоқтатып, реплика кешігінен нөлге дейін күту қаншалықты тез мүмкін (RPO нөлге жақын болу);
• ұқсас жүктемеде сынақтық свитч жасауға бола ма.

Көбінесе жаңа площадкаға және сол уақытта СУБД нұсқасын жаңартуға дайындалып жатса, логикалық немесе аралас тәсіл таңдалады. Нұсқалар сәйкес келсе және жылдамдық маңызды болса, физикалық репликация ең қысқа және түсінікті свитч береді.

Қадамдық көшіру жоспары: дайындықтан свитчке дейін

Мақсатты ортаны алдымен дайындаңыз. Ол ағымдағы базаның жүктемесін көтере алуы керек: CPU, жад, диск (IOPS және кешігулер), желі, сақтық көшірме және мониторинг. Рұқсаттарды тексеріңіз: қосымша есептері, құпияларға қолжетімділік, firewall ережелері, әкімші рөлдері және финалдық ауысуды кім жүзеге асыра алатыны.

Содан кейін репликация орнатылады және бастапқы синхрондау орындалады. Қай режим қажет екенін алдын ала шешіңіз: асинхронды (ұзақ қашықтықта және жоғары жүктемеде оңайырақ) немесе синхронды (деректер жоғалу ықтималдығы төмен, бірақ желі талаптары жоғары). Бірінші залив кезінде журналдар дискіні толтырмауы және негізгі жүйенің өнімділігі төмендемеуі үшін қадағалаңыз.

Репликация ағымдағы базаға жеткенде, параллельді жүгіруге көшіңіз. Идеал — жаңа базаны «көлеңке» ретінде жүктеу: оқулардың бір бөлігін ауыстыру, типтік операцияларды тестілік контурда қайталау немесе қосымша арқылы жазуды дубликациялау. Мақсат — индекстер, локтар, жад баптаулары және жауап уақытындағы мәселелерді табу.

Свитчке дайындық кезінде сәйкестік мәселелерін жабыңыз. Схеманы, кеңейтімдердің нұсқасын, collation/уақыт белдеу баптауларын, барлық job-тарды, триггерлерді және рұқсаттарды тексеріңіз. Деректер үшін негізгі кестелер бойынша контрольді соммаларды және бизнес көрсеткіштердің іріктемелі салыстыруларын (мысалы, қорлар, тапсырыс статустары, баланс) пайдаланыңыз.

Осы сәтке дейін қысқа рольдер жоспары болуы қажет:

• кім командалық каналды жүргізіп, оқиғалар уақытын жазады;
• кім репликация мен лагқа жауапты;
• кім қосымшаны және негізгі сценарийлерді тексереді;
• кім go/no-go шешімін қабылдайды және свитчті бастайды;
• кім метрикаларды және қателерді бақылайды.

Егер инфрақұрылым 24/7 жұмыс істесе, «арнайы бақылау» терезесін және байланыста болатын адамдар тізімін алдын ала бекіту пайдалы (қолдау және өнім иесін қосқанда). Бұл ауысу күніндегі кідіріс тәуекелін азайтады.

Ауыстыру алдындағы тесттер: жұмысқа жарамдылық пен жылдамдық

Свитчке дейін екі нәрсені дәлелдеу қажет: жаңа базада бәрі ескі сияқты жұмыс істейді және жүйе баяуламайды. Егер мақсатыңыз — үзіліссіз көшіру, қателерді талқылауға уақыт болмайды.

Функционалдық тесттер: не өтуі тиіс

Ең жиі және қателігі үлкен операциялардан бастаңыз. Барлығын емес, бизнеске нақты әсер ететіндерді тексеріңіз: пайдаланушы кіруі, негізгі құжаттарды жасау және өзгерту, есептердің жабылуы, басып шығару және экспорттар, фондық жұмыстар.

Жақсы тәсіл — бірдей әрекеттер жиынтығын ескі базада және репликада орындап, нәтижесін (сандар, статустар, сомалар) салыстыру. Егер есептер болса, 2–3 «эталон» есепті бірдей деректер кескінде тексеріңіз.

Өнімділік тесттері: метрикалар мен шектер

Өнімділікті ұғымдық метрикалармен бағалау оңайырақ. Алдын ала свитч тыйылатын шектерді келісіңіз:

• 5–10 негізгі сұраудың жауап уақыты;
• шың уақыттағы p95 жауап уақыты (мысалы, қосымша логтарынан);
• дерекқор серверінің CPU және диск жүктемесі;
• кезектердің, локтардың немесе күту уақыттарының өсуі;
• қосымша мен дерекқор арасындағы желі өткізу қабілеті.

Репликация кешігуін бөлек тексеріңіз. Егер жүктеме кезінде лаг өссе, бұл апат немесе қатал ауысу кезінде деректер жоғалтудың тікелей қаупі.

Шағын төзімділік тесті қажет: түйінді имитациялап құлатып, репликация қанша уақытта қалпына келетінін және қосымша не көретінін тексеріңіз. Оны өндірістікге ұқсас стендте орындаңыз.

Соңында нәтижелерді бекітіңіз және дайындықты растайтын құжаттарды толтырыңыз:

• тесттер тізімі мен нақты цифрлар;
• келісілген шектер және олардың өту фактісі;
• ағымдағы репликация лагы және RPO/RTO бағасы;
• белгілі шектеулер (нені тексермегеніңіз және неліктен);
• «ауыстыруға болады» деген шешім және оны қабылдайтын тұлға.

Үзіліссіз ауыстыру: әрекет тәртібі мен бақылау

Ауыстыру — негізгі жұмыстың жаңа базаға ауысатын қысқа сәті. Оны күтпеген жайттарға айналдырмау үшін табыстың критерийлерін және свитч кезеңіндегі қабылданатын өзгерістерді алдын ала бекітіңіз.

Ең маңыздысы — өзгерістерге «тоқтату» режимін енгізу. Бұл толық тыйым емес, басқарылатын терезе: уақытша қауіпті операцияларды тоқтатып, қосымшалардың нұсқаларын бекітіп, админ панельдерде қолмен түзетулерді шектеу.

Свитч кезіндегі әрекеттер тәртібі

Логика қарапайым: алдымен жазуды қорғаймыз, сосын оқуды аударамыз, және тек одан кейін фондық жұмыстарды қайта қосамыз.

• Қосымшаларды басқарылатын режимге ауыстырыңыз: фондық жұмыстарды, жазатын кезектер мен интеграцияларды тоқтатыңыз.
• Репликацияның дереккөзге жеткенін күтіп, нөлдік лагты тіркеңіз (уақыт, LSN/GTID, журнал нөмірі — СУБД-ңызға лайықты көрсеткіш).
• Жазуды жаңа БД-ға аударыңыз (немесе жаңа primary тағайындаңыз) және жаңа транзакциялар тек сонда пайда болатынын тексеріңіз.
• Оқуды аударыңыз: read-only қызметтер, есептер, кэшті жылыту, содан кейін пайдаланушылық сұраулар.
• Фондық тапсырмаларды бір-бірлеп қосыңыз, ең қауіпсізінен бастап, және жүктеменің өсуін бақылыңыз.

Қосылу параметрлерін өзгерту алдын ала болжамды болуы тиіс: DNS/виртуалдық IP, біртұтас байланыс жолы, бірдей аккаунттар және рұқсаттар. Егер қосылым пулдарын пайдалансаңыз, қысқа TTL орнатып, қосымшаның қосылуын автоматты түрде жасай алатынына сенімді болыңыз.

Алғашқы сағаттарды бақылау

Алғашқы 1–2 сағат ішінде әр 15 минут сайын метрикаларды тексеріп, ауысу журналына жазып отырыңыз.

• Қосымша қателері: 5xx саны, таймауттар, транзакция және лок қателері.
• Дерекқор өнімділігі: p95/p99 кешігулер, кезектердің ұзындығы, CPU/IO, локтау бәсекелестігі.
• Деректер тұтастығы: негізгі нысандар есептері, критикалық кестелердің жаңалығы, фондық өңдеулердің дұрыстығы.
• Репликация/сақтық: егер екі жақты репликация болса, артқа бағыттағы статус, сақтық көшірменің өзектілігі.

Жұмыстар жүктеме тұрақты болғанда, қателер қалыпты деңгейге оралғанда және негізгі бизнес-операциялар орындалғанда аяқталған деп есептеуге болады. Дереккөз резервке шығарылған немесе жазудан мүлдем оқшауланған болуы тиіс.

Кері оралу жоспары: бұрыс болғанда не істеу

Кері оралу — «сәтсіздік» емес, жүйені тезірек тұрақты күйге қайтарудың алдын ала келісілген тәсілі. Жақсы кері оралу жоспарының нақты триггерлері, шешім қабылдайтын жауаптысы және қысқа қайтару жолы болуы керек.

Триггерлерді ауысу күнінен бұрын бекітіңіз — олар талқылауға келмейтін өлшенетін сигналдар болуы тиіс: қосымша қателерінің көбеюі, кешігу шегінің асып кетуі, деректер арасындағы айырмашылықтар, негізгі операцияның (кіру, төлем, тапсырыс) орындалмауы немесе жаңа жақтағы сақтық көшірменің жұмыс істемеуі.

«Кері свитчті» негізгі сценарий сияқты мұқият ойластырыңыз. Көбінде ол жазуды қайтадан ескі жерге аудару (конфиг беру, балансирлеу, DNS, баптау тұтқасы) және жаңа базада жазуды дереу блоктаумен шектеледі, екі жаққа жазудың алдын алу үшін.

Егер кері оралу қажет болса, жаңа базаға түскен өзгерістермен не істеу сұрағы туындайды. Негізгі нұсқалар:

• критикалық операцияларды уақытша тоқтату, айырмашылықтың өсуіне жол бергенін тоқтату;
• жаңа базадағы өзгерістерді бөлек журналға сақтау (кесте, экспорт, хабарлар кезегі) кейінгі қайта толтыру үшін;
• уақыттық/LSN нүктесін белгілеп, журналдарды сақтап қою, кейін оқиғаларды ұқыпты қайта ойнату үшін.

Кері оралу туралы шешімді бір жауапты адам қабылдауы тиіс (дежурный жетекші). Статус дереу жазылады: уақыт, себеп, ауысу нүктесі, жасалған әрекеттер және командаға қандай әрекеттерге тыйым салынғаны.

Кері оралудан кейін дұрыстығын тексеру қажет. Мінімум: қосымша қайтадан ескі базада жазады, негізгі сценарийлер орындалады, фондық тапсырмалар жұмыс істейді, метрикалар қалыпқа оралды, және ауысу уақыты ішінде түскен деректер жоқ не журналда сақталған түрде кейін толтырылады.

Миграция кезінде жиі кездесетін қателіктер мен тұзақтар

Репликация бапталған және свитч қарапайым көрінсе де, проблемалар көбіне дерекқордың айналасында пайда болады. Үзіліссіз көшіру кезінде кішігірім келісілмеген деталь немесе «кейін тексереміз» деген ой инцидентке әкелуі мүмкін.

Жиі кездесетін қателер:

• тәуелділіктерді ұмыту: кезектер, жоспарлаушылар, есептер, сыртқы интеграциялар, кэш, файл сақтау. Нәтижесінде «қосымша жұмыс істейді», бірақ төлемдер өтпейді немесе есептер құрылмайды.
• репликация кешігуді өлшемей свитч жасау. Егер кешігушілік 30–60 секунд болса, соңғы жазбалар жоғалып кетуі немесе сәйкессіздіктер пайда болуы мүмкін.
• пиковые жүктемелер кезінде тест жасамай «көзбен» тексеру. Жаңа сервер таңертең жылдам көрінуі мүмкін, ал 11:00-де таймауттар мен локтар басталады.
• рұқсаттарды өте соңғы сәтте тексеру: қосымша қолданушысының құқықтары, подсеттерден қолжетім, сертификаттар, firewall ережелері, DNS, шифрлау параметрлері. Соңғы минуттағы түзетулер қатерлі болады.
• жауаптыларды тағайындамау және коммуникацияны ойластырмау. Қайда мәселе шықса, кім тоқтатады, кім кері оралу жасайды, кім бизнеске хабарлайды — ешкім белгісіз болса, хаос туындайды.

Осы тұзақтарды тауып алу үшін «D-день» сценарийін тесттік контурда өткізу пайдалы: репликация лагын өлшеу, типтік операцияларды өткізу және міндетті түрде пик симуляциясын жасау. Инфрақұрылымды жеткізуші бар болса да, желіні, рұқсаттарды және нақты жүктеме профилін тексеру міндетті.

Тәуекелді азайту үшін қарапайым ережелер жинағын ұстаңыз: тәуелділіктер мен олардың иелерін бекітіңіз, свитчке дейін репликация метрикаларын алыңыз және қабылданатын максимумды келісіңіз, мақсатты орталықта жүктеме тестін өткізіңіз, ал рұқсаттар мен сертификаттарды жұмыстарға бірнеше күн бұрын тексеріңіз.

Ауыстыру күні алдындағы қысқа чек-лист

Ауыстыру күні уақыт тез өтеді, және қателіктер көбіне келісілмегендіктен болатындықтан, бұл чек-лист үзіліссіз көшіруді тыныш өткізеді.

Алдымен бизнестің күтулерін бекітіңіз. RPO мен RTO нақты сандармен және жазбаша келісілген болуы тиіс: қанша деректі жоғалтса болады және ауысу режимі қанша уақытқа созыла алады.

Содан кейін ұйымдастырушылық бөлігі: әр тәуелділіктің иесі болу және ауысу күнінде байланыс әдісі анықталған болу керек. Сағат сайын бір есеп жасайтын есепкер секілді «кіші» процесс жоспары жиі барлығын бұзады.

Ауыстыру алдындағы орындауды белгілеңіз:

• RPO және RTO келісілген, жұмыс терезесі және коммуникация ережелері бекітілген;
• тәуелділіктер тізімі (қосымшалар, интеграциялар, есептер, жоспарлаушылар) жиналған, иелері тағайындалған және қолжетімді;
• мониторинг пен алерттер екі жақта да қосылған: репликация лагы, қателер, жүктеме, бос орын, жауап уақыты;
• мақсатты ортада өнімділік тесттері жүргізілген, шектер бекітілген (мысалы, «кіру 2 секундтан астам емес», «есеп 30 секундтан артық емес»);
• кері оралу жоспары сипатталған және тестіленген тесттік ортада.

Соңғы тексеріс — 10–15 минуттық «сухой прогон»: команда жоғары дауыспен әрекет тәртібін және бақылау нүктелерін айтады. Реплика доганғанын кім растайды, қосымшаны кім ауыстырады, алғашқы бақылауларды кім жүргізеді, пайдаланушыларға кім хабарлайды — бәрі анық болуы керек.

Мысал сценарий: 24/7 жүйесіне дерекқорды көшіру

Мысалға CRM мен биллингі тәулік бойы жұмыс істейтін компанияны алайық. Күні бойы сатылымдар мен қолдау сұраныстары келеді, түнде есептер мен төлемдер шығады. Базаны 15 минутқа тоқтату мүмкін емес: бұл уақытта интеграцияларда қателер пайда болады және тапсырмалар кезегі өседі.

Олар репликация әдісін таңдайды: жаңа серверде БД орнатылады және ағымдағы базадан үздіксіз өзгерістер жіберіледі. Пайдаланушылар ескі жүйеде жұмыс істеп тұрған кезде параллель тестілеу жүргізіледі. Ауыстыру әдетте жүктемесі төмен түнгі уақытта жоспарланады, бірақ команда байланыста болады.

Көшірмені қалай тестілеу және пайдаланушыларға кедергі келтірмеу

Тесттер жаңа базаның көшірмесінде (немесе read-only репликада) өткізіледі, ол жұмыс базасына артық жүк түсірмеу үшін. Шынайы жағдай үшін свежий деректер кескінін алып, типтік тізбектерді іске қосады: клиент іздеу, мәміле жасау, шот шығару, төлемді өткізу, есеп экспорттары.

Қалыптасқан тәжірибе бойынша:

• жүктеме жүгін төмендетілген терезелерде жүргізеді;
• ең ауыр есептер мен фондық жұмыстарды тексереді;
• негізгі сұраулардың нәтижесін және блокировкаларды салыстырады;
• интеграцияларды тексереді: төлем шлюзі, телефония, пошта, бухгалтериямен алмасу.

Метрикалар бойынша ауысу шешімі

Свитч шешімі сезіммен емес, цифрлармен қабылданады. Мысалы: репликация лагы бірнеше секунд шегінде, критикалық операциялардың жауап уақыты ағымдағыдан нашар емес, логтарда қателер жоқ, және түнгі жүктеме прогоны CPU, диск және желі бойынша қор жеткіліктілігін көрсетеді.

Ауыстыру алдындағы қысқа жазуды тоқтату (әдетте минуттар): деректерді өзгерте алатын операцияларды уақытша бұғаттап, реплика нөлдік догануға жеткенін күтіп, бақылау метрикаларын тіркейді (негізгі кестелердегі жазбалар саны, контрольді соммалар, кезектер статустары).

Кері оралу да нақты: егер қателер өссе немесе жылдамдық күрт төмендесе, қосымшаны ескі базада қайта бағыттайды және жаңа базаны жазуда өшіреді. Жақсы жоспарда бұл 10–20 минутты алады: байланыс конфигін қайтару, пайдаланушылардың қайтадан ескі базада жазуын тексеру және жаңа жүйеге кірген деректер тізімін тіркеу.

Келесі қадамдар: жобаны және инфрақұрылымды қалай дайындау

Үзіліссіз көшіру көбінесе әрекеттердің үйлесімділігіне тіреледі. Бизнес-жетекші қандай операцияларға рұқсат берілетінін және ауысу күнінде қандай метрикалар табыс саналатынын хабарлауы тиіс (мысалы, пакет жүктеулерді уақытша тоқтату).

Содан соң жұмыс тобы жинап, жұмыстар уақытында байланыс ережелерін келісіңіз: бір канал, бір шешім қабылдаушы, өзгерістерді жазып отыру. Әдетте DBA, инфрақұрылым, дамыту, эксплуатация/қолдау және бизнес-жетекші қажет.

Бір жалпы құжат дайындаңыз, ол ауысу алдында да, кейін де өмір сүреді: минуттық кесте, бақылау нүктелері, «ауыстыруға болады» критерийлері, метрикалар (репликация лагы, қателер саны, негізгі операциялардың p95 уақыты) және кері оралу жоспары қатаң шектерімен. Егер кері оралу ауысудан күрделі болса, оны алдын ала жетілдіру керек.

Бірінші тәжірибені тікелей продқа қолданбаңыз. Тесттік контурда толық сценарийді репетициялаңыз: қосымша конфигурацияларын ауыстыру, рұқсаттарды тексеру, кэшті жылыту және кері оралу.

Инфрақұрылымды мақсатты жүктеме мен 12–24 айға өсімді ескере отырып таңдаңыз: CPU, жад, дисктердің IOPS пен кешігулері, желі, бөлек каналдар репликация үшін, сақтық көшірме және қалпына келтіру. Егер жаңа площадканы критикалық сервистерге дайындасаңыз, кейде «темір» мен интеграцияны бір орында жинау ыңғайлы — мысалы, GSE.kz (gse.kz), Қазақстанда серверлер шығарып, 24/7 интеграция және қолдау көрсетеді.