විශාල .sql ගොනුවක් ආනයනය කිරීමේ ප්‍රගතිය නිරීක්ෂණය කරන්නේ කෙසේද?


220

foobar.sqlදේශීය දත්ත ගබඩාවක වගුවක් යථා තත්වයට පත් කිරීම සඳහා මම 7 GB ආනයනය කරමි .

$ mysql -h localhost -u root 'my_data' < foobar.sql

$ mysql --version
/usr/local/mysql/bin/mysql  Ver 14.12 Distrib 5.0.96, for apple-darwin9.8.0 (i386) using readline 5.1

එහි ප්‍රගතිය නිරීක්ෂණය කරන්නේ කෙසේද?


1
මෙම ප්‍රශ්නයට පිළිතුරු වලින් පෙනී යන්නේ මෙය
MySQL

Answers:


289

ඔබ * nix හි CLI වෙතින් ඩම්ප් ගොනුවකින් ආනයනය කරන්නේ නම්, උදා

mysql -uxxx -pxxx dbname < /sqlfile.sql

පළමුව ඔබේ මෙහෙයුම් පද්ධතියේ නල නරඹන්නා ස්ථාපනය කර මෙවැනි දෙයක් උත්සාහ කරන්න:

pv sqlfile.sql | mysql -uxxx -pxxxx dbname

වැඩසටහන ක්‍රියාත්මක වන විට එය ප්‍රගති තීරුවක් පෙන්වනු ඇත.

එය ඉතා ප්‍රයෝජනවත් වන අතර ඔබට mysqldump ප්‍රගතිය සඳහා ඇස්තමේන්තුවක් ලබා ගැනීමටද එය භාවිතා කළ හැකිය.

pv ඒවා ඉවත ලන අතර sqlfile.sqlඒවා mysql වෙත යවයි (නල ක්‍රියාකරු නිසා). එය ඉවත ලන අතරතුර, එය ප්රගතිය පෙන්නුම් කරයි. සිසිල් දෙය නම්, MySQL විසින් දත්ත ලබා ගන්නේ එය ඉදිරියට යා හැකි තරම් වේගයෙන් වන නිසා pv මඟින් ආනයනයේ ප්‍රගතිය පෙන්විය හැකිය. මට කිසිම සාක්ෂියක් නැහැ. නමුත් එය එසේ බව පෙනේ. සමහර බෆරයක් භාවිතා කර ඇති බව මම අනුමාන කරමි, නමුත් සමහර mysqlවිට එය කාර්යබහුල සැකසුම් තුළ තවත් දත්ත කියවන්නේ නැත.

පයිප්ප නරඹන්නාගේ තිර රුව


1
මයිස්ක්ල් බෆරයක් තිබිය හැකි යැයි මම අනුමාන කරමි, එහි සමහර දත්ත සම්පුර්ණයෙන්ම “සැකසීමෙන්” තොරව නල කළ හැකිය (එනම් එය දෝෂ සහිත නම්, පීවී ඇත්ත වශයෙන්ම ලැබෙන්නේ කුමක් දැයි තරමක් වාර්තා කර තිබිය හැක). නමුත් පොදුවේ ගත් කල, පයිප්ප ක්‍රියා කරන්නේ එලෙස ය. ඔබට කළ හැකි එකම හේතුව sudo hd /dev/sda1 | lessසහ ඔබේ මුළු පද්ධති කොටසම මතකයේ තබා නොගැනීමයි.
snapfractalpop

3
snapfractalpop pvබොහෝ අවස්ථාවන්හිදී ඕනෑවට වඩා නිවැරදි නොවනු ඇත, මන්ද SQL හි සමහර කොටස් අනෙක් ඒවාට වඩා සැකසීමට වැඩි කාලයක් ගතවනු ඇත. නිදසුනක් ලෙස, දැනටමත් පේළි රාශියක් ඇති වගුවක දර්ශකය මත සාදන සරල රේඛාවකට වඩා වේගයෙන් ඇතුල් වේ. නමුත් ප්‍රගතිය පිළිබඳ දළ අදහසක් මඟින් කියවන බෆරය mysqlවිශේෂයෙන් විශාල නොවන්නේ නම් ප්‍රතිදානය ප්‍රයෝජනවත් විය යුතුය (7Gb ආදානය සඳහා බෆරය ඉතා විශාල විය යුතු අතර pvඑහි ප්‍රතිදානය කිසිසේත්ම ප්‍රයෝජනවත් නොවේ.
ඩේවිඩ් ස්පිලට්

1
Av ඩේවිඩ්ස්පිලට් ඇත්ත වශයෙන්ම. ඔබේ ප්‍රකාශය මගේ හැඟීම පිළිබිඹු කරයි. මූලික වශයෙන්, පීවී ගොරෝසු, නමුත් .ලදායී වේ. මම එයට වඩාත්ම කැමති දෙය එය කෙතරම් සාමාන්‍යද යන්නයි. යුනික්ස් පයිප්පවල සුන්දරත්වය එයයි (ස්තූතියි මැක්ල්රෝයි).
snapfractalpop

1
@rob මේක නියමයි මචං, ඔබටත් උදාහරණයක් දෙන්න mysqldumpපුළුවන්ද?
ජොසු ඇලෙක්සැන්ඩර් ඉබරා

ඉතා හොඳ විසඳුමක්! මුරපදය අත්පොත නම්, pv එහි ප්‍රගතිය පෙන්වන තෙක් බලා
නොසිටිනු ඇත

32

ඔබ දැනටමත් ආයාත කිරීම ආරම්භ කර ඇත්නම්, ඔබේ දත්ත ගබඩාවල වත්මන් ප්‍රමාණය බැලීමට ඔබට මෙම විධානය වෙනත් කවුළුවකින් ක්‍රියාත්මක කළ හැකිය. ඔබ ආනයනය කරන .sql ගොනුවේ මුළු ප්‍රමාණය ඔබ දන්නේ නම් මෙය ප්‍රයෝජනවත් වේ.

SELECT table_schema "Data Base Name", sum( data_length + index_length ) / 1024 / 1024 "Data Base Size in MiB" 
FROM information_schema.TABLES GROUP BY table_schema;  

ණය: http://forums.mysql.com/read.php?108,201578,201578


මෙම MySQL 8.0 විමර්ශන නිරවද්යතාව ගැන පහත සඳහන් මෙසේ සඳහන්

DATA_LENGTH

MyISAM සඳහා, DATA_LENGTH යනු දත්ත ගොනුවේ දිග බයිට් වලින් වේ.

InnoDB සඳහා, DATA_LENGTH යනු පොකුරු දර්ශකය සඳහා බයිට් වලින් වෙන් කර ඇති ආසන්න මතක ප්‍රමාණයයි. නිශ්චිතවම, එය පොකුරු දර්ශක ප්‍රමාණය, පිටු වල, InnoDB පිටු ප්‍රමාණයෙන් ගුණ කරනු ලැබේ.

 

INDEX_LENGTH

MyISAM සඳහා, INDEX_LENGTH යනු දර්ශක ගොනුවේ දිග බයිට් වලින් වේ.

InnoDB සඳහා, INDEX_LENGTH යනු පොකුරු නොවන දර්ශක සඳහා බයිට් වලින් වෙන් කර ඇති ආසන්න මතක ප්‍රමාණයයි. නිශ්චිතවම, එය පොකුරු නොවන දර්ශක ප්‍රමාණවල එකතුවකි, පිටු වල, InnoDB පිටු ප්‍රමාණයෙන් ගුණ කරනු ලැබේ.


මෙම පිළිතුරේ විධානයන්ට අනුව මගේ වගුව දැන් 12 GiB වේ, තවමත් ආනයනය කරයි. මගේ sqldump ගොනුව 5 GiB පමණි. මෙම විෂමතාවය පිළිබඳ පැහැදිලි කිරීමක් කිරීමට මා උනන්දු වනු ඇත
lucidbrot

1
@lucidbrot ඔබේ වර්ග ගොනුව gzipped ද?
ට්චලාකා

17

ඔබ තනි දත්ත ගබඩාවක mysqldump ක්‍රියාත්මක කරන විට, සියලු වගු අකාරාදී පිළිවෙලට දමනු ලැබේ.

ස්වාභාවිකවම, mysqldump දත්ත ගබඩාවකට නැවත පූරණය කිරීම අකාරාදී පිළිවෙලට වනු ඇත.

ඔබට ප්‍රදර්ශන ක්‍රියාවලියක් කළ හැකිය; සහ mysqldump ධාවනය වන DB සම්බන්ධතාවය සොයා ගන්න. ඩම්ප් නැවත පූරණය කළ විට, ඩීබී සම්බන්ධතාවය අතුරුදහන් වේ.

ඩම්ප්ෆයිල් හි ඇති වගු මොනවාදැයි දැන ගැනීමට ඔබට අවශ්‍ය නම්, මෙය foobar.sql ට එරෙහිව ධාවනය කරන්න

cat foobar.sql | grep "^CREATE TABLE" | awk '{print $3}'

UPDATE 2012-05-02 13:53 EDT

එක් වගුවක් පමණක් ඇති බව නොදැන සිටීම ගැන කණගාටුයි.

වගුව MyISAM නම්, අධීක්ෂණය කළ හැකි එකම ක්‍රමය OS දෘෂ්ටි කෝණයෙන් ය. හේතුව? නැවත පූරණය වන විට වගුව ලිවීමට අගුළු දමා ඇත. ඔබ සොයන්නේ කුමක් ද? .MYDසහ .MYIගොනු වල ප්‍රමාණය . ඇත්ත වශයෙන්ම, ඔබ ආනයනය කළ අනෙක් ඩීබී සේවාදායකයේ පෙර වගුවේ ප්‍රමාණය සමඟ සැසඳිය යුතුය.

වගුව InnoDB නම් සහ ඔබට innodb_file_per_table සක්‍රීය කර ඇත්නම් , අධීක්ෂණය කිරීමට ඇති එකම ක්‍රමය OS දෘෂ්ටි කෝණයෙන් පමණි. හේතුව? නැවත පූරණය වන විට වගුව ලිවීමට අගුළු දමා ඇත. ඔබ සොයන්නේ කුමක් ද? .ibdගොනුවේ විශාලත්වය . ඇත්ත වශයෙන්ම, ඔබ ආනයනය කළ අනෙක් ඩීබී සේවාදායකයේ පෙර වගුවේ ප්‍රමාණය සමඟ සැසඳිය යුතුය.

වගුව InnoDB නම් සහ ඔබට innodb_file_per_table අක්‍රීය කර ඇත්නම් , OS දෘෂ්ටි කෝණයෙන් පවා උදව් කළ නොහැක.

UPDATE 2012-05-02 13:56 EDT

මම පසුගිය වසරේදී මෙවැනි දෙයක් ඇමතුවෙමි: "db.sql | mysql ටයිප් කරන්න" සඳහා% ප්‍රගතියක් ලබා ගන්නේ කෙසේද?

UPDATE 2012-05-02 14:09 EDT

සම්මත mysqldump ලිවීම අගුළු දමා ඇති බැවින් මේ වගේ:

LOCK TABLES `a` WRITE;
/*!40000 ALTER TABLE `a` DISABLE KEYS */;
INSERT INTO `a` VALUES (123),(451),(199),(0),(23);
/*!40000 ALTER TABLE `a` ENABLE KEYS */;
UNLOCK TABLES;

එවිට, මේස අගුල මුදා හරින තුරු mysql සමඟ ප්‍රගතියක් ලබා ගත නොහැක.

ඔබ විසින් ලබා ගත හැකි නම්, LOCK TABLESසහ UNLOCK TABLESඑම dumpfile පිටතට අදහස් ...

  • වගුව MyISAM නම්, SELECT COUNT (*) ක්‍රියා කරයි
  • වගුව InnoDB නම්, ගණන් කිරීම සිදු වන තුරු COUNT (*) තෝරන්න.

එය සාර්ථක විය. ස්තූතියි. එක් අවසාන ප්‍රශ්නයක් නම්, අත්දැකීම් අනුව, ආනයන කාලය දළ වශයෙන් සහ ගොනු ප්‍රමාණයන්ට සාපේක්ෂව රේඛීයදැයි ඔබ දන්නවාද ? .MYD.MYI
qazwsx

1
වගු රීලෝඩ් රේඛීය වේ. දර්ශක නැවත ගොඩනැඟීම රේඛීය වේ. වසර ගණනාවකට පෙර, එය මම MySQL (ප්රශ්නයක් ලෙස මෙම නාමයක් අත්පත් ලෙස නොවේ lists.mysql.com/mysql/202489 ) සහ මම කරමින් තමයි StackExchange (එය සඳහන් dba.stackexchange.com/a/2697/877 )
RolandoMySQLDBA

10

සෑම තත්පර 2 කට වරක් ඔබ ක්‍රියාවලි ක්‍රියාත්මක වන ආකාරය දකිනු ඇත.

watch 'echo "show processlist;" | mysql -uuser -ppassword';

ඔබට එය අඩු වාර ගණනක් අවශ්‍ය නම් x යනු තත්පර ගණන -n xකොතැනදැයි එක් කරන්න . තත්පර 5 ක් වනුයේ:

watch -n 5 'echo "show processlist;" | mysql -uuser -ppassword';

ඔබට නිදර්ශන ප්‍රතිදානයක් පළ කළ හැකිද? එසේම, එය ක්‍රියාවලිය පමණක් පෙන්වනවාද? නැතහොත් එය ඇත්ත වශයෙන්ම මා ඉල්ලා සිටි ආනයනයේ ප්‍රගතිය පෙන්නුම් කරයිද?
qazwsx

මෙය එතරම් ප්‍රයෝජනවත් කේතයකි. හිහ් හිහ්
නාරායන්

SQL ලිපිගොනු උඩුගත කිරීමෙන් පසුව විමසීම් යථා
තත්වයට පත්

එය% හි ප්‍රගතිය නොපෙන්වා තිබුණද එය සැබවින්ම ක්‍රියාත්මක වන අතර එය හිර වී නැති බව පෙන්නුම් කරයි.
ඩේවිඩ්

7

ඔබට එය ඇණ හිට ඇත්දැයි පරීක්ෂා කිරීමට අවශ්‍ය නම් ඔබට විමසිය හැකිය

show processlist; 

ක්‍රියාත්මක කරන්නේ කුමක්දැයි බලන්න.


5

පීවී වැඩ කිරීමට නොහැකි හෝ පීවී බොරු කියන කෙනෙකුට විසඳුමක් ලෙස. දත්ත අඩංගු ibdata1 ගොනුවේ ප්‍රමාණය / var / lib / mysql හි ඔබට නිරීක්ෂණය කළ හැකිය. මෙය ඔබගේ ප්‍රභව සේවාදායකයේ ගොනු ප්‍රමාණයට සමාන ප්‍රමාණයකින් (හෝ එතැනින්) අවසන් වේ.

බොහෝ වගු තිබේ නම් ඒවා / var / lib / mysql / <database name> එකින් එක දිස්වන ආකාරය ඔබට බලා ගත හැකිය.

වසර තුන හතරක කාලයක් තුළ දීර් G කාලීන දත්ත ගබඩාවක් 20G පමණ ලොග් ගොනුවක් ගොඩනගා ඇති විට මම මෙම කාරණය භාවිතා කළෙමි. මාරුවීම වයස්ගත වන බව මම දුටුවෙමි.

දත්ත සමුදායක් කොතැනක හෝ වෙනත් ගොනුවකට සම්බන්ධ නොවන දවස උදාවනු ඇතැයි සිතිය නොහැකිය. මේ අතර, මාරුවීමක් සිදුවන්නේ කෙසේදැයි බැලීමට ඔබට ගොනුව නිරීක්ෂණය කළ හැකිය. මා යෝජනා කළ ක්‍රමය පළමු වර්ග දත්ත ගබඩාව ලියා ඇති දා සිට ඔබට එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් කළ හැකි දෙයකි. අත්පොත ජෝකියෙකුට නැවත වැටිය හැකි ඕනෑම ආකාරයක “නිල” තාක්‍ෂණයක් යැයි මම කිසි විටෙකත් යෝජනා කිරීමට අදහස් නොකළෙමි. එය පොදුවේ පරිගණක හා සාමාන්‍යයෙන් යුනික්ස් සමඟ ප්‍රවීණතා මට්ටමක් උපකල්පනය කරයි.


2

ඔබේ ඩීබී වෙනත් ආකාරයකින් නිශ්ශබ්ද නම් (එනම් වෙනත් පරිශීලකයින් සක්‍රීයව නොමැත) සහ ඔබට කියවීමේ / ලිවීමේ ක්‍රියාකාරකම් දැකීමට අවශ්‍ය නම් ඇයි එවැනි දෙයක් නොකරන්නේ:

mysqladmin -h<host>-uroot -p<yourpass> extended -r -i 10 |grep 'row'

ඔබට කියවීම් / ලිවීම් / ඇතුළත් කිරීම් / රැඳී සිටීම් / යාවත්කාලීන කිරීම් ගණනක් පෙනෙනු ඇත.

ඔබ උදාහරණයක් ලෙස ඇතුළත් කරන්නේ නම් ඔබට එවැනි දෙයක් පෙනෙනු ඇත:

Innodb_rows_inserted                          | 28958 

28958 යනු ඔබේ කාල පරතරය සඳහා ඇතුළත් කර ඇති පේළි ගණනයි (මගේ නඩුවේ තත්පර 10).


1

ඔබ භාවිතා කරමින් නල නරඹන්නාගේ උදාහරණය සොයන අයෙකුට mysqldumpමේ වගේ දෙයක් කරයි:

mysqldump -hxxx -uxxx -p dbname | pv -W > dump.sql

මෙම -Wධජය පමණක් (රේඛාවේදී පසු) ප්රගතිය දැක්වෙන පෙර එන්න පළමු බයිට සඳහා බලා සිටීමට PV කියයි



0

හරි, තවත් වැඩක්. නමුත් එය නරකම හා සාවද්‍ය විකල්පය විය හැකිය.

වින්ඩෝස් සඳහා මගේ විසඳුම මෙන්න:

කාර්ය කළමනාකරු එබීමෙන් විවෘත කරන්න

CTRL + SHIFT + ESC

"Mysqld.exe" තැටියේ අගය වේගය පිටපත් කරන්න

e.g. 11mb/s

මේ වගේ කැල්කියුලේටරයකට දමන්න: https://techinternets.com/copy_calc?do

ETA තක්සේරු කරන්න. මගේ නඩුව වූයේ:

Speed: 8 MB/s
Size: 4.9 GB
0 Hours, 11 Minutes and 29 Seconds

ප්රතිපල:

Beg -> 11:19
ETA -> 11:31
End -> 11:39

0

ඔබට gnu coreutils / dd version> = 8.24 (නිකුත් කරන ලද්දේ 2015 ජූලි 03) නම් ඔබට dd's status = ප්‍රගති තර්කය භාවිතා කළ හැකිය.

උදා

cat dbdump.gz | gzip -d | mysql --password=root -v | time dd of=/dev/null status=progress

* PS: කාර්යබහුල පෙට්ටිය සමඟ ක්‍රියා නොකරයි, කාර්යබහුල කොටුව dd "status = progress" තේරුම් නොගනී



0

ආනයනය කිරීමට මට 500 MB SQL ගොනුවක් තිබුණි. මට පැය 2 ක් පමණ ගත විය. ආනයන ක්‍රියාවලිය ආරම්භයේදී mysqld CPU භාවිතය 100% ට ආසන්න විය. නමුත් මිනිත්තු කිහිපයකට පසු CPU භාවිතය 15% දක්වා අඩු විය.

මම බොහෝ වෙනස් කිරීම් අත්හදා බැලුවද මෙය මට පමණක් උපකාරී විය: innodb_flush_log_at_trx_commit = 0

මෙම සිටුවම ක්‍රියාත්මක කර mysql නැවත ආරම්භ කිරීමෙන් පසු ආනයනය මිනිත්තු 3 ක් ගතවිය! CPU භාවිතය සෑම විටම 100% ක් විය.

ඔබ මෙම සැකසුම භාවිතා කිරීමට කැමති නම්, ඔබට "/etc/mysql/my.cnf" ගොනුව සංස්කරණය කර "sudo service mysql restart" භාවිතා කර mysql සේවාදායකය නැවත ආරම්භ කළ යුතුය.

මෙන්න මගේ "my.conf" ගොනුවේ සැකසුම්:

    [mysqld]
    innodb_log_buffer_size = 256M
    innodb_fast_shutdown = 0
    innodb-doublewrite = OFF
    innodb_io_capacity = 1000
    innodb_flush_log_at_trx_commit = 0

කරුණාකර සටහන් කරන්න: "innodb_flush_log_at_trx_commit = 0" කැපවීමක් කරන්නේ සෑම තත්පරයකටම පමණි. එබැවින් එය ACID අනුකූලතාවයක් නොව තොග ආනයනය පිළිගත හැකි ය. ආයාත කිරීමෙන් පසු ඔබට "innodb_flush_log_at_trx_commit" හි අගය 1 ට නැවත සකසා ඔබගේ දත්ත සමුදාය නැවත ආරම්භ කළ හැකිය. MySQL ප්‍රලේඛනයට සබැඳිය


-1

මට පුදුමයි කිසිවෙකු විකල්පයක් ලෙස 'mysql -v' පළ නොකළේය. එය හිර වී ඇත්නම්, ප්‍රතිදානය නතර වනු ඇත.


3
“ප්‍රගතිය අධීක්ෂණය කිරීම” යනු සාමාන්‍යයෙන් ක්‍රියාවලිය කොතරම් දුරට ප්‍රගතියක් ලබා ඇත්ද යන්න හෝ එය සම්පූර්ණ වන්නේ කවදාද යන්න තක්සේරු කිරීමට උත්සාහ mysql -vකිරීමකි. එසේම, ගිගාබයිට් 7 ක දත්ත පර්යන්තයට මුදා හැරීම සැලකිය යුතු ලෙස යථා තත්ත්වයට පත් කරයි.
mustaccio

මට පේනවා, පැහැදිලි කිරීමට ස්තූතියි. ඇත්ත වශයෙන්ම, 7 GB ප්‍රතිදානය පර්යන්තයට ප්‍රතිදානය කිරීම හොඳ නැත. මම හිතන්නේ -v භාවිතා කිරීම මගේ ඩීබී හිර වී ඇති කුඩා දේශීය පරීක්ෂණ නඩුවක් සඳහා පමණක් විය.
dtc

2
විශාල ගොනුවක් සමඟ භාවිතා කිරීම කොතරම් ප්‍රායෝගික වුවත්, මෙම යෝජනාව මට ගැටලුවක් හඳුනා ගැනීමට උපකාරී විය. (පතල කුඩා විය).
කේසි පර්කින්ස්
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.