ProHoster > බ්ලොග් > පරිපාලනය > 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 අනුවාදයට යාවත්කාලීන කිරීමට කාලය පැමිණ තිබේ. මේ සියල්ල සිදු වූයේ Ubuntu Linux 16.04 වේදිකාවේ ය. අවම අක්‍රිය කාලයක් සමඟ එවැනි මෙහෙයුමක් සිදු කරන්නේ කෙසේද සහ යාවත්කාලීන කිරීමේදී අපට ඇති වූ ගැටළු මොනවාද - මෙම ලිපියෙන් කියවන්න.

සකස් කිරීම

දත්ත සමුදා සේවාදායකයේ ඕනෑම යාවත්කාලීන කිරීමක් බොහෝ විට දත්ත සමුදා ප්‍රතිනිර්මාණය සමඟ සම්බන්ධ වේ: පද්ධති සම්පත් වල සීමාවන් සඳහා අවශ්‍යතා වෙනස් කිරීම සහ යල් පැන ගිය විධාන වලින් ඉවත් කළ යුතු දත්ත සමුදා වින්‍යාස නිවැරදි කිරීම.

යාවත්කාලීන කිරීමට පෙර, අපි අනිවාර්යයෙන්ම නිල ලේඛන වෙත යොමු වන්නෙමු:

සහ අපි ක්රියාකාරී සැලැස්මක් සකස් කරමු:

  1. යල් පැන ගිය විධාන ඉවත් කිරීමෙන් වින්‍යාස ගොනු නිවැරදි කරන්න.
  2. උපයෝගිතා සමඟ අනුකූලතාව පරීක්ෂා කරන්න.
  3. පැකේජය ස්ථාපනය කිරීමෙන් වහල් දත්ත සමුදායන් යාවත්කාලීන කරන්න percona-server-server.
  4. එකම පැකේජය සමඟ මාස්ටර් යාවත්කාලීන කරන්න.

සැලැස්මේ එක් එක් ලක්ෂ්යය දෙස බලමු සහ වැරදි විය හැකි දේ බලමු.

වැදගත්! Galera මත පදනම් වූ 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.

පරීක්ෂා කිරීමට, අපි Percona සේවාදායකයේ ඩොකර් රූපය භාවිතා කරන්නෙමු. අපි සේවාදායක වින්‍යාසය නාමාවලියෙහි තබමු mysql_config_test, සහ ඊළඟට අපි දත්ත සහ ලොග් සඳහා නාමාවලි සාදන්නෙමු. Percona-සේවාදායක වින්‍යාස පරීක්ෂණ උදාහරණය:

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

පහළ පේළිය: ඩොකර් ලොගවල හෝ ලොග සහිත නාමාවලියෙහි - ඔබගේ වින්‍යාසය මත පදනම්ව - ගැටළු සහගත විධාන විස්තර කෙරෙන ගොනුවක් දිස්වනු ඇත.

මෙන්න අපට තිබූ දේ:

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-shell (පර්කෝනා සම්බන්ධයෙන් ගත් කල, මෙය පැකේජයයි 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 දක්වා යාවත්කාලීන කිරීම

යාවත්කාලීන කිරීම ගැටළු නොමැතිව යා යුතු බව අපි තීරණය කළෙමු.

කේතීකරණ සමඟ ගැටලු පෙන්නුම් කරන ඉහත අනතුරු ඇඟවීම් පිළිබඳ සටහනක්. කාරණය නම් මෑතක් වන තුරුම MySQL හි UTF-8 ය UTF-8 "සත්‍ය" නොවේ, එය ගබඩා කර ඇත්තේ 3 වෙනුවට බයිට් 4ක් පමණක් බැවින්. MySQL 8 හි මෙය අවසාන වශයෙන් වේ එය නිවැරදි කිරීමට තීරණය කළේය: අන්වර්ථ නාමයක් utf8 ඉක්මනින් කේතනය කිරීමට තුඩු දෙනු ඇත utf8mb4, සහ වගු වල පැරණි තීරු බවට පත් වනු ඇත utf8mb3. තවදුරටත් කේතනය කිරීම utf8mb3 ඉවත් කරනු ඇත, නමුත් මෙම නිකුතුවේ නොවේ. එබැවින්, එය යාවත්කාලීන කිරීමෙන් පසුව, ධාවනය වන DBMS ස්ථාපනය මත දැනටමත් කේතනය නිවැරදි කිරීමට අපි තීරණය කළෙමු.

3 කොටස: සේවාදායක යාවත්කාලීන

එවැනි ස්මාර්ට් සැලැස්මක් ඇති විට සිදුවිය හැක්කේ කුමක්ද?

දැනටමත් සඳහන් කර ඇති පරිදි, නිල ලියකියවිලි MySQL සේවාදායකයන් අනුරූ සමඟ යාවත්කාලීන කිරීමේ ගැටළුව ආවරණය කරයි. අවසාන කරුණ නම් MySQL 8 හට ප්‍රධාන අනුවාදය 5.7 වෙතින් ප්‍රතිවර්තනය කළ හැකි බැවින් ඔබ ප්‍රථමයෙන් සියලුම අනුරූ (වහල්) යාවත්කාලීන කළ යුතු බවයි. අපි මාදිලිය භාවිතා කරන කාරනය තුළ යම් දුෂ්කරතාවයක් පවතී master master, දුරස්ථ මාස්ටර් මාදිලියේ ඇති විට කියවීමට පමණි. එනම්, ඇත්ත වශයෙන්ම, සටන් ගමනාගමනය එක් දත්ත මධ්යස්ථානයකට යන අතර, දෙවන එක උපස්ථ එකක් වේ.

ස්ථලකය මේ වගේ ය:

MySQL (Percona Server) 5.7 සිට 8.0 දක්වා යාවත්කාලීන කිරීම

යාවත්කාලීන කිරීම අනුරූ වලින් ආරම්භ විය යුතුය mysql replica 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 යෙදුම් දත්ත ගබඩාවේ කවුන්ටර සහිත වගු යාවත්කාලීන කර ඇති බව බලන්න.

එය ඉතා සරල බව පෙනේ: dev යාවත්කාලීන කිරීම සාර්ථක විය. හරි, ඔබට නිෂ්පාදනය සඳහා රාත්‍රී යාවත්කාලීනයක් ආරක්ෂිතව උපලේඛනගත කළ හැක.

දුකක් නැත - අපි නිෂ්පාදනය යාවත්කාලීන කළෙමු

කෙසේ වෙතත්, සාර්ථක dev අත්දැකීම් නිෂ්පාදනයට මාරු කිරීම විස්මයන් නොමැතිව නොවේ.

වාසනාවකට මෙන්, යාවත්කාලීන කිරීමේ ක්‍රියාවලියම අනුරූ වලින් ආරම්භ වේ, එබැවින් අපට දුෂ්කරතා ඇති වූ විට, අපි වැඩ නතර කර ස්නැප්ෂොට් වෙතින් අනුරුව ප්‍රතිසාධනය කළෙමු. ගැටළු විමර්ශනය පසුදා උදෑසන දක්වා කල් තැබිණි. ලඝු-සටහන් පහත සඳහන් ඇතුළත් කිරීම් අඩංගු විය:

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

Google හි විවිධ තැපැල් ලැයිස්තු වල ලේඛනාගාරය ගවේෂණය කිරීමෙන් මෙම ගැටළුව ඇති වන්නේ MySQL දෝෂය. මෙය බොහෝ දුරට උපයෝගිතා දෝෂයක් වුවද mysqlcheck и mysqlsh.

MySQL දශම ක්ෂේත්‍ර (int, tinyint, ආදිය) සඳහා දත්ත නියෝජනය කරන ආකාරය වෙනස් කර ඇති බව පෙනේ, එබැවින් mysql-server ඒවා ගබඩා කිරීමට වෙනත් ක්‍රමයක් භාවිතා කරයි. ඔබගේ දත්ත සමුදාය නම් මුලදී 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 ස්ක්‍රිප්ට්.

ඇයි අපිට dev එකේ එහෙම ප්‍රශ්න ඇති වුනේ නැත්තේ? දත්ත සමුදාය වරින් වර නිෂ්පාදනයෙන් පිටපත් කරනු ලැබේ - මේ අනුව, වගු නැවත සාදා ඇත.

අවාසනාවකට, ඇත්ත වශයෙන්ම වැඩ කරන විශාල දත්ත සමුදායක් මත, ඔබට විශ්වීය එකක් ගෙන ක්‍රියාත්මක කිරීමට නොහැකි වනු ඇත. OPTIMIZE. percona-toolkit මෙහිදී උපකාර වනු ඇත: pt-online-schema-change උපයෝගීතාව මාර්ගගත 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 සේවාදායක නූල් වරින් වර දෝෂයකින් බිඳ වැටීම නිසා තිර රුවක් කියත් දත් ප්‍රස්ථාරයක් පෙන්වයි. යෙදුමේ දෝෂ දර්ශනය විය:

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

ලඝු-සටහන් ක්ෂණිකව පරීක්ෂා කිරීමේදී mysqld daemon හට මෙහෙයුම් පද්ධතියෙන් අවශ්‍ය සම්පත් ලබා ගත නොහැකි බව අනාවරණය විය. දෝෂ නිරාකරණය කිරීමේදී, අපි පද්ධතිය තුළ සොයාගත්තා "අනාථ" 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 වෙත උත්ශ්‍රේණි කිරීමේදී නිර්මාණය කරන ලද අතර ඒවා ඉවත් කරන ලද පැකේජයකට අයත් වේ. ගොනු මකා දැමීම සහ apparmor සේවාව නැවත ආරම්භ කිරීම ගැටළුව විසඳා ඇත:

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 දක්වා යාවත්කාලීන කිරීම

ප්රාදේශීය සභා

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

මූලාශ්රය: www.habr.com

අදහස් එක් කරන්න