🥇Файл системаларын жука камсыздоо LinuxҮч терабайттык MySQL маалымат базасынын жумушчу көчүрмөлөрүн 20 секунданын ичинде кантип түзүү керек

Менин атым Юрий, мен Citymobil компаниясында системаларды башкаруу тобунун жетекчисимин. Бүгүн мен файл системалары үчүн жука камсыздоо технологиясы менен иштөө тажрыйбам менен бөлүшөм. Linux Мен аны компаниянын CI/CD процесстеринде кантип колдонсо болорун түшүндүрүп берем. Кодду өндүрүшкө жеткирүүдө автоматтык түрдө текшерүү үчүн, бизге MySQL маалымат базасынын өндүрүштүк версиясына мүмкүн болушунча жакын окуу-жазуу көчүрмөлөрү керек болгон кырдаалды карап чыгабыз.

Киришүү: Эмне үчүн жаман кеңеш берүү керек?

Логикалык суроо, анткени маалыматтар базасынын схемаларын тесттик чөйрөлөргө көчүрүүнүн далилденген механизмдери бар. Эмне үчүн негизги эмес МКБны ушундай көлөмгө кеңейтүү керек? Жана бардык маалыматтар тестирлөө үчүн талап кылынбайт. Мен түшүндүрүүгө аракет кылам.

Болжол менен бир жыл мурун, биздин такси агрегаторунун жигердүү өсүшүнүн фонунда (2018-жылы аяктаган сапарлар болжол менен 15 эсеге көбөйгөн), маалыматтардын көлөмү, серверлерге жүктөм жана чыгуулардын жыштыгы көбөйгөн. Биз төмөнкү кырдаалга туш болдук:

Негизги MySQL маалымат базасы жалпы көлөмү 1000 ТБ болгон 2,5дей таблицага чейин өстү жана өсүүнү улантты.
Тез сындырып, базаны жок кылууга эч кандай жол жок болчу. Буга "Мен маалымат базасына каалаганымды жана каалаганымды жазам" деген эски ыкма жол берген эмес, бир топ JOIN жана ички таблица көз карандылыгы.
Берилиштер базасынын схемасын сыноо чөйрөсүнө көчүрүү механизми болгон эмес.
Жайгаштыруу учурунда кодду автоматтык түрдө текшерүү болгон эмес.

Мен акыркы маселени мүмкүн болушунча тезирээк чечүүнү кааладым. Почтачылардын тесттери негизги PHP монолиттерин текшерүү үчүн жазылган, бирок заманбап маалымат базасы жок болчу. Ошол эле учурда, биз түн ичинде репликаны түзүп, аны мастер кылып, күндүзү тытылып калтыра алган жокпуз: өтө көп сандагы жайылтуулар жана өзгөртүүлөр, анын ичинде маалыматтар жана маалымат базасынын схемасында, стенд күндүн ортосуна чейин иштебей калат. Ал эми жайылтууларды жумуш күнү менен чектөө натыйжасыз болмок.

Ошого карабастан тапшырма аткарылды: биз эки жуманын ичинде биринчи жумушчу стенди алдык. Ал өткөн жылдын ичинде көптөгөн өзгөрүүлөргө дуушар болгон жана колдонулуп келет.

Андан кийин, мен майда-чүйдөсүнө чейин биздин чечим иштеп чыгуунун бардык кадамдарын жана этаптарын сүрөттөп берет. Сиз бул ыкма өз укугуна татыктуу экенин көрөсүз.

"Ичке ашыкча" деген эмне?
Бул аппараттык же программалык камсыздоо технологиясы (башка аталышы - сейрек көлөмдөр), ал сизге керектүү ресурсту колдо болгонго караганда көбүрөөк бөлүүгө мүмкүндүк берет. Мында бөлүнгөн көлөм жетиштүү (зарылга жараша) жана өз убагында (талап кылынган убакыт үчүн) критерийлерине жооп бериши керек. Негизинен, ичке резервация ар кандай сактоо тутумдарында диск мейкиндигин талап кылынган көлөмдө камсыз кылуу үчүн колдонулат, бул иш жүзүндө жеткиликтүү болгондордон ашат. Технология ар кандай файл системалары тарабынан колдоого алынат, мисалы, LVM2, ZFS, BTRFS. Ал виртуалдаштыруу гипервизорлорунда кеңири колдонулат. Жука резервдик көчүрүү бизге негизги бөлүмдүн снапшоттарынан тез арада түзүүгө мүмкүндүк берди, алар бул бөлүмдүн бизге канча керек болсо, ошончо көчүрмөсүн (MySQL DBMS маалыматтар каталогу).

Биринчи стенд, Thin LVM технологиясы

Бул бөлүмдү "Кантип чоң көлөмдөгү маалыматтардын эң тез сүрөтүн жасоо керек" деп атоого болот. Жука LVM, файл тутумунун жана MySQL DBMSтин туруктуулугун адепсиз деңгээлге чейин төмөндөтүү.

Негизги OS бөлүмдөрүн куруу үчүн биз LVM колдонгондуктан, биз андан баштоону чечтик. Баштоо үчүн, бизге өзүнчө физикалык машина керек болчу - биздин негизги MySQL маалымат базасынын көчүрмөсү, анын негизинде биз сураныч боюнча репликанын сүрөтүн түзүп, аны өзүнчө MySQL инстанциясынын жанына көтөрө алабыз. Сыноо учурунда биз бул инстанцияда өзгөртүү операцияларын колдонууга уруксат бердик жана сыноолор аяктагандан кийин аны аман-эсен жок кылдык. Сервердин конфигурациясы мындай болгон:

2 x Intel Silver 4114 (10x2,2 ГГц HT)
8 x 32 ГБ DDR4
RAID-8догу Adaptec RAID контроллерундагы 1920 x 10 ГБ Intel SSD

Сиз RAID контроллери менен RAID MD программалык камсыздоосун тандоо темасында өзүнчө макала жаза аласыз. Биздин тандообузга эки фактор таасир эткенин айта кетейин:

Көйгөй түзүлгөн учурда биз RAID контроллерлоруна бардык DBMS орноттук, ошондуктан бул тарыхый жактан болгон деп айта алабыз.
Синтетикалык файл тутумунун тесттери менен MySQL ар кандай операциялары менен тесттердин аткаруусунун айырмасы минималдуу болгон.

Биз пайда болгон RAID-10ду бөлдүк: биз бүт көлөм үчүн бирдиктүү Көлөм тобун (VG) түздүк (болжол менен 6,7 ГБ ашыкча чыгым менен) жана 50 ГБ тутум үчүн логикалык бөлүктү (Логикалык көлөм, LV) түздүк. Кадимки кырдаалда биз мейкиндиктин калган бөлүгүн MySQL бөлүмү катары аныктайбыз. Бирок бизге жука резервдик көчүрмө керек болчу, андыктан адегенде бассейн деп аталган бассейнди түздүк, анын ичинде 3,5 ТБ менен /var/lib/mysql бөлүмүн түздүк (маалыматтар базасынын болжолдуу көлөмүнүн негизинде):

lvcreate -l 100%FREE -T vga/thin
lvcreate -V 3.5T -T vga/thin -n mysql

Биз бөлүмдү ext4 форматында форматтап, аны орнотуп, репликаны жаздык жана оригиналдуу стенди алдык. Андан кийин биз API түрүндөгү байланышты жасадык, ал сүрөттү түзүп, MySQL маалыматтар базасынын инстанциясын берилген портто көтөрүп, түзүлгөн инстанцияны жок кылышы керек. Бул системалык чалууларды гана колдонгондуктан, биз скрипт тили катары кадимки bashти тандап алдык жана HTTP → bash API туташтыруу үчүн ачык булактуу чечимди колдондук goexpose, Go менен жазылган.

Бир күнү биз bash скрипттерин ачык булакка чыгарабыз, бирок азыр мен жөн гана негизги алгоритмди сүрөттөп берем:

Негизги көз ирмемдик сүрөттү түзүү:

Негизги репликаны токтотуу.
Биз snapmain сүрөтү менен операцияларга блок койдук.
Жаңы көз ирмемдик сүрөттү түзүңүз.
MySQLди ишке киргизип, кулпусун алып салыңыз.

Snapmain'ден ыктыярдуу портто маалымат базасын түзүү:

Биз белгилүү бир маалымат базасынын инстанциясына (портко) кулпу койдук.
Негизги сүрөттү түзүү бөгөттөлгөндүгүн текшеребиз. Эгерде ал бар болсо, анда биз күтүп, 5 секунд сайын кайра текшерип турабыз.
Биз инстанциянын эски LV бөлүмү бар-жогун текшеребиз.
3.1 Эгерде бар болсо, MySQL инстанциясын токтотуу жана LV бөлүгүн жок кылуу үчүн kill -9 колдонуңуз.
Биз snapmainден жаңы инстанция түзөбүз.
Биз бул мисал үчүн каталогдорду даярдап, орнотобуз.
Биз кулдун (файлдардын) атрибуттарын алып салабыз жана MySQL инстанциясын ишке киргизебиз.
Аны устат кылалы.
Блокту алып салабыз.

Кокус портто маалымат базасын алып салуу:

Биз белгилүү бир маалымат базасынын инстанциясына (портко) кулпу койдук.
kill -9 аркылуу MySQL инстанциясын өлтүрүңүз.
Келгиле, каталогдорду ажыраталы.
LV бөлүгүн жок кылабыз жана кулпусун алып салабыз.

Жаңы маалымат базасы инстанциясынын бөлүктөрүн клондоо үчүн мисал буйруктары:

lvcreate -n stage_3307 -s vga/snapmain
lvchange -ay -K vga/stage_3307
mount -o noatime,nodiratime,data=writeback /dev/mapper/vga-stage_3307 /mnt/stage_3307

Эми мен сизге жука ашыкча колдонууда кабылган негизги көйгөй жөнүндө айтып берем. Биз SSD дисктеринин иштешине тыгылып калдык. Бул Thin LVM өзгөчөлүктөрүнөн улам болду: ал негизинен демейки 4 МБ өлчөмүндөгү төмөнкү деңгээлдеги бөлүктөр менен түзмөк деңгээлинде иштейт. Ал кандай көрүндү:

Негизги бөлүмдөн /var/lib/mysql сүрөтүн түзүңүз.
Кожоюнга жетиш үчүн биз репликациялоону баштайбыз.
Реплика таблицаларындагы ар кандай өзгөртүүлөр эски, өзгөрүлбөгөн маалымат бөлүктөрүн сүрөт бөлүмүндө сактоого мажбурлайт.
Көтөрүлгөн сыноо инстанциясына жасалган кандайдыр бир өзгөртүү эски, өзгөртүлбөгөн маалыматтардын бөлүктөрүн ошол инстанция үчүн клондолгон сүрөт бөлүмүндө сактоого алып келет.
Биз түзмөктө 100% киргизүү/чыгаруу операцияларынын жүгүн, бардык операциялардын жайлоосун жана репликанын акырындык менен артта калышын алабыз.
Жумуш күнүнүн аягында биз бир нече саатка артта калган стенд алабыз.

Акылдуураак жыйынтык алуу үчүн биз муну кантип чечтик (негизги пункттар):

RAID контроллери:

Кэштөөнүн бардык түрлөрү демейки боюнча өчүрүлгөн.
Кайра жазууну орнотуу (маалымат буферге киргенде, дискке иш жүзүндө сактоо аткарылганга чейин жазуу аяктайт).

Файлдык система:

/var/lib/mysql орнотуу пунктунда биз жаздык noatime,nodiratime,дата=жазуу
tune4fs аркылуу ext2 журналы өчүрүлгөн.

MySQL:

Белгиленген innodb_flush_method = O_DSYNC (жазуунун ылдамдыгын жогорулатуу, ошону менен ишенимдүүлүктү төмөндөтүү).
Каттоо өчүрүлгөн, бизге журналдардын кереги жок.
Белгиленген innodb_buffer_pool_size = 4G (InnoDB бассейнинин өлчөмү канчалык кичирээк болсо, MySQL токтогондо ошончолук тез өчүп калат жана биз ошончолук тезирээк сүрөттү түзөбүз).

Бул толук тизме эмес, өзгөчө MySQL үчүн. Бирок, калган өзгөртүүлөр анча чоң эмес жана көп учурда дайыма же так колдонула бербейт. Мисалы, дисктерди түшүрүүгө аракет кылып, биз да алып кеткенбиз innodb_parallel_doublewrite_path /dev/shm ичинде, бул кээ бир учурларда туура эмес токтотулган инстанцияны баштаганда бизди 5 секундага чейин сактап калган.

Эмне үчүн биз сүрөткө тартуудан мурун MySQLди токтотобуз? Анткени, биз аны иштеп жаткан репликадан алып сала алабыз. Туура, бирок бул сүрөттүн жаңы маалымат базасы демейки боюнча бузулган деп эсептелет жана ишке киргизүүдө толук сканерлөө талап кылынат. Репликаны токтотуу, албетте, тезирээк, бирок ал бүт процесстеги эң узак операция болуп калат.

Натыйжада, биз көбүрөөк алгылыктуу мөөнөттөрдү жана колдонууга даяр стенд алдык. Негизги репликанын репликациясынын эң сонун графигинен көрүнүп тургандай, абал идеалдуу эмес:

Башка кемчиликтердин арасында Thin LVM бассейнине мониторинг жүргүзүүнүн практикалык мүмкүн эместигин белгилей кетүү керек: системанын стандарттык iostat функцияларынан тышкары, мисалы, кайсы пулдун элементи учурда файл тутумунда эң чоң жүктү жаратып жатканын түшүнүү мүмкүн эмес.

Өзүнчө, жогоруда сүрөттөлгөн оптималдаштырууга байланыштуу бир чоң кемчиликти белгилей кетүү керек: биз YOLO стендин алдык. Болжол менен бир же эки айда бир жолу ext4 мындай кыянаттыктарга туруштук бере албай, орду толгус бузулуп, репликаны кайра форматтап, кайра жүктөөнү талап кылган. Ылдамдыкта жеңип, биз үмүтсүз туруктуулукту буздук.

Thin LVM колдонуп жатканда кандай көрсөткүчтөрдү көзөмөлдөө керек:

Жука бассейн маалыматы %
Жука бассейн метадайындары %

Эгерде биздин стендде маалыматтар үчүн орун жетишсиз болсо (бул дисктерди тазалоо үчүн жетиштүү), анда метаберилиштер үчүн орундун жетишсиздиги бассейндин толук кыйрашына жана аны нөлдөн баштап кайра куруунун зарылдыгына алып келет.

Убакыттын өтүшү менен бассейндин ичиндеги файл системасы абдан майдаланып кетет. Мен күнүнө бир жолу cron буйругун иштетүүнү сунуштайм fstrim -v /var/lib/mysql.

Аралык суммалар:

Технологияны колдонуу оңой, LVMдин өзү сыяктуу жана атайын инженердик квалификацияны талап кылбайт.
Бул кичинекей жана өтө жүктөлбөгөн маалымат базаларына ылайыктуу. Маалыматтар базасы канчалык кичине болсо, бассейндин ичиндеги файл тутумунун айланасында ошончолук аз бөлүктөр жылат жана дисктерге жүктөлгөн жүк ошончолук аз болот.
Биздин милдетибиз үчүн биз кийинки бөлүмдө талкуулана турган башка чечимдерди издей баштадык.

Экинчи стенд, ZFS технологиясы

Мен ZFS файл системасы менен көптөн бери иштечүмүн, бирок ошол кезде ZFS өзүнүн Solaris OS үй-бүлөсүндө ишенимдүү түрдө жакшы иштечү. FreeBSDге жакшы ишке ашыруу деңгээли бар порт бар болчу. Ошондой эле бүтпөгөн порт бар болчу. Linux, аны аз эле адам колдонгон. B-дарагы сыяктуу маалыматтарды сактоо түзүмүнөн улам (айта кетсек, MySQLдин InnoDB да ушундай эле сактоо түзүмүнө ээ), ZFS өтө көп сандагы файлдары бар орнотууларда начар иштеген. Бул, колдонуудан мурун ариптерди үйрөнүү зарылдыгы менен бирге, мени бул файл системасын узак мөөнөттүү колдонууга алып келди. Ext4 жана xfs пайда болуп, стандартка айланды. Бирок ZFS биздин муктаждыктарыбызга абдан ылайыктуу экенин эске алганда жана Linux-версия, сын-пикирлерге караганда, толугу менен акылдуу продуктка айланды (толук колдоого алынбаса да, ошондуктан ZFSке системаны нөлдөн баштап орнотуу ар кандай вуду техникаларынын жардамы менен гана мүмкүн), биз аны сынап көрүүнү чечтик.

Белгилүү себептерден улам, стенд окшош конфигурация менен тандалып алынган (RAID контроллерин кошпогондо). Биз сегиз 1920 ГБ SSD дисктерин орноттук. Серверди жылаңач ZFSге жүктөө үчүн өзүбүздүн тармактык сүрөтүбүздү жазууну каалабайбыз, ошондуктан биз бардык дисктерден 50 ГБ тиштеп алып, система үчүн аларга MD RAID-10 жасадык. Ар бир дискте калган 1950 ГБ RAID-10дун ZFS аналогуна бириктирилген:

zpool create zpool mirror /dev/sda2 /dev/sdb2 mirror /dev/sdc2 /dev/sdd2 mirror /dev/sde2 /dev/sdf2 mirror /dev/sdg2 /dev/sdh2

MySQL үчүн бөлүмдөрдү түздүк:

zfs create zpool/mysql
zfs set compression=gzip zpool/mysql
zfs set recordsize=128k zpool/mysql
zfs set atime=off zpool/mysql
zfs create zpool/mysql/data
zfs set recordsize=16k zpool/mysql/data
zfs set primarycache=metadata zpool/mysql/data
zfs set mountpoint=/var/lib/mysql zpool/mysql/data

Биз жергиликтүү gzip берилиштерин кысуу иштетилгенибизди эске алыңыз. Бизде серверде көптөгөн процессор ресурстары бар жана алар толук пайдаланылбайт.Натыйжада биздин базанын 3 ТБсы 1,6 ТБга айланды, ал эми алсыз шилтеме, мурунку учурдагыдай, дисктин максималдуу иштеши болгондуктан, азыраак маалымат ошончолук жакшы, биз башынан эле ZFSден чоң бонус алабыз! Толук жүктөө учурунда, gzipдин иштеши үчүн 4 ядрого чейин талап кылынат, бирок биз каршы эмеспиз.

Андан кийин ишке ашыруу тезирээк жүрдү. MySQL реплика орнотуулары LVM стендинен көмүртек көчүрмөсү катары өткөрүлүп берилди. Мен ZFS буйруктарын колдонуп скрипттерди кайра жазууга бир аз убакыт коротушум керек болчу, бирок жалпысынан алгоритмдер ошол эле бойдон калды. Сүрөттү түзүүнүн мисалы:

zfs set snapdir=visible zpool/mysql/data
zfs create zpool/stage_3307
zfs clone zpool/mysql/data@snapmain zpool/stage_3307/data
zfs set mountpoint=/mnt/stage_3307 zpool/stage_3307/data

Кошумча тюнингден: биз метаберилиштер жана l2arc жана zil журналдары менен ZFS бөлүмдөрүн эс тутумга жылдырдык. Биздин милдетибиз үчүн, кийинчерээк белгилүү болгондой, бул ашыкча болгон, бирок азыр биз бул оптималдаштырууну калтырдык, керек болсо өзгөртүү оңой. Терс таасирлердин бири - серверди кайра жүктөөдөн кийин, тиешелүү эстутум аймактарын кайра түзүү керек. Эч кандай маалымат жоголбойт. Zpool статусун кесүү:

logs
      /dev/shm/zil_slog.img  ONLINE       0     0     0
cache
      /dev/shm/l2arc.img     ONLINE       0     0     0

Бул конфигурацияда биз стендди сынап баштадык жана эң сонун натыйжаларга ээ болдук: бир эле учурда эки маалымат базасынын инстанциялары (жана активдүү негизги реплика) менен снапшоттордо дискти 50-60% колдонууга алдык.

Репликациянын артта калуу графигинен көрүнүп тургандай, биз негизги көйгөйүбүздөн арылдык (Tin LVM бөлүмүндөгү мурунку график менен салыштырыңыз):

Мындан тышкары жана мунун аркасында биз бардык операцияларды бир топ тездетип алдык: репликаны токтотуу жана баштоо менен көз ирмемдик сүрөттү толугу менен түзүү 40 секундга чейин созулат, жаңы MySQL инстанциясын снапшоттон жайылтуу 20 секундга чейин созулат. Бул биз үчүн да, биздин программалык код сыноолорубуз үчүн дагы канааттандырарлык.

Аралык суммалар:

Натыйжалар кодду сыноо үчүн өндүрүш базасынын көчүрмөсүн алуу муктаждыгын толугу менен канааттандырды.
Технология киргизүүнү талап кылат: ZFS деген эмне экенин жана аны менен кантип иштөөнү түшүнүү керек.
Биз көп сандагы (1 миллиондон ашык) кичинекей файлдар менен ZFSдин учурдагы абалын текшерген жокпуз. Бирок биз көйгөй сакталып турат деп ойлойбуз, андыктан мен бул файл тутумун эч кандай файл сактагычына сунуш кылбайм.

Кийинкиси эмне?

Стенддин алкагында кыла турган башка эч нерсе жок, биз жыйынтыкка канааттандык. Балким, келечекте биз стенддин репликациясын орнотууга тестирлөө үчүн кереги жок таблицалардын алып салууларын кошобуз; бул маалымат базасынын көлөмүн андан ары азайтат. Биз BTRFS системасын жана анын жука резервдик технологияны ишке ашыруусун сынап көргөн жокпуз. Бирок, негизги максат ишке ашкандан кийин, мындай милдет мындан ары татыктуу эмес. Жалпысынан алганда, албетте, мен жогоруда сүрөттөлгөн ыкмадан алыстагым келет - тесттик чөйрөгө жумушчу маалымат базасын көчүрүү, өзүнчө тесттик маалымат базасын түзүү жана негизги маалымат базасын бөлүштүрүү. Биз мунун көбүн иш жүзүндө колдонуп жатабыз, бул тууралуу сөзсүз түрдө кийинки макалаларда сөз кылабыз.

натыйжалары

Баштапкы маселе адаттан тыш жол менен болсо да чечилди. Ортодогу корутундулар колдонулган технологиялардын ар биринин артыкчылыктары жана кемчиликтери сүрөттөлгөн, андыктан кайсы технологияны жана качан колдонсо болорун чечели:

Thin LVM - кичинекей маалымат базалары үчүн жана ZFSди үйрөнүүнү каалабасаңыз же убактыңыз жок болгондо.
ZFS - эгерде сизде аны менен иштөө тажрыйбаңыз болсо же кандайдыр бир кырдаалда аны изилдөөгө убакыт бөлүүгө мүмкүнчүлүк болсо.

Презентациянын жогорку деңгээлинде, бул макала эки файл тутумунун технологиясын салыштыруу гана эмес. Мен айткым келет жана бекемдей турган негизги идея - бизнес-критикалык кырдаалдарда кутудан тышкары ойлонуудан коркпошуңуз жана даяр рецепттерди гана кабыл алуу. Бир кезде биз жалпы техникалык бөлүмдө башыбызды чайкап, бир мүнөткө жетпеген убакытта маалымат базасынын үч терабайттык көчүрмөсүн түзүү милдети мүмкүн эмес, бизге коркунучтуу технологиялардын кереги жок деп айта алмакпыз, келгиле. туура. Бул мүмкүн болчу, бирок биз сыноосуз жана ишке ашыруу учурунда алты айдан бир жылга чейин жана кардарлардын көп сапарларын (саякат биздин негизги бизнес көрсөткүчүбүз) жоготмокпуз. Коркунучтун чегинен тышкары иш-аракет кылуу менен биз ишке ашырууда көп убакытты жоготкон жокпуз, жаңы жана унутулуп калган эски технологиялар боюнча тажрыйбага ээ болдук жана бизге чындап муктаж болгон учурда тестирлөөнү камсыз кылдык. Бул биздин бардык керсеткучтерубузге жакшы таасирин тийгизгени талашсыз. Тандоо ар дайым сиздики, биз өз тарапыбыздан азыркы жана келечектеги кызыктуу жетишкендиктер тууралуу блогубузда сүйлөшүүнү улантабыз.

Source: www.habr.com