Есеп жүйесі әкімшісіне арналған PostgreSQL-ге көшіру

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

Салыстыру нақты болу үшін жергілікті серверде орнатылған әдеттегі Microsoft SQL Server жүйесін аламын. Егер басқа коммерциялық ДҚБЖ қолдансаңыз, экрандар мен рәсім атаулары өзгеше болады, бірақ тексерілетін сұрақтар сол күйінде қалады: серверді кім жаңартады, сұраулар тарихы қайда сақталады, дерекқор таңдалған уақытқа қалай қалпына келтіріледі және түнгі қоңырауды кім қабылдайды. Көшірудің шын құнын осы жауаптар көрсетеді.

ДҚБЖ ғана емес, жауапкершілік шекарасы өзгереді

Әкімші үшін басты өзгеріс мынада: дайын шешімдер жинағы құжаттап, өзара байланыстыру қажет архитектураға айналады. PostgreSQL сервердің өзін, жүйелік көріністерді, журналдарды, pg_dump, pg_restore, pg_basebackup утилиталарын және ағындық репликация тетіктерін береді. Бірақ сақтық көшірме қоймасын, істен шыққанда ауыстыратын диспетчерді, ескерту жүйесін, WAL сақтау мерзімін және қолдау жеткізушісін сіздің орныңызға таңдамайды.

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

Жаңа ортаны жобаламас бұрын ескі ДҚБЖ байқатпай атқарған қызметтердің тізімін жасаңыз. Оған агент тапсырмалары, хабарлама жіберу, байланысқан серверлер, шифрлау, сертификаттарды басқару, жоспарлар тарихы, аудит, журнал тазалау және корпоративтік сақтық жүйесімен бірігу кіруі мүмкін. Әр тармақтың көшкеннен кейін керегін, оны не алмастыратынын және алмастыруды кім тексеретінін шешіңіз. Ұмыт қалған түнгі дерек алмасу тапсырмасы кіруді қабылдау сынағында көрінбейді, оны пайдаланушылар алғашқы жұмыс күнінен кейін таңертең байқайды.

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

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

Күнделікті қызмет көрсету анық көрінеді

PostgreSQL түсініксіз рәсімдерді емес, кестелердің, транзакциялардың және дискілердің күйін жақсырақ түсінуді талап етеді. Күнделікті жұмысқа әдетте қосылымдарды, құлыптарды, репликацияны, дерек көлемінің өсуін, WAL-ды, журналдарды, сақтық көшірме тапсырмаларын және фондық тазалауды бақылау кіреді. Көп тексеріс бір интерфейстің ішінде емес, SQL сұраулары мен метрикалар арқылы орындалады.

Әкімші postgresql.conf, pg_hba.conf, рөлдер, pg_stat_* жүйелік көріністері және сервер журналына сенімді жұмыс істей білуі керек. Кей параметр конфигурацияны қайта оқығаннан кейін қолданылады, ал кейбіріне серверді қайта іске қосу қажет. Бұл айырмашылық өзгерістер регламентінде жазылмаса, қарапайым түзету іске қосылмай қалады немесе күтпеген тоқтау терезесін туғызады.

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

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

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

Autovacuum бақылаусыз қалмауы керек

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

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

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

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

Тағы бір мәселе қосылымдар пулында жасырылады. idle in transaction күйіндегі сессия зиянсыз көрінуі мүмкін, бірақ ашық транзакция деректердің ескі суретін ұстап тұрады. Мұндай транзакциялардың уақытын шектеңіз, қолданбаны түзетіңіз және олардың жасын бөлек бақылаңыз. Сессияларды кесте бойынша тоқтату ақауды жасырып, пайдаланушының заңды операциясын үзуі мүмкін.

Сақтық көшірмені қалпына келтіру тәсілі анықтайды

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

Белгілі бір уақытқа қалпына келтіру үшін физикалық негізгі көшірме мен архивтелген WAL файлдарының үзілмеген тізбегі қажет. PostgreSQL нұсқаулығы осы тетіктерді анық бөледі: pg_dump логикалық түсірілім жасайды және үздіксіз архивтеуге кірмейді, ал физикалық көшірме мен WAL өзгерістерді таңдалған уақытқа дейін ойнатады. Тізбектің ортасындағы бір сегмент жоғалса, одан кейінгі файлдар бар болғанның өзінде қолжетімді қалпына келтіру нүктесі шектеледі.

pg_basebackup жұмыс істеп тұрған кластерден негізгі көшірме алып, pg_verifybackup тексеретін манифест жасай алады. Манифестті тексеру файлдардың құрамын және бақылау сомаларын растайды, бірақ қалпына келген дананы іске қосуды алмастырмайды. Қолжетімділік қатесі, қате restore_command, жоқ кеңейтім немесе ескерілмеген конфигурация файлы тек оқу-жаттығу кезінде табылады.

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

Дұрыс тексеріс жасыл белгіге қараумен шектелмей, сервисті қалпына келтіруге ұқсауы керек:

1. PostgreSQL-дің дәл сол негізгі нұсқасы бар таза түйін дайындап, қажет кеңейтімдерді орнатыңыз.
2. Соңғы негізгі көшірмені қалпына келтіріп, сақтық қоймасынан WAL беріңіз және бақылау уақытын белгілеңіз.
3. Кластерді оқшауланған желіде іске қосыңыз, recovery аяқталғанын тексеріңіз және жұмысты бастаған сәттен қосылым қабылдағанға дейінгі уақытты өлшеңіз.
4. Есеп жүйесіндегі бақылау нысандарын салыстырыңыз: есептік кезең, құжат саны, алдын ала таңдалған регистрлер қорытындысы және қызметтік рөл құқықтары.
5. Нақты орындалған RPO мен RTO-ны, әр қолмен жасалған қадамның себебін және түзету иесін жазыңыз.

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

Реплика сақтық көшірмені алмастырмайды

Ағындық репликация қолжетімділікті арттырады, бірақ әдетте пайдаланушы қатесін және логикалық бүлінуді де қайталайды. Кестені жою, қате жаппай UPDATE немесе қолданба жазған бүлінген дерек WAL-ға түсіп, резервтік түйінде ойнатылады. Реплика сервер істен шыққанда көмектеседі, ал уақыт нүктесіне қалпына келтіретін архив қате операцияға дейін қайтуға мүмкіндік береді.

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

Автоматты ауысуға сыртқы шешім және негізгі түйінді таңдаудың нақты ережесі қажет. PostgreSQL WAL жібереді және standby түйіндерін қолдайды, бірақ үлестірілген келісім, виртуалды мекенжай, клиенттерді бағыттау және екі негізгі түйіннен қорғау таңдалған архитектураға байланысты. Автоматтандыруға дейін есеп қолданбасының қайта дұрыс қосылатынын, пулдың ескі қосылымдарды тастайтынын және ауысу кезінде жоғалған транзакциялар пайдаланушыға түсінікті нәтиже беретінін тексеріңіз.

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

Соңында бұрынғы негізгі түйінге қайтуды да сынаңыз. Қауіпсіз кері қайтуы жоқ сәтті ауысу апатты келесі жоспарлы жөндеуге ғана жылжытады. Рәсім PostgreSQL-дің жаңа уақыт сызығын, ескі негізгі түйіннің алшақтауын және шарттары орындалса, оны жаңа негізгі көшірме немесе pg_rewind арқылы қайта қосуды ескеруі керек.

Өнімділік диагностикасы жаңа бастапқы өлшемнен басталады

Ескі есептегіштер мен таныс қызмет көрсету жоспарларын PostgreSQL-ге сол күйінде көшіруге болмайды. Microsoft SQL Server жүйесіндегі Query Store сұрау мәтіндерінің, жоспарлардың, орындалу статистикасының және күту түрлерінің тарихын уақыт аралықтары бойынша сақтайды. PostgreSQL-де ағымдағы белсенділік pg_stat_activity арқылы, жинақталған статистика pg_stat_* тобы арқылы көрінеді, ал қалыпқа келтірілген сұраулар тарихын әдетте pg_stat_statements кеңейтімі және сыртқы метрика жүйесі жинайды.

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

Бастапқы өлшемді көшіруге дейін ескі платформада алып, PostgreSQL-де дәл сол бизнес операцияларымен қайталаңыз. Орташаға жақын және баяу орындалуларды, қатар жұмыс істейтін пайдаланушылар санын, оқу мен жазу көлемін, құлып уақытын, дерекқор көлемін және пакеттік тапсырмалар уақытын жазыңыз. Бастапқы өлшемсіз «баяулады» деген сөз естелік туралы дауға айналады. Кэштің қызуын және бірдей дерек көлемін ескеріңіз, әйтпесе жаңа есептің алғашқы орындалуы бұрыннан қызған ескі жоспармен салыстырылады.

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

SELECT pid, usename, state, wait_event_type, wait_event,
       clock_timestamp() - query_start AS running_for,
       left(query, 160) AS query_text
FROM pg_stat_activity
WHERE datname = current_database()
  AND state <> 'idle'
ORDER BY query_start;

SELECT calls, round(total_exec_time::numeric, 1) AS total_ms,
       round(mean_exec_time::numeric, 1) AS mean_ms,
       rows, left(query, 160) AS query_text
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 15;

SELECT relname, n_live_tup, n_dead_tup,
       last_autovacuum, last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 15;

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

Сұрауды тапқаннан кейін қауіпсіз көшірмеде немесе бақыланатын SELECT үшін EXPLAIN (ANALYZE, BUFFERS) қараңыз. ANALYZE параметрі сұрауды шынымен орындайды. Деректі өзгертетін операторды өндірісте іске қосу өзгерісті қайталауы мүмкін, сондықтан тексерісті кері қайтарылатын транзакцияға орап, жанама әсерін түсіну қажет. Жоспарланған және нақты жол санын, буфер оқылымын, біріктіру түрін және жоспар түйіндерінің уақытын салыстырыңыз.

Мәселені кездейсоқ shared_buffers өзгертуден немесе тізбекті сканерлеуді өшіруден бастамаңыз. Алдымен жоспарды, сұрау параметрлерін, дерек көлемін, кесте статистикасын, күту оқиғаларын және операциялық жүйе метрикаларын сақтаңыз. PostgreSQL өзі ішкі көріністермен шектелмей, top, iostat, vmstat немесе олардың баламаларын қарауды ұсынады: SQL мәтіні диск кезегін, түйіндегі жад тапшылығын немесе желі кідірісін жалғыз түсіндіре алмайды.

Қолданба үйлесімділігін нақты жүктемемен тексеріңіз

Үйлесімділік кестелердің сәтті жасалуын ғана емес, дұрыс нәтиже мен қолайлы орындалу уақытын білдіреді. Есеп жүйелері SQL-ды платформа немесе ORM арқылы жиі жасайды, сондықтан бір пайдаланушы есебі әр ДҚБЖ-да басқа жоспар, параметр түрлері және құлыптау тәртібін алуы мүмкін. Қолданба жеткізушісінің қажет PostgreSQL нұсқасын қолдауы міндетті, бірақ бұл сіздің кеңейтімдеріңізді, есептеріңізді және дерек алмасуды сынауды алмастырмайды.

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

Көшірілген деректі екі деңгейде тексеріңіз. Техникалық салыстыру жолдарды санайды, жүктеу қателерін іздейді және таңдалған бақылау сомаларын салыстырады. Пәндік салыстыру қалдықтарды, айналымдарды, жабық кезеңдерді, құжаттар арасындағы сілтемелерді және қолжетімділік құқықтарын растайды. Жалпы жол санының теңдігі жеткіліксіз, бір ұйымның жоғалған жолдарын екіншісінің көшірмелері жауып кетуі мүмкін. Салыстыру ережелерін есеп иесімен алдын ала келісіп, нәтижелерін ауысу хаттамасының бөлігі ретінде сақтаңыз.

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

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

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

Қауіпсіздік пен өзгерістер кезекшіліктің қалыпты бөлігіне кіреді

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

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

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

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

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

Маман аздау, сондықтан команда құрылымы маңызды

PostgreSQL әкімшісін табуға болады, бірақ нарық пен дағды бейіні таныс коммерциялық дерекқордан өзгеше. Мықты маман әдетте Linux, файлдық жүйелер, желі, автоматтандыру, SQL, орындалу жоспарлары, WAL, репликация, сақтық көшірме және қалпына келтіруді біледі. Бір консольдегі дұрыс мәзірді сенімді басқан адам қысқа курстан кейін бұл дағдыларды өздігінен алып кетпейді.

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

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

Жұмысқа қабылдағанда параметрлер тізімін емес, ақауды талдауды сұраңыз. Үміткер pg_wal өскенде, тазалау тұрып қалғанда, реплика кешіккенде немесе «жаңартудан кейін есеп баяулады» деген шағым түскенде не істейтінін түсіндірсін. Жақсы жауап дерек жинаудан басталып, араласу тәуекелін ескеріп, нәтижені тексерумен аяқталады. Жатталған shared_buffers мәні таңғы төртте есеп жұмысын қалпына келтіру қабілетін көрсетпейді.

Өндіруші немесе интегратор қолдауы шартта нұсқалар, жауап беру уақыты, қашықтан қолжетімділік, жауапкершілік шекарасы және қалпына келтіруге қатысуы жазылса көмектеседі. Эскалация рәсімі жоқ «PostgreSQL-ді қолдаймыз» деген сөйлем оқиғаны жаппайды. Қазақстанда GSE.kz жобаның серверлік және интеграциялық бөлігін жинап, ұлттық сервистік желі арқылы тәулік бойғы техникалық қолдау көрсете алады. Бұл ішкі дерекқор иесі мен тұрақты қалпына келтіру жаттығуларын қажетсіз етпейді.

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

Шешімді пайдалану жаттығуынан кейін қабылдаңыз

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

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

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

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

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