ፕሮሆስተር > ጦማር > አስተዳደር > MySQL (Percona Server) ከ 5.7 ወደ 8.0 በማዘመን ላይ

MySQL (Percona Server) ከ 5.7 ወደ 8.0 በማዘመን ላይ

MySQL (Percona Server) ከ 5.7 ወደ 8.0 በማዘመን ላይ

ግስጋሴው ዝም ብሎ አይቆምም፣ ስለዚህ ወደ የቅርብ ጊዜው የ MySQL ስሪቶች የማሻሻል ምክንያቶች ከጊዜ ወደ ጊዜ አስገዳጅ እየሆኑ መጥተዋል። ብዙም ሳይቆይ፣ በአንዱ ፕሮጀክታችን ውስጥ፣ ምቹ የሆነውን የፐርኮና አገልጋይ 5.7 ክላስተሮችን ወደ ስሪት 8 የምናዘምንበት ጊዜ ነበር። ይህ ሁሉ የሆነው በኡቡንቱ ሊኑክስ 16.04 መድረክ ላይ ነው። እንዲህ ዓይነቱን ቀዶ ጥገና በትንሹ ዝቅተኛ ጊዜ እንዴት ማከናወን እንደሚቻል እና በዝማኔው ወቅት ምን ችግሮች እንዳጋጠሙን - በዚህ ጽሑፍ ውስጥ ያንብቡ.

ዝግጅት

ማንኛውም የውሂብ ጎታ አገልጋይ ማሻሻያ ከመረጃ ቋት መልሶ ማዋቀር ጋር የተቆራኘ ሊሆን ይችላል፡ በስርዓት ሃብቶች ላይ የሚደረጉ መስፈርቶች ለውጦች እና የውሂብ ጎታ አወቃቀሮችን ጊዜ ያለፈባቸው መመሪያዎችን ማረም።

ከማዘመንዎ በፊት በእርግጠኝነት ኦፊሴላዊውን ሰነድ እንጠቅሳለን-

እና የድርጊት መርሃ ግብር እናዘጋጅ፡-

  1. ጊዜ ያለፈባቸው መመሪያዎችን በማስወገድ የማዋቀር ፋይሎችን ያስተካክሉ።
  2. ከመገልገያዎች ጋር ተኳሃኝነትን ያረጋግጡ።
  3. ጥቅሉን በመጫን የባሪያ ዳታቤዝ ያዘምኑ percona-server-server.
  4. ጌታውን በተመሳሳዩ ጥቅል ያዘምኑ።

እያንዳንዱን የእቅዱን ነጥብ እንይ እና ምን ሊሳሳት እንደሚችል እንይ።

አስፈላጊ! በጋሌራ ላይ የተመሠረተ የ MySQL ክላስተርን የማዘመን ሂደት በአንቀጹ ውስጥ ያልተገለጹ የራሱ ጥቃቅን ነገሮች አሉት። በዚህ ጉዳይ ላይ ይህንን መመሪያ መጠቀም የለብዎትም.

ክፍል 1፡ ውቅሮችን በመፈተሽ ላይ

MySQL በስሪት 8 ተወግዷል query_cache. በእውነቱ እሱ ነበር። ጊዜው ያለፈበት መሆኑ ተገለጸ ወደ ስሪት 5.7, አሁን ግን ሙሉ በሙሉ ተሰርዟል. በዚህ መሠረት ተጓዳኝ መመሪያዎችን ማስወገድ አስፈላጊ ነው. እና ለመሸጎጫ ጥያቄዎች አሁን ውጫዊ መሳሪያዎችን መጠቀም ይችላሉ - ለምሳሌ ፣ ProxySQL.

እንዲሁም በማዋቀር ውስጥ ስለ ጊዜ ያለፈባቸው መመሪያዎች ነበሩ። innodb_file_format. በ MySQL 5.7 ውስጥ የ InnoDB ቅርጸትን መምረጥ ከቻለ, 8 ኛው ስሪት ቀድሞውኑ ይሰራል በ Barracuda ቅርጸት ብቻ.

ውጤታችን የሚከተሉት መመሪያዎች መወገድ ነው።

  • query_cache_type, query_cache_limit и query_cache_size;
  • innodb_file_format и innodb_file_format_max.

ለመፈተሽ የፐርኮና አገልጋይ የዶከር ምስል እንጠቀማለን። የአገልጋዩን ውቅረት በማውጫው ውስጥ እናስቀምጣለን። mysql_config_test, እና ከእሱ ቀጥሎ የውሂብ እና የምዝግብ ማስታወሻዎች ማውጫዎችን እንፈጥራለን. የፐርኮና-አገልጋይ ውቅር ሙከራ ምሳሌ፡-

mkdir -p {mysql_config_test,mysql_data,mysql_logs}
cp -r /etc/mysql/conf.d/* mysql_config_test/
docker run  --name some-percona -v $(pwd)/mysql_config_test:/etc/my.cnf.d/  -v $(pwd)/mysql_data/:/var/lib/mysql/ -v $(pwd)/mysql_logs/:/var/log/mysql/ -e MYSQL_ROOT_PASSWORD=${MYSQL_PASSWORD} -d percona:8-centos

የታችኛው መስመር: በ Docker ምዝግብ ማስታወሻዎች ውስጥ ወይም በማውጫው ውስጥ ከመዝገቦች ጋር - እንደ ውቅሮችዎ - ችግር ያለባቸው መመሪያዎች የሚገለጹበት ፋይል ይታያል.

ያለን ነገር ይኸውና፡-

2020-04-03T12:44:19.670831Z 0 [Warning] [MY-011068] [Server] The syntax 'expire-logs-days' is deprecated and will be removed in a future release. Please use binlog_expire_logs_seconds instead.
2020-04-03T12:44:19.671678Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous.
2020-04-03T12:44:19.671682Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci' is a collation of the deprecated character set UTF8MB3. Please consider using UTF8MB4 with an appropriate collation instead.

ስለዚህ፣ አሁንም ኢንኮዲንግዎቹን ፈልጎ ማግኘት እና ያለፈውን መመሪያ መተካት ያስፈልገናል expire-logs-days.

ክፍል 2: የሚሰሩ ጭነቶችን መፈተሽ

የዝማኔው ሰነድ የውሂብ ጎታውን ተኳሃኝነት ለማረጋገጥ 2 መገልገያዎችን ይዟል። የእነርሱ አጠቃቀም አስተዳዳሪው ያለውን የውሂብ መዋቅር ተኳሃኝነት ለማረጋገጥ ይረዳል.

በሚታወቀው mysqlcheck መገልገያ እንጀምር። በቀላሉ አሂድ፡

mysqlcheck -u root -p --all-databases --check-upgrade

ምንም ችግሮች ካልተገኙ መገልገያው በኮድ 0 ይወጣል፡-

MySQL (Percona Server) ከ 5.7 ወደ 8.0 በማዘመን ላይ

በተጨማሪም መገልገያ በዘመናዊ MySQL ስሪቶች ውስጥ ይገኛል mysql-ሼል (በፔርኮና ጉዳይ ይህ ጥቅል ነው። percona-mysql-shell). ለጥንታዊው mysql ደንበኛ ምትክ ሲሆን የደንበኛን፣ የSQL ኮድ አርታዒ እና MySQL አስተዳደር መሳሪያዎችን ያጣምራል። ከማዘመንዎ በፊት አገልጋዩን ለመፈተሽ የሚከተሉትን ትዕዛዞች በእሱ ውስጥ ማስኬድ ይችላሉ-

mysqlsh -- util check-for-server-upgrade { --user=root --host=1.1.1.1 --port=3306 } --config-path=/etc/mysql/my.cnf

የተቀበልናቸው አስተያየቶች እነሆ፡-

MySQL (Percona Server) ከ 5.7 ወደ 8.0 በማዘመን ላይ

በአጠቃላይ ምንም ወሳኝ ነገር የለም - ስለ ኢንኮዲንግ ማስጠንቀቂያዎች ብቻ (ከስር ተመልከት). አጠቃላይ የአፈፃፀም ውጤት;

MySQL (Percona Server) ከ 5.7 ወደ 8.0 በማዘመን ላይ

ዝመናው ያለችግር እንዲሄድ ወስነናል።

ከላይ ስላሉት ማስጠንቀቂያዎች ማስታወሻ ኮዲንግ ላይ ያሉ ችግሮችን የሚያመለክት። እውነታው ግን UTF-8 በ MySQL ውስጥ እስከ ቅርብ ጊዜ ድረስ ነው UTF-8 "እውነት" አልነበረምከ 3 ይልቅ 4 ባይት ብቻ ስለሚከማች በ MySQL 8 ይህ በመጨረሻ ነው ለማስተካከል ወሰነ: ተለዋጭ ስም utf8 በቅርቡ ወደ ኮድ ማውጣትን ያመጣል utf8mb4, እና በሠንጠረዦቹ ውስጥ ያሉት አሮጌ ዓምዶች ይሆናሉ utf8mb3. ተጨማሪ ኢንኮዲንግ utf8mb3 ይወገዳል፣ ነገር ግን በዚህ ልቀት ውስጥ የለም። ስለዚህ ፣ በዲቢኤምኤስ ጭነት ላይ ያሉትን ኢንኮዲንግ ካዘመንን በኋላ ቀድሞውኑ ለማረም ወስነናል።

ክፍል 3: የአገልጋይ ዝማኔዎች

እንደዚህ አይነት ብልህ እቅድ ሲኖር ምን ችግር ሊፈጠር ይችላል?... ድክመቶች ሁል ጊዜ እንደሚከሰቱ በደንብ በመረዳት፣ የመጀመሪያውን ሙከራ በ MySQL ዴቭ ክላስተር ላይ አድርገናል።

ቀደም ሲል እንደተጠቀሰው ፣ ኦፊሴላዊ ሰነዶች MySQL አገልጋዮችን በቅጂዎች የማዘመን ጉዳይን ይሸፍናል። ዋናው ነገር MySQL 8 ከዋናው ስሪት 5.7 ሊባዛ ስለሚችል በመጀመሪያ ሁሉንም ቅጂዎች (ባሪያዎች) ማዘመን አለብዎት። አንዳንድ ችግሮች ሁነታውን በመጠቀማችን ላይ ነው ማስተር <-> ማስተር, የርቀት ማስተር ሞድ ላይ ሲሆን ለማንበብ ብቻ የተፈቀደ. ያም ማለት በእውነቱ, የውጊያ ትራፊክ ወደ አንድ የመረጃ ማእከል ይሄዳል, ሁለተኛው ደግሞ ምትኬ ነው.

ቶፖሎጂ ይህንን ይመስላል።

MySQL (Percona Server) ከ 5.7 ወደ 8.0 በማዘመን ላይ

ዝማኔው በቅጂዎች መጀመር አለበት። mysql ቅጂ dc 2, mysql master dc 2 и mysql replica dc 1, እና በ mysql master dc 1 አገልጋይ እንጨርሳለን የበለጠ አስተማማኝ ለመሆን ቨርቹዋል ማሽኖቹን አቁመን ቅጽበተ-ፎቶዎችን አንስተናል እና ዝመናው በትእዛዙ ማባዛትን ከማቆሙ በፊት ወዲያውኑ STOP SLAVE. የተቀረው ዝመና ይህን ይመስላል።

  1. ወደ ውቅሮቹ 3 አማራጮችን በመጨመር እያንዳንዱን ቅጂ እንደገና እንጀምራለን- skip-networking, skip-slave-start, skip-log-bin. እውነታው ግን የውሂብ ጎታውን ማዘመን የስርዓት ሰንጠረዦችን በማዘመን ሁለትዮሽ ምዝግብ ማስታወሻዎችን ያመነጫል. እነዚህ መመሪያዎች በመረጃ ቋቱ ውስጥ በመተግበሪያ ውሂብ ላይ ምንም አይነት ለውጥ እንደማይኖር ዋስትና ይሰጣሉ፣ እና የስርዓት ሰንጠረዦችን ስለማዘመን መረጃ በሁለትዮሽ ምዝግብ ማስታወሻዎች ውስጥ አይካተትም። ይህ ማባዛትን በሚቀጥልበት ጊዜ ችግሮችን ያስወግዳል.
  2. ጥቅሉን በመጫን ላይ percona-server-server. በ MySQL ስሪት 8 ውስጥ መሆኑን ልብ ሊባል ይገባል አይደለም ትዕዛዙን ማስኬድ ያስፈልግዎታል mysqlupgrade ከአገልጋይ ዝመና በኋላ.
  3. ከተሳካ ጅምር በኋላ አገልጋዩን እንደገና እናስጀምረዋለን - በመጀመሪያው አንቀጽ ላይ የተጨመሩት መለኪያዎች ሳይኖሩ።
  4. ማባዛት በተሳካ ሁኔታ እንደሚሰራ እናረጋግጣለን፡ አረጋግጥ SHOW SLAVE STATUS እና በመተግበሪያው ዳታቤዝ ውስጥ ቆጣሪዎች ያሉት ጠረጴዛዎች እንደተዘመኑ ይመልከቱ።

ሁሉም ነገር በጣም ቀላል ነው የሚመስለው፡ የዴቭ ዝማኔው የተሳካ ነበር። እሺ፣ ለምርት የምሽት ዝማኔን በደህና ማቀድ ይችላሉ።

ምንም ሀዘን አልነበረም - ፕሮዱን አዘምነናል።

ይሁን እንጂ የተሳካለት የዴቭ ልምድ ወደ ምርት ማሸጋገር ያለ ድንገተኛ አልነበረም።

እንደ እድል ሆኖ፣ የማዘመን ሂደቱ በራሱ ቅጂዎች ይጀምራል፣ ስለዚህ ችግሮች ሲያጋጥሙን ስራውን አቁመን ቅጂውን ከቅጽበተ-ፎቶው ወደነበረበት መልሰናል። የችግሮቹ ምርመራ እስከሚቀጥለው ጠዋት ድረስ ለሌላ ጊዜ ተላልፏል. መዝገቦቹ የሚከተሉትን ግቤቶች ይይዛሉ።

2020-01-14T21:43:21.500563Z 2 [ERROR] [MY-012069] [InnoDB] table: t1 has 19 columns but InnoDB dictionary has 20 columns
2020-01-14T21:43:21.500722Z 2 [ERROR] [MY-010767] [Server] Error in fixing SE data for db1.t1
2020-01-14T21:43:24.208365Z 0 [ERROR] [MY-010022] [Server] Failed to Populate DD tables.
2020-01-14T21:43:24.208658Z 0 [ERROR] [MY-010119] [Server] Aborting

በጎግል ላይ ያሉ የተለያዩ የደብዳቤ መላኪያ ዝርዝሮችን ማህደሮች መመርመር ይህ ችግር የሚከሰተው በምክንያት እንደሆነ ለመረዳት አስችሏል። MySQL ስህተት. ምንም እንኳን ይህ ምናልባት የመገልገያ ስህተት ሊሆን ይችላል። mysqlcheck и mysqlsh.

MySQL ለአስርዮሽ መስኮች (int, tinyint, ወዘተ.) ውሂብን የሚወክሉበትን መንገድ ቀይሯል, ስለዚህ mysql-ሰርቨር እነሱን ለማከማቸት ሌላ መንገድ ይጠቀማል. የውሂብ ጎታዎ ከሆነ መጀመሪያ ላይ በስሪት 5.5 ወይም 5.1 ነበር፣ እና ከዚያ ወደ 5.7 አዘምነዋል፣ ከዚያ ማድረግ ሊኖርብዎ ይችላል። OPTIMIZE ለአንዳንድ ጠረጴዛዎች. ከዚያ MySQL የውሂብ ፋይሎችን ያዘምናል, ወደ የአሁኑ የማከማቻ ቅርጸት ያስተላልፋቸዋል.

ይህንንም በፍጆታ ማረጋገጥ ይችላሉ። mysqlfrm:

mysqlfrm --diagnostic -vv /var/lib/mysql/db/table.frm
...
 'field_length': 8,
  'field_type': 246, # формат поля
  'field_type_name': 'decimal',
  'flags': 3,
  'flags_extra': 67,
  'interval_nr': 0,
 'name': 'you_deciaml_column',
...

ከሆነ field_type ከ 0 ጋር እኩል ከሆነ, የድሮው አይነት በጠረጴዛው ውስጥ ጥቅም ላይ ይውላል - ማከናወን ያስፈልግዎታል OPTIMIZE. ነገር ግን, እሴቱ 246 ከሆነ, ቀድሞውኑ አዲስ ዓይነት አለዎት. ስለ ዓይነቶች ተጨማሪ መረጃ በ ውስጥ ይገኛል። ኮድ.

በተጨማሪም ፣ ውስጥ ይህ ስህተት እኛን ያለፈውን ሁለተኛውን ምክንያት እያሰብን ነው-በስርዓት ሠንጠረዥ ውስጥ የ InnoDB ጠረጴዛዎች አለመኖር INNODB_SYS_TABLESPACESእነሱ, ሰንጠረዦች, በስሪት 5.1 ውስጥ ከተፈጠሩ. በማዘመን ጊዜ ችግሮችን ለማስወገድ, መጠቀም ይችላሉ ተያይዟል SQL ስክሪፕት.

ለምን በዴቭ ላይ እንደዚህ አይነት ችግሮች አላጋጠሙንም? የመረጃ ቋቱ በየጊዜው እዚያ ከምርት ይገለበጣል - ስለዚህ ፣ ጠረጴዛዎች እንደገና ተፈጥረዋል.

እንደ አለመታደል ሆኖ፣ በእውነት በሚሰራ ትልቅ የውሂብ ጎታ ላይ፣ ሁለንተናዊን ብቻ መውሰድ እና ማስፈጸም አይችሉም OPTIMIZE. percona-Toolkit እዚህ ይረዳል፡ pt-online-schema-change utility ለመስመር ላይ OPTIMIZE ስራ በጣም ጥሩ ነው።

የተሻሻለው እቅድ ይህን ይመስላል፡-

  1. ሁሉንም ጠረጴዛዎች ያመቻቹ።
  2. የውሂብ ጎታዎችን አዘምን.

እሱን ለመፈተሽ እና በተመሳሳይ ጊዜ የማሻሻያ ሰዓቱን ለማወቅ ከቅጂዎቹ ውስጥ አንዱን አሰናክለን እና ለሁሉም ሰንጠረዦች የሚከተለውን ትዕዛዝ አስሄድን።

pt-online-schema-change --critical-load Threads_running=150 --alter "ENGINE=InnoDB" --execute --chunk-size 100 --quiet --alter-foreign-keys-method auto h=127.0.0.1,u=root,p=${MYSQL_PASSWORD},D=db1,t=t1

ሰንጠረዦች ያለ ረጅም መቆለፊያዎች ተዘምነዋል ምክንያቱም መገልገያው ከዋናው ጠረጴዛ ላይ መረጃን የሚቀዳበት አዲስ ጊዜያዊ ሠንጠረዥ ይፈጥራል. በአሁኑ ጊዜ ሁለቱም ጠረጴዛዎች ተመሳሳይ ሲሆኑ ዋናው ጠረጴዛ ተቆልፎ በአዲሱ ተተክቷል. በእኛ ሁኔታ, አንድ የሙከራ ሩጫ ሁሉንም ጠረጴዛዎች ለማዘመን አንድ ቀን ያህል እንደሚፈጅ አሳይቷል, ነገር ግን መረጃን መቅዳት በዲስኮች ላይ በጣም ብዙ ጭነት አስከትሏል.

ይህንን ለማስቀረት በምርት ውስጥ ክርክሩን በትእዛዙ ላይ ጨምረናል። --sleep ከ 10 እሴት ጋር - ይህ ግቤት የውሂብ ስብስብን ወደ አዲስ ጠረጴዛ ካስተላለፈ በኋላ የጥበቃውን ርዝመት ያስተካክላል. ትክክለኛው አሂድ መተግበሪያ በምላሽ ጊዜ የሚፈልግ ከሆነ በዚህ መንገድ ጭነቱን መቀነስ ይችላሉ።

ማሻሻያውን ካከናወነ በኋላ ዝመናው ስኬታማ ነበር።

... ግን ሙሉ በሙሉ አይደለም!

ከዝማኔው በኋላ በግማሽ ሰዓት ውስጥ ደንበኛው ችግር አጋጥሞታል። የመረጃ ቋቱ በጣም በሚገርም ሁኔታ ሰርቷል፡ በየጊዜው ጀመሩ የግንኙነት ዳግም ማስጀመር. በክትትል ውስጥ ይህ ይመስላል።

MySQL (Percona Server) ከ 5.7 ወደ 8.0 በማዘመን ላይ

አንዳንድ የ MySQL አገልጋይ ክሮች ከጊዜ ወደ ጊዜ በስህተት በመበላሸታቸው የስክሪፕቱ ፎቶግራፍ የ sawtooth ግራፍ ያሳያል። በመተግበሪያው ውስጥ ስህተቶች ታይተዋል፡-

[PDOException] SQLSTATE[HY000] [2002] Connection refused

የምዝግብ ማስታወሻዎች ፈጣን ፍተሻ mysqld ዴሞን ከስርዓተ ክወናው የሚፈለጉትን ግብዓቶች ማግኘት አልቻለም። ስህተቶችን በምንፈታበት ጊዜ በስርዓቱ ውስጥ አግኝተናል "ወላጅ አልባ" apparmor ፖሊሲ ፋይሎች:

# dpkg -S /etc/apparmor.d/cache/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/cache/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/local/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/local/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/usr.sbin.mysqld
mysql-server-5.7: /etc/apparmor.d/usr.sbin.mysqld
# dpkg -l mysql-server-5.7
rc  mysql-server-5.7 5.7.23-0ubuntu0.16.04.1      amd64

እነዚህ ፋይሎች የተፈጠሩት ከጥቂት አመታት በፊት ወደ MySQL 5.7 ሲያሻሽሉ እና የተወገደ ጥቅል ውስጥ ናቸው። ፋይሎቹን መሰረዝ እና የመሳሪያውን አገልግሎት እንደገና ማስጀመር ችግሩን ፈታው

systemctl stop apparmor
rm /etc/apparmor.d/cache/usr.sbin.mysqld
rm /etc/apparmor.d/local/usr.sbin.mysqld
rm /etc/apparmor.d/usr.sbin.mysqld
systemctl start apparmor

በማጠቃለያው

ማንኛውም, በጣም ቀላሉ ቀዶ ጥገና እንኳን, ወደ ያልተጠበቁ ችግሮች ሊያመራ ይችላል. እና በደንብ የታሰበበት እቅድ እንኳን ሁልጊዜ የሚጠበቀው ውጤት ዋስትና አይሆንም. አሁን፣ ማንኛውም የማሻሻያ ዕቅዶች ቡድናችን በቅርብ ጊዜ በተደረጉ ድርጊቶች ምክንያት ሊከሰቱ የሚችሉ አላስፈላጊ ፋይሎችን የግድ ማጽዳትንም ያካትታል።

እና በዚህ በጣም ፕሮፌሽናል ግራፊክ ፈጠራ አይደለም ፣ ለምርጥ ምርቶቻቸው ለፔርኮና በጣም አመሰግናለሁ ማለት እፈልጋለሁ!

MySQL (Percona Server) ከ 5.7 ወደ 8.0 በማዘመን ላይ

PS

በብሎጋችን ላይ ያንብቡ፡-

ምንጭ: hab.com

አስተያየት ያክሉ