MySQL untuk IU Sitehosting menggunakan fitur MySQL Enterprise Backup dengan jadwal setiap malam. Cadangan ini disimpan selama 14 hari untuk tujuan pemulihan bencana di seluruh layanan
MySQL restoration policy
If you need to back up or restore your data for any purpose (development, transference from production to test, etc. ), you should take advantage of the functionality and tools that MySQL Workbench offers (for example, mysqldump or Data Export and Import Wizard)
The Database Administration team will perform MySQL data restoration in extremely limited cases, such as data loss due to SQL injection or unforeseen corruption. Data restoration services are performed on a case-by-case basis and are subject to review and approval by administrators. In all cases, data restoration is limited to the previous night's updates. Binary logs are not active, and it is not possible to provide point-in-time recovery. Data restoration may take up to 48 business hours to process
To request data restoration, email Tier 2 Support. Include the date and time the incident requiring data recovery occurred and the type of incident that spurred your request. You may be asked to provide information about what steps you have taken to mitigate the need for future data restoration. Staff will forward your request to the Database Administration team, who will contact you with options or further questions they may have
Departments and owners of sites who require 24x7 data backup and restoration services are encouraged to contact the Database Administration team to discuss options, which may include creating an Enterprise MySQL instance for just that site's content and on-call data recovery services. A fee may be associated with these services
Manually back up your MySQL for IU Sitehosting schemas
Create a backup using MySQL Workbench
Note
Store this backup file in a manner consistent with the data classification appropriate to your site's content. Sites which store sensitive internal or critical data must be stored in secure locations
If you're using versions of Workbench before 6. 3. 8, including on IUanyWare, you will have an unhandled exception when trying to export on the new system. You will be unable to export until you update Workbench
- Connect to your MySQL database
- Click Server on the main tool bar.
- Select Data Export .
- Select the tables you want to back up
- Under Export Options , select where you want your dump saved. By default, it will save to your Documents folder in a subfolder titled dumps.
- Click Start Export .
Note
You may get a message about a mismatch between your mysqldump.exe version and the MySQL Server version. You can update your local MySQL version or continue
It is important to back up your databases so that you can recover your data and be up and running again in case problems occur, such as system crashes, hardware failures, or users deleting data by mistake. Backups are also essential as a safeguard before upgrading a MySQL installation, and they can be used to transfer a MySQL installation to another system or to set up replication slave servers
MySQL offers a variety of backup strategies from which you can choose the methods that best suit the requirements for your installation. This chapter discusses several backup and recovery topics with which you should be familiar
Types of backups. Logical versus physical, full versus incremental, and so forth
Methods for creating backups
Recovery methods, including point-in-time recovery
Backup scheduling, compression, and encryption
Table maintenance, to enable recovery of corrupt tables
Additional Resources
Resources related to backup or to maintaining data availability include the following
Customers of MySQL Enterprise Edition can use the MySQL Enterprise Backup product for backups. For an overview of the MySQL Enterprise Backup product, see
A forum dedicated to backup issues is available at http. //forum. mysql. com/list. php?28
Details for can be found in Chapter 5, MySQL Programs
The syntax of the SQL statements described here is given in Chapter 14, SQL Statement Syntax
For additional information about shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 backup procedures, see
Replication enables you to maintain identical data on multiple servers. This has several benefits, such as enabling client query load to be distributed over servers, availability of data even if a given server is taken offline or fails, and the ability to make backups with no impact on the master by using a slave server. See Chapter 18, Replication
MySQL Cluster provides a high-availability, high-redundancy version of MySQL adapted for the distributed computing environment. See Chapter 21, MySQL NDB Cluster 7. 5, which provides information about MySQL NDB Cluster 7. 5 (based on MySQL 5. 7 but containing the latest improvements and fixes for the shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 2 storage engine)
Distributed Replicated Block Device (DRBD) is another high-availability solution. It works by replicating a block device from a primary server to a secondary server at the block level. See Chapter 17, High Availability and Scalability
8. 1 Backup and Recovery Types
This section describes the characteristics of different types of backups
Physical (Raw) Versus Logical Backups
Physical backups consist of raw copies of the directories and files that store database contents. This type of backup is suitable for large, important databases that need to be recovered quickly when problems occur
Logical backups save information represented as logical database structure (, statements) and content ( statements or delimited-text files). Jenis pencadangan ini cocok untuk jumlah data yang lebih kecil di mana Anda dapat mengedit nilai data atau struktur tabel, atau membuat ulang data pada arsitektur mesin yang berbeda
Metode pencadangan fisik memiliki karakteristik ini
Cadangan terdiri dari salinan persis dari direktori dan file database. Biasanya ini adalah salinan dari semua atau sebagian dari direktori data MySQL
Metode pencadangan fisik lebih cepat daripada logis karena hanya melibatkan penyalinan file tanpa konversi
Output lebih kompak daripada cadangan logis
Karena kecepatan dan kekompakan pencadangan penting untuk database yang sibuk dan penting, produk Pencadangan MySQL Enterprise melakukan pencadangan fisik. Untuk ikhtisar produk Pencadangan MySQL Enterprise, lihat
Perincian pencadangan dan pemulihan berkisar dari tingkat seluruh direktori data hingga tingkat file individual. Ini mungkin atau mungkin tidak menyediakan perincian tingkat tabel, tergantung pada mesin penyimpanan. Misalnya, shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 tabel masing-masing dapat berada dalam file terpisah, atau berbagi penyimpanan file dengan shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 tabel lainnya;
Selain database, cadangan dapat menyertakan file terkait seperti file log atau konfigurasi
Data dari tabel shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql _9 sulit untuk dicadangkan dengan cara ini karena kontennya tidak disimpan di disk. (Produk MySQL Enterprise Backup memiliki fitur di mana Anda dapat mengambil data dari tabel shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 9 selama pencadangan. )
Cadangan portabel hanya untuk mesin lain yang memiliki karakteristik perangkat keras yang identik atau serupa
Pencadangan dapat dilakukan saat server MySQL tidak berjalan. Jika server sedang berjalan, perlu dilakukan penguncian yang sesuai agar server tidak mengubah konten database selama pencadangan. MySQL Enterprise Backup melakukan penguncian ini secara otomatis untuk tabel yang memerlukannya
Alat pencadangan fisik termasuk mysqlbackup dari MySQL Enterprise Backup untuk shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 atau tabel lainnya, atau perintah tingkat sistem file (seperti cp, scp, tar, rsync) untuk shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 8 tabel
Untuk memulihkan
MySQL Enterprise Backup memulihkan shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql _1 dan tabel lain yang dicadangkan
mengembalikan shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql _2 tabel
File yang disalin pada tingkat sistem file dapat disalin kembali ke lokasi aslinya dengan perintah sistem file
Metode cadangan logis memiliki karakteristik ini
Pencadangan dilakukan dengan menanyakan server MySQL untuk mendapatkan struktur database dan informasi konten
Pencadangan lebih lambat daripada metode fisik karena server harus mengakses informasi basis data dan mengubahnya menjadi format logis. Jika keluaran ditulis di sisi klien, server juga harus mengirimkannya ke program cadangan
Keluaran lebih besar daripada cadangan fisik, terutama bila disimpan dalam format teks
Perincian pencadangan dan pemulihan tersedia di tingkat server (semua basis data), tingkat basis data (semua tabel dalam basis data tertentu), atau tingkat tabel. This is true regardless of storage engine
The backup does not include log or configuration files, or other database-related files that are not part of databases
Backups stored in logical format are machine independent and highly portable
Logical backups are performed with the MySQL server running. The server is not taken offline
Logical backup tools include the program and the statement. These work for any storage engine, even shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 9
To restore logical backups, SQL-format dump files can be processed using the client. To load delimited-text files, use the statement or the client
Online Versus Offline Backups
Online backups take place while the MySQL server is running so that the database information can be obtained from the server. Offline backups take place while the server is stopped. This distinction can also be described as “hot” versus “cold” backups; a “warm” backup is one where the server remains running but locked against modifying data while you access database files externally
Online backup methods have these characteristics
The backup is less intrusive to other clients, which can connect to the MySQL server during the backup and may be able to access data depending on what operations they need to perform
Care must be taken to impose appropriate locking so that data modifications do not take place that would compromise backup integrity. The MySQL Enterprise Backup product does such locking automatically
Offline backup methods have these characteristics
Clients can be affected adversely because the server is unavailable during backup. For that reason, such backups are often taken from a replication slave server that can be taken offline without harming availability
The backup procedure is simpler because there is no possibility of interference from client activity
A similar distinction between online and offline applies for recovery operations, and similar characteristics apply. However, it is more likely that clients will be affected for online recovery than for online backup because recovery requires stronger locking. During backup, clients might be able to read data while it is being backed up. Recovery modifies data and does not just read it, so clients must be prevented from accessing data while it is being restored
Local Versus Remote Backups
A local backup is performed on the same host where the MySQL server runs, whereas a remote backup is done from a different host. For some types of backups, the backup can be initiated from a remote host even if the output is written locally on the server. host
can connect to local or remote servers. For SQL output (shell> mysql < backup_sunday_1_PM.sql 8 and statements), local or remote dumps can be done and generate output on the client. For delimited-text output (with the option), data files are created on the server host
can be initiated from a local or remote client host, but the output file is created on the server host
Physical backup methods typically are initiated locally on the MySQL server host so that the server can be taken offline, although the destination for copied files might be remote
Snapshot Backups
Some file system implementations enable “snapshots” to be taken. These provide logical copies of the file system at a given point in time, without requiring a physical copy of the entire file system. (For example, the implementation may use copy-on-write techniques so that only parts of the file system modified after the snapshot time need be copied. ) MySQL itself does not provide the capability for taking file system snapshots. It is available through third-party solutions such as Veritas, LVM, or ZFS
Full Versus Incremental Backups
A full backup includes all data managed by a MySQL server at a given point in time. An incremental backup consists of the changes made to the data during a given time span (from one point in time to another). MySQL has different ways to perform full backups, such as those described earlier in this section. Incremental backups are made possible by enabling the server's binary log, which the server uses to record data changes
Full Versus Point-in-Time (Incremental) Recovery
A full recovery restores all data from a full backup. This restores the server instance to the state that it had when the backup was made. If that state is not sufficiently current, a full recovery can be followed by recovery of incremental backups made since the full backup, to bring the server to a more up-to-date state
Incremental recovery is recovery of changes made during a given time span. This is also called point-in-time recovery because it makes a server's state current up to a given time. Point-in-time recovery is based on the binary log and typically follows a full recovery from the backup files that restores the server to its state when the backup was made. Then the data changes written in the binary log files are applied as incremental recovery to redo data modifications and bring the server up to the desired point in time
Table Maintenance
Data integrity can be compromised if tables become corrupt. Untuk tabel shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1, ini bukan masalah biasa. For programs to check tables and repair them if problems are found, see
Backup Scheduling, Compression, and Encryption
Backup scheduling is valuable for automating backup procedures. Compression of backup output reduces space requirements, and encryption of the output provides better security against unauthorized access of backed-up data. MySQL itself does not provide these capabilities. The MySQL Enterprise Backup product can compress shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 backups, and compression or encryption of backup output can be achieved using file system utilities. Other third-party solutions may be available
8. 2 Database Backup Methods
Bagian ini merangkum beberapa metode umum untuk membuat cadangan
Membuat Hot Backup dengan MySQL Enterprise Backup
Pelanggan MySQL Enterprise Edition dapat menggunakan produk ini untuk melakukan pencadangan seluruh instans atau database, tabel, atau keduanya yang dipilih. Produk ini mencakup fitur untuk dan cadangan. Mencadangkan file basis data fisik membuat pemulihan jauh lebih cepat daripada teknik logis seperti perintah shell> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql 5. shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 tabel disalin menggunakan mekanisme. (Idealnya, tabel shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql _1 harus mewakili sebagian besar data. ) Tabel dari mesin penyimpanan lain disalin menggunakan mekanisme. Untuk ikhtisar produk Pencadangan MySQL Enterprise, lihat
Membuat Backup dengan mysqldump
Program ini dapat membuat cadangan. It can back up all kinds of tables. (Lihat. )
Untuk shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 tabel, dimungkinkan untuk melakukan pencadangan online yang tidak mengunci tabel menggunakan opsi untuk. Lihat
Membuat Cadangan dengan Menyalin File Tabel
Untuk mesin penyimpanan yang mewakili setiap tabel menggunakan filenya sendiri, tabel dapat dicadangkan dengan menyalin file tersebut. Misalnya, shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 8 tabel disimpan sebagai file, sehingga mudah untuk melakukan backup dengan menyalin file (shell> mysqlbinlog gbichot2-bin.000009 .. | mysql 1, shell> mysqlbinlog gbichot2-bin.000009 .. | mysql 2, dan shell> mysqlbinlog gbichot2-bin.000009 .. | mysql 3 file). Untuk mendapatkan cadangan yang konsisten, hentikan server atau kunci dan bersihkan tabel yang relevan
FLUSH TABLES tbl_list WITH READ LOCK;Anda hanya membutuhkan kunci baca; . Pembilasan diperlukan untuk memastikan bahwa semua halaman indeks aktif ditulis ke disk sebelum Anda memulai pencadangan. Lihat , dan
Anda juga dapat membuat cadangan biner hanya dengan menyalin semua file tabel, selama server tidak memperbarui apa pun. (Tapi perhatikan bahwa metode penyalinan file tabel tidak berfungsi jika database Anda berisi shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 tabel. Selain itu, meskipun server tidak memperbarui data secara aktif, shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 mungkin masih memiliki data yang dimodifikasi yang di-cache di memori dan tidak dibuang ke disk. )
Membuat Pencadangan File Teks-Dibatasi
Untuk membuat file teks yang berisi data tabel, Anda dapat menggunakan. File dibuat di host server MySQL, bukan host klien. Untuk pernyataan ini, file keluaran tidak boleh sudah ada karena mengizinkan file untuk ditimpa merupakan risiko keamanan. Lihat. Metode ini berfungsi untuk semua jenis file data, tetapi hanya menyimpan data tabel, bukan struktur tabel
Cara lain untuk membuat file data teks (bersama dengan file yang berisi pernyataan untuk tabel yang dicadangkan) adalah dengan menggunakan opsi. Lihat
Untuk memuat ulang file data teks terbatas, gunakan atau
Membuat Pencadangan Inkremental dengan Mengaktifkan Log Biner
MySQL mendukung pencadangan tambahan. Anda harus memulai server dengan opsi untuk mengaktifkan logging biner; . File log biner memberi Anda informasi yang Anda perlukan untuk mereplikasi perubahan ke database yang dibuat setelah Anda melakukan pencadangan. Pada saat Anda ingin membuat cadangan inkremental (berisi semua perubahan yang terjadi sejak cadangan penuh atau inkremental terakhir), Anda harus memutar log biner dengan menggunakan. Ini selesai, Anda perlu menyalin ke lokasi cadangan semua log biner yang berkisar dari salah satu saat cadangan penuh atau inkremental terakhir hingga yang terakhir kecuali satu. Log biner ini adalah cadangan inkremental; . Lain kali Anda melakukan pencadangan penuh, Anda juga harus memutar log biner menggunakan atau. Lihat
Membuat Cadangan Menggunakan Budak Replikasi
Jika Anda memiliki masalah kinerja dengan server master saat membuat cadangan, salah satu strategi yang dapat membantu adalah menyiapkan replikasi dan melakukan pencadangan pada budak, bukan pada master. Lihat
Jika Anda mencadangkan server replikasi budak, Anda harus mencadangkan info masternya dan menyimpan repositori info log (lihat ) saat Anda mencadangkan basis data budak, apa pun metode pencadangan yang Anda pilih. File informasi ini selalu diperlukan untuk melanjutkan replikasi setelah Anda memulihkan data budak. Jika budak Anda mereplikasi pernyataan, Anda juga harus mencadangkan file InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 05 apa pun yang ada di direktori yang digunakan budak untuk tujuan ini. Budak membutuhkan file-file ini untuk melanjutkan replikasi dari setiap operasi yang terputus. Lokasi direktori ini adalah nilai opsi. Jika server tidak dimulai dengan opsi tersebut, lokasi direktori adalah nilai dari variabel sistem
Memulihkan Tabel Rusak
Jika Anda harus memulihkan shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 8 tabel yang rusak, coba pulihkan menggunakan atau terlebih dahulu. Itu harus bekerja di 99. 9% dari semua kasus. Jika gagal, lihat
Membuat Cadangan Menggunakan Snapshot Sistem File
Jika Anda menggunakan sistem file Veritas, Anda dapat membuat cadangan seperti ini
Kemampuan snapshot serupa mungkin tersedia di sistem file lain, seperti LVM atau ZFS
8. 3 Contoh Strategi Pencadangan dan Pemulihan
Bagian ini membahas prosedur untuk melakukan pencadangan yang memungkinkan Anda memulihkan data setelah beberapa jenis kerusakan
Kecelakaan sistem operasi
Masalah listrik
Kerusakan sistem file
Masalah perangkat keras (hard drive, motherboard, dan sebagainya)
Perintah contoh tidak menyertakan opsi seperti dan untuk program klien dan. Anda harus menyertakan opsi seperti yang diperlukan untuk mengaktifkan program klien untuk terhubung ke server MySQL
Asumsikan bahwa data disimpan di mesin penyimpanan shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1, yang memiliki dukungan untuk transaksi dan pemulihan kerusakan otomatis. Asumsikan juga bahwa server MySQL sedang dimuat pada saat crash. Jika tidak, tidak ada pemulihan yang diperlukan
Untuk kasus crash sistem operasi atau kegagalan daya, kita dapat mengasumsikan bahwa data disk MySQL tersedia setelah restart. File data shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 mungkin tidak berisi data yang konsisten karena crash, tetapi shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 membaca lognya dan menemukan di dalamnya daftar transaksi commit dan noncommitted yang tertunda yang belum dipindahkan ke file data. shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 secara otomatis memutar kembali transaksi yang tidak dilakukan, dan memindahkan ke file datanya transaksi yang dilakukan. Informasi tentang proses pemulihan ini disampaikan kepada pengguna melalui log kesalahan MySQL. Berikut ini adalah contoh kutipan log
InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connectionsUntuk kasus crash sistem file atau masalah perangkat keras, kita dapat berasumsi bahwa data disk MySQL tidak tersedia setelah restart. Ini berarti MySQL gagal untuk memulai dengan sukses karena beberapa blok data disk tidak lagi dapat dibaca. Dalam hal ini, perlu memformat ulang disk, menginstal yang baru, atau memperbaiki masalah yang mendasarinya. Maka perlu untuk memulihkan data MySQL kami dari cadangan, yang berarti cadangan harus sudah dibuat. Untuk memastikan itu masalahnya, rancang dan terapkan kebijakan pencadangan
8. 3. 1 Menetapkan Kebijakan Pencadangan
Agar bermanfaat, pencadangan harus dijadwalkan secara teratur. Pencadangan penuh (snapshot data pada satu titik waktu) dapat dilakukan di MySQL dengan beberapa alat. Misalnya, dapat menjalankan seluruh instance, dengan pengoptimalan untuk meminimalkan overhead dan menghindari gangguan saat mencadangkan shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 file data; . Pembahasan ini menggunakan
Asumsikan bahwa kita membuat cadangan penuh dari semua tabel shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 kita di semua database menggunakan perintah berikut pada hari Minggu pukul 1 p. m. , ketika beban rendah
shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sqlFile InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections _19 yang dihasilkan oleh berisi sekumpulan pernyataan SQL yang dapat digunakan untuk memuat ulang tabel yang dibuang di lain waktu
Operasi pencadangan ini memperoleh kunci baca global di semua tabel di awal dump (menggunakan ). Segera setelah kunci ini diperoleh, koordinat log biner dibaca dan kunci dilepaskan. Jika pernyataan pemutakhiran yang lama berjalan saat pernyataan dikeluarkan, operasi pencadangan mungkin terhenti hingga pernyataan tersebut selesai. Setelah itu, dump menjadi bebas kunci dan tidak mengganggu proses baca dan tulis pada tabel
Diasumsikan sebelumnya bahwa tabel yang akan dicadangkan adalah shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 tabel, jadi gunakan pembacaan yang konsisten dan jaminan bahwa data yang dilihat tidak berubah. (Perubahan yang dibuat oleh klien lain ke shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 tabel tidak terlihat oleh proses. ) Jika operasi pencadangan menyertakan tabel nontransaksional, konsistensi mengharuskan mereka tidak berubah selama pencadangan. Misalnya, untuk tabel shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql _8 di database InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 27, tidak boleh ada perubahan administratif pada akun MySQL selama pencadangan
Pencadangan lengkap diperlukan, tetapi tidak selalu nyaman untuk membuatnya. Mereka menghasilkan file cadangan yang besar dan membutuhkan waktu untuk membuatnya. They are not optimal in the sense that each successive full backup includes all data, even that part that has not changed since the previous full backup. Lebih efisien untuk membuat cadangan penuh awal, dan kemudian membuat cadangan tambahan. Pencadangan inkremental lebih kecil dan membutuhkan waktu lebih sedikit untuk diproduksi. Imbalannya adalah, pada waktu pemulihan, Anda tidak dapat memulihkan data hanya dengan memuat ulang cadangan penuh. Anda juga harus memproses cadangan inkremental untuk memulihkan perubahan inkremental
Untuk membuat cadangan tambahan, kita perlu menyimpan perubahan tambahan. Di MySQL, perubahan ini direpresentasikan dalam log biner, sehingga server MySQL harus selalu dimulai dengan opsi untuk mengaktifkan log tersebut. Dengan pendataan biner diaktifkan, server menulis setiap perubahan data ke dalam file saat memperbarui data. Melihat direktori data server MySQL yang dimulai dengan opsi dan telah berjalan selama beberapa hari, kami menemukan file log biner MySQL ini
-rw-rw---- 1 guilhem guilhem 1277324 Nov 10 23:59 gbichot2-bin.000001 -rw-rw---- 1 guilhem guilhem 4 Nov 10 23:59 gbichot2-bin.000002 -rw-rw---- 1 guilhem guilhem 79 Nov 11 11:06 gbichot2-bin.000003 -rw-rw---- 1 guilhem guilhem 508 Nov 11 11:08 gbichot2-bin.000004 -rw-rw---- 1 guilhem guilhem 220047446 Nov 12 16:47 gbichot2-bin.000005 -rw-rw---- 1 guilhem guilhem 998412 Nov 14 10:08 gbichot2-bin.000006 -rw-rw---- 1 guilhem guilhem 361 Nov 14 10:07 gbichot2-bin.indexSetiap kali dimulai ulang, server MySQL membuat file log biner baru menggunakan nomor berikutnya dalam urutan. Saat server sedang berjalan, Anda juga dapat memintanya untuk menutup file log biner saat ini dan memulai yang baru secara manual dengan mengeluarkan pernyataan SQL atau dengan perintah. juga memiliki opsi untuk menyiram log. File InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections _31 di direktori data berisi daftar semua log biner MySQL di direktori
Log biner MySQL penting untuk pemulihan karena membentuk kumpulan cadangan inkremental. Jika Anda memastikan untuk mengosongkan log saat membuat cadangan lengkap, file log biner yang dibuat setelahnya berisi semua perubahan data yang dibuat sejak pencadangan. Mari kita ubah sedikit perintah sebelumnya sehingga menghapus log biner MySQL pada saat pencadangan penuh, dan agar file dump berisi nama log biner baru saat ini
shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases > backup_sunday_1_PM.sqlSetelah menjalankan perintah ini, direktori data berisi file log biner baru, InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 32, karena opsi tersebut menyebabkan server menghapus lognya. Opsi menyebabkan untuk menulis informasi log biner ke outputnya, sehingga file dump ________26______19 yang dihasilkan menyertakan baris-baris ini
-- Position to start replication or point-in-time recovery from -- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;Karena perintah membuat cadangan penuh, baris tersebut berarti dua hal
File dump berisi semua perubahan yang dibuat sebelum perubahan apa pun ditulis ke file log biner InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 32 atau lebih tinggi
Semua perubahan data yang dicatat setelah pencadangan tidak ada di file dump, tetapi ada di file log biner InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 32 atau lebih tinggi
Pada hari Senin pukul 1 siang. m. , kita dapat membuat cadangan inkremental dengan membilas log untuk memulai file log biner baru. Misalnya, menjalankan perintah akan menghasilkan ________26______38. Semua perubahan antara Minggu 1 hal. m. backup penuh dan Senin 1 hal. m. akan berada di file InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections _32. Pencadangan tambahan ini penting, jadi sebaiknya salin ke tempat yang aman. (Misalnya, cadangkan di kaset atau DVD, atau salin ke komputer lain. ) Pada hari Selasa pukul 1 siang. m. , jalankan perintah lain. Semua perubahan antara Senin 1 hal. m. dan Selasa 1 hal. m. akan berada di file InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections _38 (yang juga harus disalin di tempat yang aman)
Log biner MySQL menggunakan ruang disk. Untuk mengosongkan ruang, bersihkan dari waktu ke waktu. Salah satu cara untuk melakukannya adalah dengan menghapus log biner yang tidak diperlukan lagi, seperti saat kita membuat cadangan penuh
shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql8. 3. 2 Menggunakan Cadangan untuk Pemulihan
Sekarang, misalkan kita mengalami kecelakaan dahsyat pada hari Rabu pukul 8 pagi. m. yang membutuhkan pemulihan dari cadangan. Untuk memulihkan, pertama-tama kami memulihkan cadangan penuh terakhir yang kami miliki (yang dari Minggu 1 hal. m. ). File cadangan lengkap hanyalah sekumpulan pernyataan SQL, jadi memulihkannya sangat mudah
shell> mysql < backup_sunday_1_PM.sqlPada titik ini, data dipulihkan ke kondisinya pada Minggu 1 p. m. Untuk memulihkan perubahan yang dilakukan sejak saat itu, kita harus menggunakan cadangan inkremental; . Ambil file jika perlu dari tempat mereka dicadangkan, lalu proses kontennya seperti ini
shell> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysqlKami sekarang telah memulihkan data ke kondisinya pada hari Selasa pukul 1 siang. m. , tetapi masih belum ada perubahan dari tanggal tersebut hingga tanggal crash. Agar tidak hilang, kita harus meminta server MySQL menyimpan log biner MySQL-nya ke lokasi yang aman (disk RAID, SAN,. ) berbeda dari tempat menyimpan file datanya, sehingga log ini tidak ada di disk yang dihancurkan. (Artinya, kita dapat memulai server dengan opsi yang menentukan lokasi pada perangkat fisik yang berbeda dari tempat direktori data berada. Dengan begitu, log tetap aman meskipun perangkat yang berisi direktori hilang. ) Jika kami telah melakukan ini, kami akan memiliki file InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 44 (dan file berikutnya) di tangan, dan kami dapat menerapkannya menggunakan dan untuk memulihkan perubahan data terbaru tanpa kehilangan hingga saat crash
shell> mysqlbinlog gbichot2-bin.000009 .. | mysqlUntuk informasi lebih lanjut tentang penggunaan untuk memproses file log biner, lihat
8. 3. 3 Ringkasan Strategi Pencadangan
Jika sistem operasi crash atau listrik mati, shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 1 sendiri melakukan semua pekerjaan memulihkan data. Namun untuk memastikan Anda bisa tidur nyenyak, perhatikan panduan berikut ini
Selalu jalankan server MySQL dengan opsi, atau bahkan , di mana nama file log berada di beberapa media aman yang berbeda dari drive tempat direktori data berada. Jika Anda memiliki media yang aman, teknik ini juga bagus untuk penyeimbangan beban disk (yang menghasilkan peningkatan kinerja)
Buat pencadangan penuh secara berkala, menggunakan perintah yang ditunjukkan sebelumnya di , yang membuat pencadangan online tanpa pemblokiran
Buat cadangan inkremental berkala dengan membilas log dengan atau
8. 4 Menggunakan mysqldump untuk Pencadangan
Bagian ini menjelaskan cara menggunakan untuk menghasilkan file dump, dan cara memuat ulang file dump. File dump dapat digunakan dalam beberapa cara
Sebagai cadangan untuk mengaktifkan pemulihan data jika terjadi kehilangan data
Sebagai sumber data untuk menyiapkan budak replikasi
Sebagai sumber data untuk percobaan
Untuk membuat salinan database yang dapat Anda gunakan tanpa mengubah data aslinya
Untuk menguji potensi ketidakcocokan pemutakhiran
menghasilkan dua jenis output, tergantung pada apakah opsi diberikan
Tanpa , tulis pernyataan SQL ke keluaran standar. Output ini terdiri dari shell> mysql < backup_sunday_1_PM.sql 8 pernyataan untuk membuat objek yang dibuang (database, tabel, rutinitas tersimpan, dan sebagainya), dan pernyataan shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 5 untuk memuat data ke dalam tabel. Keluaran dapat disimpan dalam file dan dimuat ulang nanti menggunakan untuk membuat ulang objek yang dibuang. Opsi tersedia untuk memodifikasi format pernyataan SQL, dan untuk mengontrol objek mana yang dibuang
Dengan , menghasilkan dua file keluaran untuk setiap tabel yang dibuang. Server menulis satu file sebagai teks yang dibatasi tab, satu baris per baris tabel. This file is named ________20_______7.txt in the output directory. Server juga mengirimkan pernyataan untuk tabel ke , yang menuliskannya sebagai file bernama ________20_______7.sql di direktori keluaran
8. 4. 1 Membuang Data dalam Format SQL dengan mysqldump
Bagian ini menjelaskan cara menggunakan untuk membuat file dump format SQL. Untuk informasi tentang memuat ulang file dump tersebut, lihat
Secara default, menulis informasi sebagai pernyataan SQL ke keluaran standar. Anda dapat menyimpan output dalam file
InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 0Untuk membuang semua basis data, aktifkan dengan opsi
InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 1Untuk membuang hanya database tertentu, beri nama pada baris perintah dan gunakan opsi
InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 2Opsi tersebut menyebabkan semua nama pada baris perintah diperlakukan sebagai nama database. Tanpa opsi ini, perlakukan nama depan sebagai nama database dan nama berikutnya sebagai nama tabel
Dengan or , tulis dan pernyataan sebelum output dump untuk setiap database. Ini memastikan bahwa ketika file dump dimuat ulang, itu membuat setiap database jika tidak ada dan menjadikannya database default sehingga konten database dimuat ke dalam database yang sama dari mana mereka berasal. Jika Anda ingin memaksa file dump menjatuhkan setiap database sebelum membuatnya kembali, gunakan opsi ini juga. Dalam hal ini, tulis pernyataan sebelum setiap pernyataan
Untuk membuang satu database, beri nama pada baris perintah
InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 3Dalam kasus basis data tunggal, diperbolehkan untuk menghilangkan opsi
InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 4Perbedaan antara dua perintah sebelumnya adalah bahwa tanpa , keluaran dump tidak berisi pernyataan atau. Ini memiliki beberapa implikasi
Saat Anda memuat ulang file dump, Anda harus menentukan nama database default sehingga server mengetahui database mana yang akan dimuat ulang
Untuk memuat ulang, Anda dapat menentukan nama basis data yang berbeda dari nama aslinya, yang memungkinkan Anda memuat ulang data ke dalam basis data yang berbeda
Jika database yang akan dimuat ulang tidak ada, Anda harus membuatnya terlebih dahulu
Karena output tidak akan berisi pernyataan, opsi tidak berpengaruh. Jika Anda menggunakannya, itu tidak menghasilkan pernyataan
Untuk membuang hanya tabel tertentu dari database, beri nama pada baris perintah mengikuti nama database
InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 58. 4. 2 Memuat Ulang Cadangan Format SQL
Untuk memuat ulang file dump yang ditulis oleh yang terdiri dari pernyataan SQL, gunakan itu sebagai input ke klien. Jika file dump dibuat dengan opsi atau , itu berisi dan pernyataan dan tidak perlu menentukan database default untuk memuat data
InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 6Atau, dari dalam, gunakan perintah ________26______78
InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 7Jika file tersebut adalah dump database tunggal yang tidak berisi dan pernyataan, buat database terlebih dahulu (jika perlu)
InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 8Kemudian tentukan nama database saat Anda memuat file dump
InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 13674004 InnoDB: Doing recovery: scanned up to log sequence number 0 13739520 InnoDB: Doing recovery: scanned up to log sequence number 0 13805056 InnoDB: Doing recovery: scanned up to log sequence number 0 13870592 InnoDB: Doing recovery: scanned up to log sequence number 0 13936128 ... InnoDB: Doing recovery: scanned up to log sequence number 0 20555264 InnoDB: Doing recovery: scanned up to log sequence number 0 20620800 InnoDB: Doing recovery: scanned up to log sequence number 0 20664692 InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no 16745 InnoDB: Rolling back of trx no 16745 completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections _9Atau, dari dalam, buat database, pilih sebagai database default, dan muat file dump
shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql _0Untuk pengguna Windows PowerShell. Karena karakter "