Бұрын-соңды болмаған, міне, тағы барамыз!
Келесі жобамызда біз болашақта қиындықтарды болдырмау үшін Liquibase-ті басынан бастап пайдалануды шештік. Белгілі болғандай, жас команданың барлық мүшелері оны қалай дұрыс пайдалану керектігін білмейді. Мен ішкі семинар өткіздім, содан кейін оны мақалаға айналдыруды шештім.
Мақалада пайдалы кеңестер және реляциялық дерекқорды тасымалдау құралдарымен, атап айтқанда Liquibase-мен жұмыс істеу кезінде түсуге болатын үш ең айқын қателердің сипаттамасы бар. Кіші және орта деңгейлердегі Java әзірлеушілеріне арналған; тәжірибелі әзірлеушілер үшін бұл бұрыннан белгілі нәрсені құрылымдау және қайталау үшін қызықты болуы мүмкін.
Liquibase және Flyway Java әлеміндегі реляциялық құрылымдардың нұсқаларды басқару мәселелерін шешуге арналған негізгі бәсекелес технологиялар болып табылады. Біріншісі толығымен тегін, іс жүзінде ол көбінесе пайдалану үшін таңдалады, сондықтан Liquibase басылымның кейіпкері ретінде таңдалды. Дегенмен, қолданба архитектурасына байланысты сипатталған кейбір тәжірибелер әмбебап болуы мүмкін.
Реляциялық құрылымдардың көші-қоны реляциялық деректер қоймаларының әлсіз икемділігімен күресудің мәжбүрлі тәсілі болып табылады. OOP сәні дәуірінде дерекқорлармен жұмыс істеу стилі біз схеманы бір рет сипаттайтынымызды және оны қайтадан ұстамайтынымызды білдірді. Бірақ шындық әрқашан нәрселер өзгереді және кесте құрылымын өзгерту жиі қажет. Әрине, процестің өзі ауыр және жағымсыз болуы мүмкін.
Мен технологияның сипаттамасына және жобаңызға кітапхана қосу нұсқауларына тереңірек бармаймын; бұл тақырып бойынша бірнеше мақалалар жазылған:
Сонымен қатар, пайдалы кеңестер тақырыбы бойынша тамаша мақала болды:
Кеңестер
Көші-қон мәселесін шешудің төккен терімен, қанымен, азабымен туған ақыл-кеңестеріммен бөліскім келеді.
1. Жұмысты бастамас бұрын ең жақсы тәжірибелер бөлімімен танысу керек Ликвибаза
қарапайым, бірақ өте маңызды нәрселер сипатталған, онсыз кітапхананы пайдалану сіздің өміріңізді қиындатуы мүмкін. Мысалы, өзгерістер жиынын басқарудың құрылымданбаған тәсілі ерте ме, кеш пе шатасуларға және бұзылған тасымалдауларға әкеледі. Дерекқор құрылымы мен қызмет логикасына өзара тәуелді өзгерістерді бір уақытта енгізбесеңіз, бұл қызыл сынақтарға немесе бұзылған ортаға әкелуі ықтималдығы жоғары. Сонымен қатар, ресми веб-сайтта Liquibase пайдалану бойынша ұсыныстарда негізгі көшіру сценарийлерімен бірге кері қайтару сценарийлерін әзірлеу және сынау туралы тармақ бар. Жақсы, мақалада Тасымалдауларға және кері қайтару механизміне қатысты код мысалдары бар.
2. Тасымалдау құралдарын пайдалана бастасаңыз, дерекқор құрылымында қолмен түзетулерге рұқсат бермеңіз
«Бір рет Персил, әрқашан Персил» дегендей. Қолданбаңыздың негізін Liquibase басқара бастаса, кез келген қолмен жасалған өзгертулер бірден сәйкес емес күйге әкеледі және өзгертулер жиынына сенім деңгейі нөлге тең болады. Ықтимал тәуекелдер дерекқорды қалпына келтіруге жұмсалған бірнеше сағатты қамтиды; ең нашар жағдайда, өлі сервер. Егер сіздің командаңызда «ескі мектеп» DBA архитекторы болса, оған жай ғана шартты SQL әзірлеушісінен өз түсінігі бойынша дерекқорды өңдейтін болса, жағдайдың қаншалықты жаман болатынын шыдамдылықпен және мұқият түсіндіріңіз.
3. Өзгерістер жинағы репозиторийге әлдеқашан жіберілген болса, өңдеуден аулақ болыңыз
Егер басқа әзірлеуші қолданбасын жасаса және кейінірек өңделетін өзгерістер жиынтығын қолданса, ол қолданбаны іске қосу кезінде қате алған кезде сізді жылы сөзбен еске алады. Өзгертулер жинағын өңдеу қандай да бір жолмен әзірлеуге ағып кетсе, түзетулердің тайғақ еңісін орындауға тура келеді. Мәселенің мәні хэш сомасы бойынша өзгерістерді тексеруге негізделген - Liquibase негізгі механизмі. Өзгерістер жинағы кодын өңдеу кезінде хэш мөлшері өзгереді. Өзгерістер жиынын өңдеу деректерді жоғалтпай бүкіл дерекқорды нөлден бастап орналастыру мүмкін болғанда ғана мүмкін болады. Бұл жағдайда, SQL немесе XML кодын рефакторинг, керісінше, өмірді жеңілдетеді және көші-қонды оқуға ыңғайлы етеді. Мысал ретінде қолданбаның басында бастапқы дерекқордың схемасы топ ішінде келісілген жағдай болуы мүмкін.
4. Мүмкіндігінше расталған дерекқор сақтық көшірмелерін жасаңыз
Бұл жерде, менің ойымша, бәрі түсінікті. Егер кенеттен көшу сәтсіз аяқталса, барлығын қайтаруға болады. Liquibase-де өзгерістерді кері қайтару құралы бар, бірақ кері қайтару сценарийлерін де әзірлеушінің өзі жазады және оларда негізгі өзгертулер жинағының сценарийлері сияқты ықтималдығы бар проблемалар болуы мүмкін. Бұл кез келген жағдайда сақтық көшірмелермен қауіпсіз ойнау пайдалы екенін білдіреді.
5. Мүмкіндігінше әзірлеу кезінде дәлелденген дерекқордың сақтық көшірмелерін пайдаланыңыз
Егер бұл келісім-шарттар мен құпиялылыққа қайшы келмесе, дерекқорда жеке деректер жоқ және оның салмағы екі күн сияқты емес - оны тікелей тасымалдау серверлерінде қолданбас бұрын, оның әзірлеушінің машинасында қалай жұмыс істейтінін тексеріп, есептей аласыз. көші-қон кезінде ықтимал проблемалардың 100% дерлік.
6. Топтағы басқа әзірлеушілермен байланысыңыз
Жақсы ұйымдастырылған даму процесінде командадағы әрбір адам кімнің не істеп жатқанын біледі. Шындығында бұл жиі болмайды, сондықтан егер сіз өзіңіздің тапсырмаңыздың бөлігі ретінде дерекқор құрылымына өзгертулер дайындасаңыз, бұл туралы бүкіл команданы қосымша хабардар еткен жөн. Егер біреу параллель өзгерістер енгізсе, мұқият ұйымдастыру керек. Әріптестермен жұмыстың басында ғана емес, аяқталғаннан кейін сөйлескен жөн. Өзгерістер жиындарына қатысты көптеген ықтимал ақауларды кодты қарап шығу сатысында шешуге болады.
7. Не істеп жатқаныңызды ойлаңыз!
Бұл кез келген жағдайға қатысты түсінікті кеңес сияқты көрінеді. Дегенмен, егер әзірлеуші ол не істеп жатқанын және оның әсер етуі мүмкін екенін тағы бір рет талдаса, көптеген проблемаларды болдырмауға болар еді. Көшірулермен жұмыс әрқашан қосымша назар мен дәлдікті талап етеді.
Қақпақтар
Енді жоғарыдағы кеңестерді орындамасаңыз, түсіп қалуыңыз мүмкін типтік тұзақтарды қарастырайық және дәл не істеу керек?
1-жағдай: Екі әзірлеуші бір уақытта жаңа өзгертулер жиынын қосуға тырысуда
Вася мен Петя бір-бірін білмей, 4-нұсқасын өзгерткісі келеді. Олар дерекқор құрылымына өзгерістер енгізіп, әртүрлі өзгертулер жинағы файлдарымен тарту сұрауын шығарды. Келесі әсер ету механизмі ұсынылады:
Қалай шешуге болады
- Қалай болғанда да, әріптестер олардың өзгерістер жиынтығының жүру тәртібін келісу керек, мысалы, алдымен Петинді қолдану керек.
- Біреу екіншісін өзіне қосып, Васяның өзгерістер жинағын 5 нұсқасымен белгілеуі керек. Мұны Cherry Pick немесе ұқыпты біріктіру арқылы жасауға болады.
- Өзгерістерден кейін сіз қабылданған әрекеттердің дұрыстығын міндетті түрде тексеруіңіз керек.
Шындығында, Liquibase механизмдері репозиторийде 4-нұсқадағы екі өзгерістер жиынтығын алуға мүмкіндік береді, осылайша сіз бәрін сол күйінде қалдыра аласыз. Яғни, сізде әртүрлі атаулармен 4-нұсқаға екі өзгеріс болады. Бұл тәсілмен кейінірек дерекқор нұсқаларын шарлау өте қиын болады.
Сонымен қатар, Liquibase хоббиттердің үйі сияқты көптеген құпияларды сақтайды. Олардың бірі - validCheckSum кілті, ол 1.7 нұсқасында пайда болды және дерекқорда не сақталғанына қарамастан, белгілі бір өзгерістер жиынтығы үшін жарамды хэш мәнін көрсетуге мүмкіндік береді. Құжаттама былай дейді:
Дерекқорда не сақталғанына қарамастан, осы өзгертулер жинағы үшін жарамды деп саналатын бақылау сомасын қосыңыз. Негізінен өзгертулер жиынын өзгерту қажет болғанда және ол бұрыннан іске қосылған дерекқорларға жіберілген қателерді қаламағанда қолданылады (ұсынылған процедура емес)
Иә, иә, бұл процедура ұсынылмайды. Бірақ кейде күшті жеңіл сиқыршы да қараңғы техниканы меңгереді
2-жағдай: деректерге байланысты көшу
Тікелей серверлерден дерекқордың сақтық көшірмелерін пайдалану мүмкіндігіңіз жоқ делік. Петя өзгертулер жинағын жасап, оны жергілікті деңгейде сынап көрді және оның дұрыс екеніне толық сенімділікпен әзірлеушіге сұрау жіберді. Қалай болғанда да, жоба жетекшісі Петя оны тексерді ме, жоқ па деп түсіндірді, содан кейін оны қосты. Бірақ әзірлеу серверінде орналастыру төмендеді.
Шындығында, бұл мүмкін және ешкім де бұдан қорғалмаған. Бұл кесте құрылымына өзгертулер қандай да бір түрде дерекқордағы нақты деректермен байланысты болса орын алады. Әлбетте, егер Петяның деректер базасы тек сынақ деректерімен толтырылған болса, онда ол барлық проблемалық жағдайларды қамтымауы мүмкін. Мысалы, кестені жою кезінде, жойылатын кестедегі жазбаларға қатысты Сыртқы кілт бойынша басқа кестелерде жазбалар бар екені белгілі болды. Немесе баған түрін өзгерткенде, деректердің 100% жаңа түрге түрлендіру мүмкін емес болып шығады.
Қалай шешуге болады
- Тасымалдаумен бірге бір рет пайдаланылатын арнайы сценарийлерді жазыңыз және деректерді тиісті пішінге келтіріңіз. Бұл көшірулерді қолданғаннан кейін деректерді жаңа құрылымдарға тасымалдау мәселесін шешудің жалпы жолы, бірақ осыған ұқсас нәрсені ерекше жағдайларда бұрын қолдануға болады. Бұл жол, әрине, әрқашан қол жетімді емес, өйткені тірі серверлердегі деректерді өңдеу қауіпті және тіпті жойқын болуы мүмкін.
- Тағы бір қиын әдіс бар өзгертулер жинағын өңдеу болып табылады. Қиындығы, ол бұрыннан бар пішінде қолданылған барлық дерекқорларды қалпына келтіруге тура келеді. Бүкіл сервер тобы дерекқорды нөлден бастап жергілікті түрде шығаруға мәжбүр болуы әбден мүмкін.
- Және ең әмбебап әдіс - деректерге қатысты мәселені әзірлеушінің ортасына беру, сол жағдайды қайта жасау және ақаулықты айналып өтетін сынғанға жаңа өзгерістер жиынтығын қосу.
Тұтастай алғанда, деректер базасы құрамы бойынша өндірістік сервер дерекқорына неғұрлым ұқсас болса, көшіру мәселелерінің алысқа бару мүмкіндігі соғұрлым аз болады. Және, әрине, репозиторийге өзгертулер жинағын жібермес бұрын, ол ештеңені бұзады ма, жоқ па деп бірнеше рет ойлану керек.
Жағдай 3. Ликвибаза өндіріске енгеннен кейін қолданыла бастайды
Топ жетекшісі Петядан жобаға Liquibase қосуды сұрады делік, бірақ жоба қазірдің өзінде өндірісте және дерекқор құрылымы бар.
Сәйкесінше, мәселе кез келген жаңа серверлерде немесе әзірлеуші машиналарында бұл кестелер нөлден қайта жасалуы керек және бар орта жаңа өзгерістер жиынын қабылдауға дайын тұрақты күйде қалуы керек.
Қалай шешуге болады
Сондай-ақ бірнеше тәсілдер бар:
- Бірінші және ең айқын - жаңа ортаны инициализациялау кезінде қолмен қолданылуы керек бөлек сценарийдің болуы.
- Екіншісі азырақ анық, басқа Liquibase контекстінде болатын Liquibase көшірмелері бар және оны қолданыңыз. Liquibase контексті туралы қосымша ақпаратты мына жерден оқи аласыз: . Жалпы алғанда, бұл, мысалы, тестілеу үшін сәтті қолдануға болатын қызықты механизм.
- Үшінші жол бірнеше қадамдардан тұрады. Біріншіден, бар кестелер үшін тасымалдауды жасау керек. Содан кейін ол белгілі бір ортаға қолданылуы керек және осылайша оның хэш сомасы алынады. Келесі қадам бос емес серверде бос Liquibase кестелерін инициализациялау болып табылады және өзгертулер жиынын пайдалану тарихы бар кестеде дерекқорда бұрыннан бар өзгерістері бар «қолданылған сияқты» өзгерістер жиынтығы туралы жазбаны қолмен қоюға болады. . Осылайша, бар серверде тарихты кері санау 2-нұсқадан басталады және барлық жаңа орталар бірдей әрекет етеді.
Жағдай 4. Көші-қон үлкен болып, аяқтауға уақыт жоқ
Қызметті дамытудың басында, әдетте, Liquibase сыртқы тәуелділік ретінде пайдаланылады және қолданба іске қосылған кезде барлық тасымалдаулар өңделеді. Дегенмен, уақыт өте келе сіз келесі жағдайларға тап болуыңыз мүмкін:
- Көші-қон үлкен болады және аяқталуы ұзақ уақыт алады.
- Таратылған орталарда, мысалы, бір уақытта бірнеше дерекқор серверінің даналарында тасымалдау қажеттілігі бар.
Бұл жағдайда тасымалдауларды тым ұзақ қолдану қолданба басталған кезде күту уақытының аяқталуына әкеледі. Сонымен қатар, тасымалдауларды әрбір қолданба данасына бөлек қолдану әртүрлі серверлердің синхрондалмаған болуына әкелуі мүмкін.
Қалай шешуге болады
Мұндай жағдайларда сіздің жобаңыз қазірдің өзінде үлкен, мүмкін тіпті ересек және Liquibase жеке сыртқы құрал ретінде әрекет ете бастайды. Шындығында, Liquibase кітапхана ретінде jar файлына жинақталған және жобада немесе тәуелсіз түрде тәуелділік ретінде жұмыс істей алады.
Оқшау режимде тасымалдауды жүзеге асыруды CI/CD ортасына немесе жүйелік әкімшілер мен қолдану мамандарының күшті иығына қалдыра аласыз. Мұны істеу үшін сізге Liquibase пәрмен жолы қажет . Бұл режимде барлық қажетті тасымалдаулар орындалғаннан кейін қолданбаны іске қосу мүмкін болады.
қорытынды
Шындығында, дерекқорды көшірумен жұмыс істеу кезінде көптеген қателіктер болуы мүмкін және олардың көпшілігі шығармашылық көзқарасты талап етеді. Егер сіз құралды дұрыс пайдалансаңыз, бұл тұзақтардың көпшілігін болдырмауға болатынын түсіну маңызды. Атап айтқанда, мен аталған мәселелердің барлығын әртүрлі формада шешуге тура келді, олардың кейбіреулері менің қателіктерімнің нәтижесі болды. Көбінесе бұл, әрине, абайсыздықтан болады, бірақ кейде құралды пайдалана алмау салдарынан болады.
Ақпарат көзі: www.habr.com