mysqldump-ით backup და აღდგენა: flag-ები, დიდი dump-ები, შეცდომები

რამდენიმე ათეულ გიგაბაიტამდე MySQL ბაზისთვის mysqldump სწორი backup ხელსაწყოა და ერთი ბრძანება ამას სწორად აკეთებს:

$ mysqldump -h db.example.net -P 30412 -u backup -p \    --single-transaction --routines --events --triggers \    --set-gtid-purged=OFF --no-tablespaces \    appdb | gzip > appdb-$(date +%F).sql.gz

--single-transaction ყოველი InnoDB ცხრილის თანმიმდევრულ snapshot-ს გაძლევს ისე, რომ აპლიკაციას არ ბლოკავს. --routines და --events ამატებს stored procedure-ებსა და დაგეგმილ event-ებს, რომლებიც ნაგულისხმევად გამოტოვებულია. --set-gtid-purged=OFF და --no-tablespaces აჩერებს იმ ორ შეცდომას, რომლებიც ჩვეულებრივი მომხმარებლის მიერ აღებულ dump-ებს ყველაზე ხშირად ამტვრევს. აღდგენა არის gunzip -c file.sql.gz | mysql appdb. ამ გზამკვლევის დანარჩენი ნაწილი თითოეულ flag-ს განმარტავს, აჩვენებს, როგორ გახადო დიდი dump-ები და იმპორტები სწრაფი, და როგორ წაიკითხო შეცდომები - რადგან dump backup მხოლოდ მაშინ ხდება, როცა მისგან ერთხელ აღადგენ.

აქ ყველაფერი MySQL 8.4 LTS-სა და მის mysqldump-ს ეხება. mysqlpump, 5.7-ში შემოტანილი პარალელური ხელსაწყო, 8.4-ში ამოღებულია; მის საქმეს ახლა MySQL Shell-ის dump utility-ები აკეთებს, რომლებიც ქვემოთაა განხილული.

რას აწარმოებს mysqldump#

mysqldump ლოგიკური backup-ია: ის მონაცემებს ჩვეულებრივი query-ებით კითხულობს და წერს SQL ბრძანებებს, რომლებიც მათ თავიდან აგებს - CREATE TABLE, შემდეგ მრავალხაზიანი INSERT-ები, შემდეგ index-ები და trigger-ები. შედეგი ტექსტური ფაილია, რომლის წაკითხვა, grep-ით ძებნა, რედაქტირება და ნებისმიერ თავსებად სერვერზე ჩატვირთვა შეგიძლია, მათ შორის უფრო ახალ ვერსიაზე ან სხვა ჰოსტზე.

გაცვლა სიჩქარეა. 10 GB მონაცემის dump სწრაფად იწერება, მაგრამ უკან ჩატვირთვა ნიშნავს ყოველი INSERT-ის შესრულებას და ყოველი index-ის თავიდან აგებას, რასაც შეიძლება dump-ზე რამდენჯერმე მეტი დრო დასჭირდეს. თუ ბაზა იმდენად დიდია, რომ აღდგენას საათები სჭირდება, ეს იმ დღემდე უნდა იცოდე, როცა დაგჭირდება.

Flag-ები, რომლებსაც მნიშვნელობა აქვს#

mysqldump ნაგულისხმევად --opt-ს რთავს, გონივრული ქცევის ნაკრებს: --add-drop-table, --add-locks, --create-options, --disable-keys, --extended-insert (ბევრი ხაზი ერთ INSERT-ში), --lock-tables, --quick (ხაზების ნაკადად გადაცემა მთელი ცხრილის ბუფერში ჩატვირთვის ნაცვლად) და --set-charset. შენ ამას ამატებ და ნულიდან არ აგებ.

რატომ --single-transaction და მისი ზღვრები

მის გარეშე --lock-tables თითოეული ბაზის ცხრილებს წასაკითხად ბლოკავს, სანამ მათი dump მიმდინარეობს, ასე რომ აპლიკაციას ამ დროის განმავლობაში ჩაწერა არ შეუძლია. --single-transaction-ით mysqldump თანმიმდევრული snapshot-ით ტრანზაქციას იწყებს და ყველაფერს დროის ამ მომენტიდან კითხულობს, მაშინ როცა აპლიკაცია ჩაწერას აგრძელებს. InnoDB-ზე, რაც ყველა შენი ცხრილი უნდა იყოს, ეს თანმიმდევრული და არაბლოკირებადია.

მას ორი ზღვარი აქვს, რომელიც ღირს იცოდე. ის მხოლოდ ტრანზაქციულ ცხრილებს ფარავს: MyISAM ცხრილი იმავე dump-ში იმ მომენტში იკითხება, როცა dump მას მიაღწევს. და ის სქემის ცვლილებებისგან არ იცავს - ALTER TABLE, RENAME TABLE, TRUNCATE ან DROP ცხრილზე dump-ის დროს შეიძლება ამ ცხრილის მონაცემები შედეგში დაკარგული ან არათანმიმდევრული აღმოჩნდეს. ნუ გაუშვებ migration-ებს, სანამ backup მიმდინარეობს, და ეს ორი ერთმანეთისგან დაშორებით დაგეგმე.

გრძელი dump ძველ snapshot-ს ღიად ინახავს, ამიტომ InnoDB-ს მისთვის ხაზების ძველი ვერსიების შენახვა უწევს. დატვირთულ ბაზაზე მრავალსაათიანი dump undo log-ს ზრდის და purge ჩამორჩება. ღამით ეს ჩვეულებრივ ასატანია; ეს არის მიზეზი, რომ დიდი, დატვირთული ბაზის dump ყოველ საათში არ გააკეთო.

Routine-ები, event-ები და trigger-ები

ნაგულისხმევი მნიშვნელობები არათანმიმდევრულია და ხალხს ხაფანგში აბამს: trigger-ები შედის, routine-ები და event-ები - არა. აპლიკაცია, რომელიც stored procedure-ს ეყრდნობა და --routines-ის გარეშე dump-იდან აღდგა, კვირების შემდეგ ვარდება „PROCEDURE appdb.close_month does not exist“-ით, როცა procedure პირველად გამოიძახება. ყოველ სრულ backup-ს -R -E დაუმატე.

ყოველ view-ს, routine-ს, trigger-სა და event-ს DEFINER პუნქტი აქვს. აღდგენა ისეთი მომხმარებლით, რომელიც definer არ არის და რომელსაც SET_ANY_DEFINER (8.4) ან SUPER (უფრო ძველში) არ აქვს, ვარდება. ამაზე მეტი ქვემოთ, შეცდომებში.

უფლებები, რომლებიც backup მომხმარებელს სჭირდება#

backup გააკეთე ცალკე ანგარიშით და არა root-ით. ერთი ბაზისთვის, რომლის dump-იც ამ პოსტის თავში მოცემული ბრძანებით კეთდება:

CREATE USER 'backup'@'%' IDENTIFIED BY RANDOM PASSWORD;GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, EVENT ON appdb.* TO 'backup'@'%';

SELECT ხაზებს კითხულობს. stored routine-ების dump-ს --routines-ით მეტი სჭირდება: ან გლობალური SELECT უფლება, ან SHOW_ROUTINE, 8.0.20-ში დამატებული დინამიკური უფლება, თუ backup ანგარიში თავად არ არის routine-ების definer - GRANT SHOW_ROUTINE ON *.* TO 'backup'@'%' ვიწრო ვარიანტია. SHOW VIEW view-ების განსაზღვრებებს ინახავს, TRIGGER - trigger-ებს, EVENT - event-ებს, ხოლო LOCK TABLES არატრანზაქციული ცხრილებისთვისაა საჭირო. --no-tablespaces-ის გარეშე dump-ს გლობალური PROCESS უფლება სჭირდება, ხოლო --source-data-ს - RELOAD და REPLICATION CLIENT. ასეთი ანგარიშების შექმნას MySQL-ის მომხმარებლები და უფლებები ფარავს.

Dump-ის აღდგენა#

# Into an existing, empty database$ mysql -h db.example.net -P 30412 -u app -p appdb < appdb-2026-10-08.sql# From a compressed file, with a progress bar (pv is optional)$ pv appdb-2026-10-08.sql.gz | gunzip | mysql -h db.example.net -P 30412 -u app -p appdb# A dump made with --databases names its own database; give mysql no database$ mysql -h db.example.net -P 30412 -u root -p < all-databases.sql

კლიენტის შიგნიდან SOURCE /path/to/appdb.sql იგივეს აკეთებს, თითო ბრძანების შედეგის ჩვენებით. Windows PowerShell-ში < გადამისამართება არ არსებობს; პატარა ფაილებისთვის გამოიყენე Get-Content dump.sql | mysql ..., ან, უკეთესი, mysql ... -e "source C:/backups/appdb.sql", რადგან PowerShell-ის pipeline-ს ტექსტის გადაკოდირება შეუძლია.

dump --add-drop-table-ის გარეშე პირველივე ცხრილზე ჩავარდება, რომელიც უკვე არსებობს, ხოლო მისით (ნაგულისხმევი) თითოეულ ცხრილს, რომელსაც შეიცავს, წაშლის და თავიდან შექმნის - და ხელუხლებლად დატოვებს ნებისმიერ ცხრილს, რომელსაც dump არ ახსენებს. ცოცხალი ბაზის „თავზე“ აღდგენა ამიტომ ნარევს გაძლევს: ცხრილებს dump-იდან, პლუს ნებისმიერ ცხრილს, რომელიც მას შემდეგ შეიქმნა. სუფთა აღდგენისთვის ჯერ ბაზა წაშალე და თავიდან შექმენი, ან აღადგინე ახალ ბაზაში და აპლიკაცია მასზე გადართე.

ერთი ცხრილის აღდგენა

რადგან dump ტექსტია, ერთი ცხრილის აღდგენა დანარჩენის ჩატვირთვის გარეშეც შეიძლება. ცხრილის ყოველი სექცია იწყება კომენტარით -- Table structure for table, რომელსაც მისი სახელი მოსდევს:

$ zcat appdb.sql.gz | sed -n '/^-- Table structure for table `orders`/,/^-- Table structure for table/p' \    > orders.sql

შედეგი ჩატვირთვამდე დაათვალიერე, იდეალურად საცდელ ბაზაში, და საჭირო ხაზები იქიდან დააკოპირე. ბაზისთვის, სადაც ერთი ცხრილის აღდგენა ხშირად ხდება, სანაცვლოდ თითოეული ცხრილის dump საკუთარ ფაილში გააკეთე.

დიდი dump-ები: შეკუმშვა, დრო და MySQL Shell#

mysqldump-ის ტექსტური ფაილი უკიდურესად კარგად იკუმშება, ხშირად თავისი ზომის მეათედამდე. gzip ყველგანაა; zstd მსგავსი თანაფარდობით უფრო სწრაფია, ხოლო zstd -T0 ყველა ბირთვს იყენებს:

$ mysqldump ... appdb | zstd -T0 -3 > appdb.sql.zst$ zstd -dc appdb.sql.zst | mysql ... appdb

pipe პირდაპირ კომპრესორში გაატარე, ნაცვლად იმისა, რომ ჯერ შეუკუმშავი ფაილი ჩაწერო, როგორც დისკის ადგილის გამო, ისე იმიტომ, რომ დისკზე ჩაწერა ხშირად ვიწრო ადგილია. ინტერნეტით dump-ისას --compression-algorithms=zstd კლიენტ-სერვერის პროტოკოლსაც კუმშავს, რაც ნელ კავშირზე გეხმარება.

mysqldump ორივე მიმართულებით ერთნაკადიანია. დაახლოებით 20-50 GB-ის მიღმა, ან როცა აღდგენა მოვლის ფანჯარაში უნდა ჩაეტიოს, MySQL Shell-ის dump utility-ები უკეთესი ხელსაწყოა. ისინი ცხრილებს პარალელურ ნაწილებად შეკუმშული ფაილების დირექტორიაში ინახავს და უკანაც პარალელურად ტვირთავს:

$ mysqlsh app@db.example.net:30412 -- util dump-schemas appdb \    --outputUrl=/backups/appdb-2026-10-08 --threads=4$ mysqlsh root@new-host:3306 -- util load-dump /backups/appdb-2026-10-08 --threads=4

util.loadDump სამიზნე სერვერზე local_infile=ON-ს მოითხოვს, რადგან მონაცემებს LOAD DATA LOCAL INFILE-ით ტვირთავს. მის შესაცვლელად გლობალური უფლებებია საჭირო, ამიტომ ჰოსტინგის სერვერზე შეამოწმე SELECT @@local_infile;-ით, სანამ მასზე დაიმედდები. Shell-ის dump-ები თავსებადობასაც ამოწმებს და შეუძლია definer-ების ამოშლა და სხვა პრობლემების გასწორება ისეთ სერვერზე გადატანისას, სადაც superuser არ ხარ - ocimds და compatibility ოფციები.

აღდგენის დაჩქარება#

dump ფაილი ყველაზე იაფ შემოწმებებს თავშივე თიშავს: session-ისთვის აყენებს UNIQUE_CHECKS=0 და FOREIGN_KEY_CHECKS=0, და თითოეული ცხრილის ხაზებს ALTER TABLE ... DISABLE KEYS-ში ახვევს (რაც მხოლოდ MyISAM-ზე მოქმედებს). რჩება ყოველი ხაზის commit-ისა და ლოგირების ფასი. თუ root ანგარიში გაქვს, სამი რამ გეხმარება:

-- Before the import, on the target serverSET GLOBAL innodb_flush_log_at_trx_commit = 2;   -- flush the redo log once a secondSET GLOBAL sync_binlog = 0;                      -- let the OS flush the binary log-- After the import, put them backSET GLOBAL innodb_flush_log_at_trx_commit = 1;SET GLOBAL sync_binlog = 1;

ორივე სანდოობას სიჩქარეზე ცვლის - იმპორტის დროს crash ბოლო წამს ან მასზე ოდნავ მეტს კარგავს - რაც კარგია აღდგენისთვის, რომლის თავიდან გაშვებაც შეგიძლია. innodb_buffer_pool_size-ისა და innodb_redo_log_capacity-ის დროებით აწევაც ეხმარება დიდ ჩატვირთვას; ორივე 8.x-ში დინამიკურია. პარამეტრი, რომელიც redo log-ს მთლიანად თიშავს, ALTER INSTANCE DISABLE INNODB REDO_LOG, ახალ ინსტანციაში ჩატვირთვას ბევრად აჩქარებს და მთელ ინსტანციას აღუდგენელს ტოვებს, თუ ის crash-ს განიცდის, სანამ ხელახლა ჩართავ. გამოიყენე მხოლოდ ახალ სერვერზე, რომლის თავიდან აგებაც შეგიძლია, და არასოდეს ისეთზე, რომელიც სხვა მონაცემებს ინახავს.

Dump-ების დაგეგმვა და ასლების შენახვა#

dump, რომელსაც არავინ აღადგენს, ჰიპოთეზაა. dump, რომელიც ბაზის იმავე დისკზე დევს, ჰიპოთეზაა ერთი წარუმატებლობის წერტილით. მომუშავე რუტინა პატარა ბაზისთვის:

#!/bin/bashset -euo pipefailSTAMP=$(date +%F-%H%M)DEST=/backups/mysqlmysqldump --login-path=backup --single-transaction -R -E --triggers \  --set-gtid-purged=OFF --no-tablespaces appdb | zstd -q -T0 > "$DEST/appdb-$STAMP.sql.zst"# keep 14 daysfind "$DEST" -name 'appdb-*.sql.zst' -mtime +14 -delete

--login-path მონაცემებს ~/.mylogin.cnf-იდან კითხულობს, რომელიც ერთხელ mysql_config_editor-ით იქმნება, ასე რომ პაროლი არც სკრიპტშია და არც პროცესების სიაში. set -euo pipefail სკრიპტს აჩერებს, თუ mysqldump ჩავარდა. pipefail ნაწილს მნიშვნელობა აქვს: მის გარეშე pipeline-ის გასვლის სტატუსი კომპრესორისაა, ასე რომ dump, რომელიც შუა გზაზე მოკვდა, მაინც აწარმოებს პატარა, ვალიდურად მოჩვენებით შეკუმშულ ფაილს, და ამას აღდგენისას გაიგებ. უახლესი ფაილის ზომა გუშინდელს შეადარე, როგორც იაფი განგაში, და ფაილები სხვაგან დააკოპირე: ბაზის dump-ები S3-ზე განრიგით ატვირთვისა და შენახვის მხარეს აჩვენებს.

RE:NODE-ზე MySQL გეგმებს დონის მიხედვით ერთიდან ოთხამდე backup სლოტი მოჰყვება. Backup-ები მოთხოვნით ან განრიგით ეშვება, ღილაკით აღდგება, შეიძლება ჩამოიტვირთოს, შეიძლება როტაციისგან დაიბლოკოს და ინახება იმ მანქანის გარეთ, რომელსაც იცავს. ლოგიკური dump მათ გვერდით მაინც ღირს: ეს ფორმატია, რომელსაც სხვა სერვერზე, უფრო ახალ ვერსიაზე ან debug-ისთვის ლოკალურ ასლში ჩატვირთავ, და ის არის, საიდანაც ერთი ცხრილის აღდგენა შეგიძლია. ბაზის backup-ები და აღდგენა მიდგომებს სხვადასხვა ძრავაზე ადარებს.

დროის კონკრეტულ მომენტზე აღდგენა binary log-ით#

ღამის dump ნიშნავს, რომ 17:00-ზე დაშვებული შეცდომა წინა ღამიდან მოყოლებული ყველაფერი დაგიჯდება. binary log ამ ხარვეზს ხურავს: ის dump-ის შემდეგ ყოველ ცვლილებას ინიშნავს, ხოლო mysqlbinlog-ს შეუძლია მათი თავიდან გათამაშება შეცდომამდე წინა მომენტამდე. ამას სამი რამ სჭირდება - ჩართული binary logging (MySQL 8-ში ნაგულისხმევი), --source-data=2-ით აღებული dump, რომ მან ჩაინიშნოს log ფაილი და პოზიცია, რომელსაც შეესაბამება, და binary log ფაილები, რომლებიც სულ მცირე dump-ებს შორის შუალედის ხანგრძლივობით ინახება.

# The dump's header names its starting point$ zgrep -m1 'CHANGE REPLICATION SOURCE TO' appdb.sql.gz-- CHANGE REPLICATION SOURCE TO SOURCE_LOG_FILE='binlog.000042', SOURCE_LOG_POS=157;# Restore the dump, then replay changes up to just before the bad statement$ mysqlbinlog --start-position=157 --stop-datetime="2026-10-08 16:59:00" \    binlog.000042 binlog.000043 | mysql -u root -p

პრაქტიკაში ამას სჭირდება root ანგარიში, RELOAD და REPLICATION CLIENT dump-ისთვის, და წვდომა binary log ფაილებზე, რომელსაც ჰოსტინგის სერვერი შეიძლება მოგცეს ან არ მოგცეს. თუ არ გაძლევს, რეალისტური ალტერნატივაა იმ ცხრილების უფრო ხშირი dump, რომლებიც ყველაზე მეტად იცვლება. ორივე შემთხვევაში გაარკვიე, რომელი გაქვს, ინციდენტამდე და არა მის დროს.

შეცდომები და რა უნდა გააკეთო თითოეულზე#

mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s)for this operation' when trying to dump tablespaces

8.0.21-დან tablespace-ის ინფორმაციის dump-ს გლობალური PROCESS სჭირდება. დაამატე --no-tablespaces; აპლიკაციის dump-ში tablespace-ის ბრძანებები თითქმის დანამდვილებით არ გჭირდება.

ERROR 1227 (42000) at line 18: Access denied; you need (at least one of) the SUPER,SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN privilege(s) for this operation

აღდგენისას, ჩვეულებრივ, SET @@GLOBAL.GTID_PURGED ან SET @@SESSION.SQL_LOG_BIN= 0 ხაზები, რომლებსაც GTID-ჩართული სერვერის dump შეიცავს. dump თავიდან გააკეთე --set-gtid-purged=OFF-ით, ან ეს ხაზები ფაილის თავიდან წაშალე.

ERROR 1449 (HY000): The user specified as a definer ('root'@'localhost') does not exist

dump შეიცავს view-ებს ან routine-ებს, რომელთა definer ახალ სერვერზე არ არის, ან აღადგენ ისეთი მომხმარებლით, რომელსაც ამ definer-ის მინიჭება არ შეუძლია. definer-ები ჩატვირთვამდე ამოშალე:

$ zcat appdb.sql.gz | sed -E 's/DEFINER=`[^`]+`@`[^`]+`//g' | mysql ... appdb

mysqldump: Couldn't execute 'SELECT COLUMN_NAME, JSON_EXTRACT(HISTOGRAM, ...)':Unknown table 'COLUMN_STATISTICS' in information_schema (1109)

8.x mysqldump, რომელიც უფრო ძველ ან არა-Oracle სერვერს ესაუბრება, სადაც COLUMN_STATISTICS ცხრილი არ არის. დაამატე --column-statistics=0.

ERROR 2006 (HY000) at line 4127: MySQL server has gone awayERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes

dump-ში ერთი INSERT იმაზე დიდია, ვიდრე სერვერი იღებს. სერვერზე max_allowed_packet ასწიე (8.x-ში ნაგულისხმევად 64 MB, 1 GB-მდე) და mysql-ს გადაეცი --max-allowed-packet=512M, ან dump თავიდან გააკეთე დაწეული --net-buffer-length-ით, რომ extended insert-ები უფრო პატარა იყოს.

ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci'

MySQL 8-ის dump, ჩატვირთული MySQL 5.7-ში ან სხვა ოჯახის სერვერში, რომელსაც 8.0-ის ნაგულისხმევი collation არ აქვს. ფაილში ის utf8mb4_unicode_ci-ით ჩაანაცვლე, ან, უკეთესი, აღადგინე MySQL 8-ში. იხილე utf8mb4 და collation-ები.

FAQ#

ბლოკავს mysqldump ბაზას?

--single-transaction-ითა და InnoDB ცხრილებით - არა: წაკითხვა და ჩაწერა მთელი დროის განმავლობაში გრძელდება, ხოლო dump თანმიმდევრულ snapshot-ს ხედავს. მის გარეშე ნაგულისხმევი --lock-tables თითოეულ ბაზაში ჩაწერას ბლოკავს, სანამ მისი dump მიმდინარეობს. dump-ის დროს სქემის ცვლილებებს ორივე შემთხვევაში შეუძლია თანმიმდევრულობის დარღვევა.

რამდენ ხანს გრძელდება mysqldump ფაილის აღდგენა?

dump-ზე მეტხანს, ხშირად სამიდან ხუთჯერ, რადგან ყოველი index ხაზ-ხაზ უნდა აიგოს თავიდან. გაზომე ერთხელ რეალური ფაილით საცდელ სერვერზე. თუ პასუხი იმაზე გრძელია, რამდენ ხანსაც შეიძლება გათიშული იყო, გადადი MySQL Shell-ის პარალელურ dump-სა და ჩატვირთვაზე, ან ფიზიკურ backup-ებზე.

შემიძლია MySQL 8.0-ის dump-ის აღდგენა MySQL 8.4-ში?

კი. ლოგიკური dump-ები იმავე ან უფრო ახალ ვერსიებში თითქმის ყოველთვის უპრობლემოდ იტვირთება. უკან წასვლა - 8.4-ის dump 8.0-ში, ან ნებისმიერი 8.x-ის dump 5.7-ში - შეიძლება ჩავარდეს collation-ებსა და სინტაქსზე, რომლებიც ძველმა სერვერმა არ იცის.

phpMyAdmin-ის export იგივეა, რაც mysqldump?

პატარა ბაზებისთვის საკმარისად ახლოს: phpMyAdmin-ის SQL export მსგავს ბრძანებებს აწარმოებს. თუმცა ის ვებ მოთხოვნის შიგნით მუშაობს, ამიტომ დიდი export-ები PHP-ის დროისა და მეხსიერების ლიმიტებს აწყდება, და მის ოფციებში routine-ებისა და event-ების დავიწყება ადვილია. მის პარამეტრებს phpMyAdmin-ის import და export ფარავს.

როგორ გავაკეთო სერვერის ყველა ბაზის backup?

mysqldump --all-databases შეიცავს mysql სისტემურ სქემას, რაც 8.x სერვერებს შორის ანგარიშების გადასატანად კარგი გზა არ არის. აპლიკაციის ბაზების dump გააკეთე --databases db1 db2-ით, ხოლო მომხმარებლები ცალკე დააკოპირე SHOW CREATE USER-ითა და SHOW GRANTS-ით. სრული პროცედურა MySQL-ის ახალ ჰოსტზე გადატანაშია.