Jenis cadangan apa yang disertakan selama proses pencadangan di mysql?

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

1. Connect to your MySQL database
2. Click Server on the main tool bar.
3. Select Data Export .
4. Select the tables you want to back up
5. Under Export Options , select where you want your dump saved. By default, it will save to your Documents folder in a subfolder titled dumps.
6. 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 connections
   

   Untuk 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.sql
   

   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
   

   _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.index
   

   Setiap 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.sql
   

   Setelah 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.sql
   

   8. 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.sql
   

   Pada 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 | mysql
   

   Kami 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 .. | mysql
   

   Untuk 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
   

   0

   Untuk 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
   

   1

   Untuk 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
   

   2

   Opsi 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
   

   3

   Dalam 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
   

   4

   Perbedaan 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
   

   5

   8. 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
   

   6

   Atau, 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
   

   7

   Jika 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
   

   8

   Kemudian 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
   

   _9

   Atau, dari dalam, buat database, pilih sebagai database default, dan muat file dump

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _0

   Untuk pengguna Windows PowerShell. Karena karakter "<" dicadangkan untuk penggunaan di masa mendatang di PowerShell, diperlukan pendekatan alternatif, seperti menggunakan tanda kutip

   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
   

   81

   8. 4. 3 Membuang Data dalam Format Teks-Terbatas dengan mysqldump

   Bagian ini menjelaskan cara menggunakan untuk membuat file dump delimited-text. Untuk informasi tentang memuat ulang file dump tersebut, lihat

   Jika Anda memanggil dengan opsi, ia menggunakan

   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
   

   83 sebagai direktori keluaran dan membuang tabel satu per satu di direktori itu menggunakan dua file untuk setiap tabel. Nama tabel adalah nama dasar untuk file-file ini. Untuk tabel bernama

   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
   

   84, file diberi nama

   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
   

   85 dan

   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
   

   86. 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
   

   _19 berisi pernyataan untuk tabel. 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
   

   _89 berisi data tabel, satu baris per baris tabel

   Perintah berikut membuang konten database ________26______90 ke file 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
   

   91

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _1

   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
   

   _89 yang berisi data tabel ditulis oleh server, sehingga dimiliki oleh akun sistem yang digunakan untuk menjalankan server. Server menggunakan untuk menulis file, jadi Anda harus memiliki hak istimewa untuk melakukan operasi ini, dan kesalahan akan terjadi jika file ________26______89 yang diberikan sudah ada

   Server mengirimkan definisi

   shell> mysql < backup_sunday_1_PM.sql
   

   8 untuk tabel yang dibuang ke , yang menulisnya ke 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
   

   19. Oleh karena itu, file-file ini dimiliki oleh pengguna yang mengeksekusi

   Yang terbaik adalah digunakan hanya untuk membuang server lokal. Jika Anda menggunakannya dengan server jarak jauh, direktori harus ada di host lokal dan jarak jauh, dan 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
   

   89 akan ditulis oleh server di direktori jarak jauh (di host server), sedangkan 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
   

   19 akan ditulis oleh

   Untuk , server secara default menulis data tabel ke

   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
   

   89 file satu baris per baris dengan tab di antara nilai kolom, tidak ada tanda kutip di sekitar nilai kolom, dan baris baru sebagai terminator baris. (Ini adalah default yang sama seperti untuk. )

   Untuk mengaktifkan file data yang akan ditulis menggunakan format yang berbeda, dukung opsi ini

   Bergantung pada nilai yang Anda tentukan untuk salah satu dari opsi ini, mungkin perlu pada baris perintah untuk mengutip atau keluar dari nilai secara tepat untuk juru bahasa perintah Anda. Atau, tentukan nilai menggunakan notasi hex. Misalkan Anda ingin mengutip nilai kolom dalam tanda kutip ganda. Untuk melakukannya, tentukan kutip ganda sebagai nilai opsi. Tetapi karakter ini seringkali khusus untuk juru perintah dan harus diperlakukan secara khusus. Misalnya, di Unix, Anda bisa mengutip kutipan ganda seperti ini

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _2

   Di platform apa pun, Anda dapat menentukan nilai dalam hex

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _3

   Adalah umum untuk menggunakan beberapa opsi pemformatan data secara bersamaan. Misalnya, untuk membuang tabel dalam format nilai yang dipisahkan koma dengan baris yang diakhiri oleh pasangan carriage-return/newline (

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   05), gunakan perintah ini (masukkan pada satu baris)

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _4

   Jika Anda menggunakan salah satu opsi pemformatan data untuk membuang data tabel, Anda perlu menentukan format yang sama saat Anda memuat ulang file data nanti, untuk memastikan interpretasi konten file yang tepat.

   8. 4. 4 Memuat Ulang Cadangan Format Teks Terpisah

   Untuk cadangan yang dihasilkan dengan , setiap tabel diwakili dalam direktori keluaran dengan 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
   

   19 yang berisi pernyataan untuk tabel, dan 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
   

   89 yang berisi data tabel. Untuk memuat ulang tabel, pertama-tama ubah lokasi menjadi direktori keluaran. Then process the

   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 file with to create an empty table and process the

   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
   

   89 file to load the data into the table

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _5

   Alternatif menggunakan untuk memuat file data adalah dengan menggunakan pernyataan dari dalam klien

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _6

   Jika Anda menggunakan opsi pemformatan data saat pertama kali membuang tabel, Anda harus menggunakan opsi yang sama dengan atau untuk memastikan interpretasi yang tepat dari konten file data

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _7

   Atau

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _8

   Bagian ini mensurvei teknik yang dapat Anda gunakan untuk memecahkan masalah tertentu

   • Cara membuat salinan database

   • Cara menyalin database dari satu server ke server lainnya

   • Cara membuang program tersimpan (prosedur dan fungsi tersimpan, pemicu, dan peristiwa)

   • Cara membuang definisi dan data secara terpisah

   8. 4. 5. 1 Membuat Salinan Database

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _9

   Jangan gunakan pada baris perintah karena menyebabkan

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   14 dimasukkan ke dalam file dump, yang mengesampingkan efek penamaan

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   15 pada baris perintah

   8. 4. 5. 2 Menyalin Database dari satu Server ke Server Lain

   Di Server 1

   -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.index
   

   _0

   Salin file dump dari Server 1 ke Server 2

   Di Server 2

   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
   

   6

   Penggunaan dengan baris perintah menyebabkan file dump disertakan dan pernyataan yang membuat database jika memang ada dan menjadikannya database default untuk data yang dimuat ulang

   Atau, Anda dapat menghilangkan dari perintah. Maka Anda perlu membuat database di Server 2 (jika perlu) dan menentukannya sebagai database default saat Anda memuat ulang file dump

   Di Server 1

   -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.index
   

   _2

   Di Server 2

   -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.index
   

   _3

   Anda dapat menentukan nama database yang berbeda dalam hal ini, sehingga menghilangkan dari perintah memungkinkan Anda membuang data dari satu database dan memuatnya ke yang lain

   8. 4. 5. 3 Membuang Program Tersimpan

   Beberapa opsi mengontrol cara menangani program tersimpan (prosedur dan fungsi tersimpan, pemicu, dan peristiwa)

   • Acara Penjadwal Acara Buang

   • Buang prosedur dan fungsi tersimpan

   • Pemicu pembuangan untuk tabel

   Opsi ini diaktifkan secara default sehingga saat tabel dibuang, tabel tersebut disertai dengan pemicu apa pun yang dimilikinya. Opsi lainnya dinonaktifkan secara default dan harus ditentukan secara eksplisit untuk membuang objek yang sesuai. Untuk menonaktifkan salah satu opsi ini secara eksplisit, gunakan formulir lewati. , , atau

   8. 4. 5. 4 Definisi dan Konten Tabel Pembuangan Secara Terpisah

   Opsi memberitahu untuk tidak membuang data tabel, menghasilkan file dump yang hanya berisi pernyataan untuk membuat tabel. Sebaliknya, opsi memberitahu untuk menekan

   shell> mysql < backup_sunday_1_PM.sql
   

   8 pernyataan dari output, sehingga file dump hanya berisi data tabel

   Misalnya, untuk membuang definisi tabel dan data secara terpisah untuk database

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   31, gunakan perintah 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.index
   

   _4

   Untuk dump definisi saja, tambahkan opsi dan untuk juga menyertakan definisi rutin dan peristiwa tersimpan

   -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.index
   

   _5

   8. 4. 5. 5 Menggunakan mysqldump untuk Menguji Inkompatibilitas Upgrade

   Saat mempertimbangkan peningkatan MySQL, sebaiknya instal versi yang lebih baru secara terpisah dari versi produksi Anda saat ini. Kemudian Anda dapat membuang database dan definisi objek database dari server produksi dan memuatnya ke server baru untuk memverifikasi bahwa mereka ditangani dengan benar. (Ini juga berguna untuk menguji penurunan versi. )

   Di server produksi

   -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.index
   

   _6

   Di server yang ditingkatkan

   -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.index
   

   _7

   Karena file dump tidak berisi data tabel, maka dapat diproses dengan cepat. Ini memungkinkan Anda menemukan potensi ketidaksesuaian tanpa menunggu operasi pemuatan data yang lama. Cari peringatan atau kesalahan saat file dump sedang diproses

   Setelah Anda memverifikasi bahwa definisi ditangani dengan benar, buang data dan coba muat ke server yang ditingkatkan

   Di server produksi

   -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.index
   

   _8

   Di server yang ditingkatkan

   -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.index
   

   _9

   Sekarang periksa isi tabel dan jalankan beberapa kueri pengujian

   8. 5 Pemulihan Point-in-Time (Inkremental) Menggunakan Log Biner

   Pemulihan point-in-time mengacu pada pemulihan perubahan data yang dibuat sejak titik waktu tertentu. Biasanya, jenis pemulihan ini dilakukan setelah memulihkan cadangan lengkap yang mengembalikan server ke kondisinya saat cadangan dibuat. (Pencadangan lengkap dapat dilakukan dengan beberapa cara, seperti yang tercantum di. ) Pemulihan point-in-time kemudian memperbarui server secara bertahap dari waktu pencadangan penuh ke waktu yang lebih baru

   Banyak contoh di sini menggunakan klien untuk memproses keluaran log biner yang dihasilkan oleh. Jika log biner Anda berisi

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   34 (null) karakter, output tersebut tidak dapat diuraikan kecuali Anda mengaktifkannya dengan opsi

   Pemulihan point-in-time didasarkan pada prinsip-prinsip ini

   • Sumber informasi untuk pemulihan point-in-time adalah kumpulan cadangan inkremental yang diwakili oleh file log biner yang dihasilkan setelah operasi pencadangan penuh. Oleh karena itu, server harus dimulai dengan opsi untuk mengaktifkan logging biner (lihat )

     Untuk memulihkan data dari log biner, Anda harus mengetahui nama dan lokasi file log biner saat ini. Secara default, server membuat file log biner di direktori data, tetapi nama jalur dapat ditentukan dengan opsi untuk menempatkan file di lokasi yang berbeda.

     Untuk melihat daftar semua file log biner, gunakan pernyataan ini

     shell> mysqldump --single-transaction --flush-logs --master-data=2 \
              --all-databases > backup_sunday_1_PM.sql
     

     0

     Untuk menentukan nama file log biner saat ini, keluarkan pernyataan berikut

     shell> mysqldump --single-transaction --flush-logs --master-data=2 \
              --all-databases > backup_sunday_1_PM.sql
     

     1

   • Utilitas mengubah peristiwa dalam file log biner dari format biner menjadi teks sehingga dapat dieksekusi atau dilihat. memiliki opsi untuk memilih bagian log biner berdasarkan waktu peristiwa atau posisi peristiwa dalam log. Lihat

   • Mengeksekusi peristiwa dari log biner menyebabkan modifikasi data yang diwakilinya dilakukan ulang. This enables recovery of data changes for a given span of time. Untuk mengeksekusi peristiwa dari log biner, proses keluaran menggunakan klien

     shell> mysqldump --single-transaction --flush-logs --master-data=2 \
              --all-databases > backup_sunday_1_PM.sql
     

     2

   • Melihat konten log dapat berguna saat Anda perlu menentukan waktu atau posisi peristiwa untuk memilih sebagian konten log sebelum menjalankan peristiwa. Untuk melihat peristiwa dari log, kirim output ke program paging

     shell> mysqldump --single-transaction --flush-logs --master-data=2 \
              --all-databases > backup_sunday_1_PM.sql
     

     3

     Alternatifnya, simpan output dalam file dan lihat file dalam editor teks

     shell> mysqldump --single-transaction --flush-logs --master-data=2 \
              --all-databases > backup_sunday_1_PM.sql
     

     4

   • Menyimpan keluaran dalam file berguna sebagai awal untuk mengeksekusi isi log dengan peristiwa tertentu yang dihapus, seperti yang tidak disengaja. Anda dapat menghapus dari file pernyataan apa pun yang tidak akan dieksekusi sebelum mengeksekusi isinya. Setelah mengedit file, jalankan isinya sebagai berikut

     shell> mysqldump --single-transaction --flush-logs --master-data=2 \
              --all-databases > backup_sunday_1_PM.sql
     

     5

   Jika Anda memiliki lebih dari satu log biner untuk dieksekusi di server MySQL, metode yang aman adalah memproses semuanya menggunakan satu koneksi ke server. Berikut adalah contoh yang menunjukkan apa yang mungkin tidak aman

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases > backup_sunday_1_PM.sql
   

   6

   Pemrosesan log biner dengan cara ini menggunakan koneksi berbeda ke server menyebabkan masalah jika file log pertama berisi pernyataan dan log kedua berisi pernyataan yang menggunakan tabel sementara. Saat proses pertama berakhir, server menghapus tabel sementara. Ketika proses kedua mencoba menggunakan tabel, server melaporkan “tabel tidak dikenal. ”

   Untuk menghindari masalah seperti ini, gunakan satu koneksi untuk mengeksekusi konten semua log biner yang ingin Anda proses. Inilah salah satu cara untuk melakukannya

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases > backup_sunday_1_PM.sql
   

   7

   Pendekatan lain adalah menulis semua log ke satu file dan kemudian memproses file tersebut

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases > backup_sunday_1_PM.sql
   

   8

   Saat menulis ke file dump sambil membaca kembali dari log biner yang berisi GTID (lihat ), gunakan opsi dengan , seperti ini

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases > backup_sunday_1_PM.sql
   

   _9

   8. 5. 1 Pemulihan Point-in-Time Menggunakan Waktu Acara

   Untuk menunjukkan waktu mulai dan berakhirnya pemulihan, tentukan opsi dan untuk , dalam format. Sebagai contoh, misalkan tepat pukul 10. 00 pagi. m. pada tanggal 20 April 2005 pernyataan SQL dieksekusi yang menghapus tabel besar. Untuk memulihkan tabel dan data, Anda dapat memulihkan cadangan malam sebelumnya, lalu menjalankan perintah berikut

   -- Position to start replication or point-in-time recovery from
   -- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;
   

   _0

   Perintah ini memulihkan semua data hingga tanggal dan waktu yang diberikan oleh opsi. Jika Anda tidak mendeteksi kesalahan pernyataan SQL yang dimasukkan hingga beberapa jam kemudian, Anda mungkin juga ingin memulihkan aktivitas yang terjadi setelahnya. Berdasarkan ini, Anda dapat menjalankan lagi dengan tanggal dan waktu mulai, seperti itu

   -- Position to start replication or point-in-time recovery from
   -- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;
   

   _1

   Dalam perintah ini, pernyataan SQL dicatat dari 10. 01 a. m. on akan dieksekusi kembali. Kombinasi memulihkan file dump malam sebelumnya dan dua perintah memulihkan semuanya hingga satu detik sebelum 10. 00 pagi. m. dan semuanya dari 10. 01 a. m. pada

   Untuk menggunakan metode pemulihan point-in-time ini, Anda harus memeriksa log untuk memastikan waktu yang tepat untuk menentukan perintah. Untuk menampilkan konten file log tanpa mengeksekusinya, gunakan perintah ini

   -- Position to start replication or point-in-time recovery from
   -- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;
   

   _2

   Kemudian buka file

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _45 dengan editor teks untuk memeriksanya

   Mengecualikan perubahan tertentu dengan menentukan waktu untuk tidak berfungsi dengan baik jika beberapa pernyataan dijalankan pada waktu yang sama dengan yang akan dikecualikan

   8. 5. 2 Pemulihan Point-in-Time Menggunakan Posisi Acara

   Alih-alih menentukan tanggal dan waktu, opsi dan untuk dapat digunakan untuk menentukan posisi log. Mereka bekerja sama dengan opsi tanggal mulai dan berhenti, kecuali bahwa Anda menentukan nomor posisi log daripada tanggal. Menggunakan posisi dapat memungkinkan Anda untuk lebih tepat tentang bagian mana dari log yang akan dipulihkan, terutama jika banyak transaksi terjadi pada waktu yang bersamaan dengan pernyataan SQL yang merusak. Untuk menentukan nomor posisi, jalankan beberapa kali mendekati waktu ketika transaksi yang tidak diinginkan dijalankan, tetapi alihkan hasilnya ke file teks untuk diperiksa. Ini bisa dilakukan seperti itu

   -- Position to start replication or point-in-time recovery from
   -- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;
   

   _3

   Perintah ini membuat file teks kecil di direktori

   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
   

   91 yang berisi pernyataan SQL sekitar waktu pernyataan SQL yang merusak dieksekusi. Buka file ini dengan editor teks dan cari pernyataan yang tidak ingin Anda ulangi. Tentukan posisi dalam log biner untuk menghentikan dan melanjutkan pemulihan dan catat. Posisi diberi label sebagai

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _49 diikuti dengan nomor. Setelah memulihkan file cadangan sebelumnya, gunakan nomor posisi untuk memproses file log biner. Misalnya, Anda akan menggunakan perintah seperti ini

   -- Position to start replication or point-in-time recovery from
   -- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;
   

   _4

   Perintah pertama memulihkan semua transaksi hingga posisi berhenti diberikan. Perintah kedua memulihkan semua transaksi dari posisi awal yang diberikan hingga akhir log biner. Karena output dari menyertakan

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _50 pernyataan sebelum setiap pernyataan SQL direkam, data yang dipulihkan dan log MySQL terkait akan mencerminkan waktu asli saat transaksi dieksekusi

   8. 6 Pemeliharaan Tabel MyISAM dan Pemulihan Kerusakan

   Bagian ini membahas cara menggunakan untuk memeriksa atau memperbaiki tabel

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases --delete-master-logs > backup_sunday_1_PM.sql
   

   8 (tabel yang memiliki file

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   52 dan

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   53 untuk menyimpan data dan indeks). Untuk latar belakang umum, lihat. Informasi perbaikan meja lainnya dapat ditemukan di

   Anda dapat menggunakan untuk memeriksa, memperbaiki, atau mengoptimalkan tabel database. Bagian berikut menjelaskan cara melakukan operasi ini dan cara menyiapkan jadwal pemeliharaan tabel. Untuk informasi tentang penggunaan untuk mendapatkan informasi tentang tabel Anda, lihat

   Even though table repair with is quite secure, it is always a good idea to make a backup before doing a repair or any maintenance operation that could make a lot of changes to a table

   operasi yang memengaruhi indeks dapat menyebabkan

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases --delete-master-logs > backup_sunday_1_PM.sql
   

   8

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   55 indeks dibangun kembali dengan parameter teks lengkap yang tidak kompatibel dengan nilai yang digunakan oleh server MySQL. Untuk menghindari masalah ini, ikuti panduan di

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases --delete-master-logs > backup_sunday_1_PM.sql
   

   8 pemeliharaan tabel juga dapat dilakukan dengan menggunakan pernyataan SQL yang melakukan operasi serupa dengan apa yang dapat dilakukan

   Untuk informasi tambahan tentang pernyataan ini, lihat

   Pernyataan ini dapat digunakan secara langsung atau melalui program klien. Satu keuntungan dari pernyataan ini adalah bahwa server melakukan semua pekerjaan. Dengan , Anda harus memastikan bahwa server tidak menggunakan tabel secara bersamaan sehingga tidak ada interaksi yang tidak diinginkan antara dan server

   8. 6. 1 Menggunakan myisamchk untuk Pemulihan Kerusakan

   Bagian ini menjelaskan cara memeriksa dan menangani korupsi data di database MySQL. Jika tabel Anda sering rusak, Anda harus mencoba menemukan alasannya. Lihat

   Untuk penjelasan tentang bagaimana tabel

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases --delete-master-logs > backup_sunday_1_PM.sql
   

   _8 dapat rusak, lihat

   Jika Anda menjalankan dengan penguncian eksternal dinonaktifkan (yang merupakan default), Anda tidak dapat menggunakan dengan andal untuk memeriksa tabel saat menggunakan tabel yang sama. Jika Anda dapat yakin bahwa tidak ada yang akan mengakses tabel saat Anda menjalankannya, Anda hanya perlu mengeksekusi sebelum mulai memeriksa tabel. Jika Anda tidak dapat menjamin ini, Anda harus berhenti saat memeriksa tabel. Jika Anda menjalankan untuk memeriksa tabel yang diperbarui pada saat yang sama, Anda mungkin mendapat peringatan bahwa tabel rusak meskipun sebenarnya tidak

   Jika server dijalankan dengan penguncian eksternal diaktifkan, Anda dapat menggunakannya untuk memeriksa tabel kapan saja. Dalam hal ini, jika server mencoba memperbarui tabel yang sedang digunakan, server akan menunggu hingga selesai sebelum melanjutkan

   Jika Anda menggunakan tabel untuk memperbaiki atau mengoptimalkan, Anda harus selalu memastikan bahwa server tidak menggunakan tabel (ini juga berlaku jika penguncian eksternal dinonaktifkan). Jika Anda tidak berhenti, Anda setidaknya harus melakukan a sebelum Anda berlari. Tabel Anda mungkin rusak jika server dan mengakses tabel secara bersamaan

   Saat melakukan pemulihan kerusakan, penting untuk dipahami bahwa setiap

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases --delete-master-logs > backup_sunday_1_PM.sql
   

   8 tabel

   shell> mysqlbinlog gbichot2-bin.000009 .. | mysql
   

   7 dalam database sesuai dengan tiga file dalam direktori database yang ditunjukkan pada tabel berikut

   FilePurpose________20_______7.frmDefinisi (format) file________20_______7.MYDData file________20_______7.MYIIndeks file

   Masing-masing dari ketiga jenis file ini dapat mengalami kerusakan dalam berbagai cara, tetapi masalah paling sering terjadi pada file data dan file indeks

   bekerja dengan membuat salinan file data

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   52 baris demi baris. Itu mengakhiri tahap perbaikan dengan menghapus file

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   52 lama dan mengganti nama file baru ke nama file asli. Jika Anda menggunakan , tidak membuat file

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   52 sementara, melainkan menganggap bahwa file

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   52 benar dan hanya menghasilkan file indeks baru tanpa menyentuh file

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   52. Ini aman, karena secara otomatis mendeteksi apakah file

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   52 rusak dan membatalkan perbaikan jika rusak. Anda juga dapat menentukan opsi dua kali. Dalam hal ini, tidak membatalkan beberapa kesalahan (seperti kesalahan kunci duplikat) melainkan mencoba menyelesaikannya dengan memodifikasi file

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   52. Biasanya penggunaan dua opsi hanya berguna jika Anda memiliki terlalu sedikit ruang disk kosong untuk melakukan perbaikan normal. Dalam hal ini, Anda setidaknya harus membuat cadangan tabel sebelum dijalankan

   8. 6. 2 Cara Memeriksa Kesalahan Tabel MyISAM

   Untuk memeriksa tabel

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases --delete-master-logs > backup_sunday_1_PM.sql
   

   _8, gunakan perintah berikut

   • Ini menemukan 99. 99% dari semua kesalahan. Apa yang tidak dapat ditemukan adalah korupsi yang hanya melibatkan file data (yang sangat tidak biasa). Jika Anda ingin memeriksa tabel, biasanya Anda harus menjalankan tanpa opsi atau dengan opsi ________35______75 (silent)

   • Ini menemukan 99. 999% dari semua kesalahan. Ini pertama-tama memeriksa semua entri indeks untuk kesalahan dan kemudian membaca semua baris. Itu menghitung checksum untuk semua nilai kunci di baris dan memverifikasi bahwa checksum cocok dengan checksum untuk kunci di pohon indeks

   • Ini melakukan pemeriksaan lengkap dan menyeluruh terhadap semua data (

     shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
     

     78 berarti "pemeriksaan diperpanjang"). Itu memeriksa setiap kunci untuk setiap baris untuk memverifikasi bahwa mereka memang menunjuk ke baris yang benar. Ini mungkin memakan waktu lama untuk tabel besar yang memiliki banyak indeks. Biasanya, berhenti setelah kesalahan pertama ditemukan. Jika Anda ingin mendapatkan informasi lebih lanjut, Anda dapat menambahkan opsi

     shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
     

     79 (verbose). Ini menyebabkan terus berjalan, hingga maksimal 20 kesalahan

   • Ini seperti perintah sebelumnya, tetapi opsi

     shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
     

     81 memberitahu untuk mencetak informasi statistik tambahan

   Dalam kebanyakan kasus, perintah sederhana tanpa argumen selain nama tabel sudah cukup untuk memeriksa tabel

   8. 6. 3 Cara Memperbaiki Tabel MyISAM

   Diskusi di bagian ini menjelaskan cara menggunakan pada

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases --delete-master-logs > backup_sunday_1_PM.sql
   

   8 tabel (ekstensi

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   53 dan

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   52)

   Anda juga dapat menggunakan pernyataan dan untuk memeriksa dan memperbaiki

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases --delete-master-logs > backup_sunday_1_PM.sql
   

   8 tabel. Lihat , dan

   Gejala tabel yang rusak mencakup kueri yang dibatalkan secara tidak terduga dan kesalahan yang dapat diamati seperti ini

   • _______ 206 _______ terkunci terhadap perubahan

   • Tidak dapat menemukan file ________20_______7.MYI (Errcode.

     shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
     

     _90)

   • Akhir file tak terduga

   • File rekaman rusak

   • Mendapat kesalahan

     shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
     

     _90 dari table handler

   Untuk mendapatkan informasi lebih lanjut tentang kesalahan, jalankan

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   90, di mana

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   90 adalah nomor kesalahan. Contoh berikut menunjukkan cara menggunakan untuk menemukan arti dari nomor kesalahan yang paling umum yang menunjukkan masalah dengan tabel

   -- Position to start replication or point-in-time recovery from
   -- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;
   

   _5

   Perhatikan bahwa kesalahan 135 (tidak ada lagi ruang di file rekaman) dan kesalahan 136 (tidak ada lagi ruang di file indeks) bukanlah kesalahan yang dapat diperbaiki dengan perbaikan sederhana. Dalam hal ini, Anda harus menggunakan untuk meningkatkan nilai opsi tabel

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   95 dan

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   96

   -- Position to start replication or point-in-time recovery from
   -- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;
   

   _6

   Jika Anda tidak mengetahui nilai opsi tabel saat ini, gunakan

   For the other errors, you must repair your tables. biasanya dapat mendeteksi dan memperbaiki sebagian besar masalah yang terjadi

   Proses perbaikan melibatkan hingga empat tahap, yang dijelaskan di sini. Sebelum memulai, Anda harus mengubah lokasi ke direktori database dan memeriksa izin file tabel. Di Unix, pastikan mereka dapat dibaca oleh pengguna yang berjalan sebagai (dan untuk Anda, karena Anda perlu mengakses file yang Anda periksa). Jika ternyata Anda perlu memodifikasi file, file tersebut juga harus dapat Anda tulis

   Bagian ini untuk kasus di mana pemeriksaan tabel gagal (seperti yang dijelaskan dalam ), atau Anda ingin menggunakan fitur tambahan yang menyediakan

   Opsi yang digunakan untuk pemeliharaan tabel dijelaskan dalam. juga memiliki variabel yang dapat Anda atur untuk mengontrol alokasi memori yang dapat meningkatkan performa. Lihat

   Jika Anda akan memperbaiki tabel dari baris perintah, Anda harus menghentikan server terlebih dahulu. Perhatikan bahwa ketika Anda melakukannya di server jarak jauh, server masih tersedia untuk beberapa saat setelah kembali, hingga semua pemrosesan pernyataan berhenti dan semua perubahan indeks telah dibilas ke disk

   Tahap 1. Memeriksa tabel Anda

   Jalankan atau jika Anda memiliki lebih banyak waktu. Gunakan opsi

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _75 (diam) untuk menekan informasi yang tidak perlu

   Jika server dihentikan, Anda harus menggunakan opsi kirim untuk menandai tabel sebagai “dicentang. ”

   Anda harus memperbaiki hanya tabel yang mengumumkan kesalahan. Untuk tabel seperti itu, lanjutkan ke Tahap 2

   Jika Anda mendapatkan kesalahan tak terduga saat memeriksa (seperti

   -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.index
   

   00 kesalahan), atau jika macet, lanjutkan ke Tahap 3

   Tahap 2. Perbaikan aman yang mudah

   Pertama, coba (

   -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.index
   

   02 berarti "mode pemulihan cepat"). Ini mencoba untuk memperbaiki file indeks tanpa menyentuh file data. Jika file data berisi semua yang seharusnya dan tautan hapus mengarah ke lokasi yang benar dalam file data, ini akan berfungsi, dan tabel diperbaiki. Mulailah memperbaiki meja berikutnya. Jika tidak, gunakan prosedur berikut

   1. Buat cadangan file data sebelum melanjutkan

   2. Gunakan (

      -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.index
      

      _04 berarti "mode pemulihan"). Ini menghapus baris yang salah dan menghapus baris dari file data dan merekonstruksi file indeks

   3. Jika langkah sebelumnya gagal, gunakan. Mode pemulihan aman menggunakan metode pemulihan lama yang menangani beberapa kasus yang tidak dapat dilakukan oleh mode pemulihan biasa (tetapi lebih lambat)

   Jika Anda ingin operasi perbaikan berjalan lebih cepat, Anda harus mengatur nilai dan variabel masing-masing sekitar 25% dari memori yang tersedia saat menjalankan

   Jika Anda mendapatkan kesalahan tak terduga saat memperbaiki (seperti

   -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.index
   

   00 kesalahan), atau jika macet, lanjutkan ke Tahap 3

   Tahap 3. Perbaikan yang sulit

   Anda harus mencapai tahap ini hanya jika blok 16KB pertama di file indeks dihancurkan atau berisi informasi yang salah, atau jika file indeks hilang. Dalam hal ini, Anda perlu membuat file indeks baru. Lakukan sebagai berikut

   1. Pindahkan file data ke tempat yang aman

   2. Gunakan file deskripsi tabel untuk membuat data baru (kosong) dan file indeks

      -- Position to start replication or point-in-time recovery from
      -- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;
      

      _7

   3. Salin file data lama kembali ke file data yang baru dibuat. (Jangan hanya memindahkan kembali file lama ke file baru. Anda ingin menyimpan salinannya jika terjadi kesalahan. )

   Jika Anda menggunakan replikasi, Anda harus menghentikannya sebelum melakukan prosedur di atas, karena melibatkan operasi sistem file, dan ini tidak dicatat oleh MySQL

   Kembali ke Tahap 2. harus bekerja. (Ini seharusnya tidak menjadi putaran tanpa akhir. )

   Anda juga dapat menggunakan pernyataan SQL REPAIR TABLE ________20_______7 USE_FRM_, yang melakukan seluruh prosedur secara otomatis. Juga tidak ada kemungkinan interaksi yang tidak diinginkan antara utilitas dan server, karena server melakukan semua pekerjaan saat Anda menggunakannya. Lihat

   Tahap 4. Perbaikan yang sangat sulit

   Anda harus mencapai tahap ini hanya jika file deskripsi

   -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.index
   

   11 juga macet. Itu tidak boleh terjadi, karena file deskripsi tidak diubah setelah tabel dibuat

   1. Pulihkan file deskripsi dari cadangan dan kembali ke Tahap 3. Anda juga dapat memulihkan file indeks dan kembali ke Tahap 2. Dalam kasus terakhir, Anda harus mulai dengan

   2. Jika Anda tidak memiliki cadangan tetapi tahu persis bagaimana tabel dibuat, buat salinan tabel di database lain. Hapus file data baru, lalu pindahkan deskripsi

      -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.index
      

      11 dan file indeks

      shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
      

      53 dari database lain ke database Anda yang rusak. Ini memberi Anda deskripsi baru dan file indeks, tetapi membiarkan file data

      shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
      

      52 saja. Go back to Stage 2 and attempt to reconstruct the index file

   8. 6. 4 Pengoptimalan Tabel MyISAM

   Untuk menyatukan baris yang terfragmentasi dan menghilangkan ruang terbuang akibat menghapus atau memperbarui baris, jalankan dalam mode pemulihan

   -- Position to start replication or point-in-time recovery from
   -- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;
   

   _8

   Anda dapat mengoptimalkan tabel dengan cara yang sama menggunakan pernyataan SQL. melakukan perbaikan tabel dan analisis kunci, dan juga mengurutkan pohon indeks sehingga pencarian kunci lebih cepat. Juga tidak ada kemungkinan interaksi yang tidak diinginkan antara utilitas dan server, karena server melakukan semua pekerjaan saat Anda menggunakannya. Lihat

   memiliki sejumlah opsi lain yang dapat Anda gunakan untuk meningkatkan performa tabel

   • atau

     -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.index
     

     _19. Lakukan analisis distribusi kunci. Ini meningkatkan kinerja gabungan dengan mengaktifkan pengoptimal gabungan untuk memilih urutan yang lebih baik untuk menggabungkan tabel dan indeks mana yang harus digunakan

   • atau

     -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.index
     

     _21. Sortir blok indeks. Ini mengoptimalkan pencarian dan membuat pemindaian tabel yang menggunakan indeks lebih cepat

   • atau

     -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.index
     

     _23. Urutkan baris data menurut indeks yang diberikan. Ini membuat data Anda jauh lebih terlokalisasi dan dapat mempercepat operasi berbasis rentang dan

     -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.index
     

     25 yang menggunakan indeks ini

   Untuk keterangan lengkap tentang semua opsi yang tersedia, lihat

   8. 6. 5 Menyiapkan Jadwal Pemeliharaan Tabel MyISAM

   Sebaiknya lakukan pemeriksaan tabel secara teratur daripada menunggu masalah terjadi. Salah satu cara untuk memeriksa dan memperbaiki tabel

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases --delete-master-logs > backup_sunday_1_PM.sql
   

   _8 adalah dengan pernyataan dan. Lihat

   Cara lain untuk memeriksa tabel adalah dengan menggunakan. Untuk tujuan pemeliharaan, Anda dapat menggunakan. Opsi

   shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql
   

   _75 (kependekan dari ) menyebabkan berjalan dalam mode senyap, mencetak pesan hanya ketika terjadi kesalahan

   Ini juga merupakan ide bagus untuk mengaktifkan pemeriksaan tabel ________0______8 otomatis. Misalnya, setiap kali mesin melakukan restart di tengah pembaruan, Anda biasanya perlu memeriksa setiap tabel yang mungkin terpengaruh sebelum digunakan lebih lanjut. (Ini adalah “tabel mogok yang diharapkan. ”) Untuk membuat server memeriksa

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases --delete-master-logs > backup_sunday_1_PM.sql
   

   8 tabel secara otomatis, mulailah dengan opsi. Lihat

   Anda juga harus memeriksa tabel Anda secara teratur selama pengoperasian sistem normal. Misalnya, Anda dapat menjalankan tugas cron untuk memeriksa tabel penting seminggu sekali, menggunakan baris seperti ini di file

   -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.index
   

   34

   -- Position to start replication or point-in-time recovery from
   -- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;
   

   _9

   Ini mencetak informasi tentang tabel yang mogok sehingga Anda dapat memeriksa dan memperbaikinya seperlunya

   Untuk memulainya, jalankan setiap malam pada semua tabel yang telah diperbarui selama 24 jam terakhir. Karena Anda melihat bahwa masalah jarang terjadi, Anda dapat memundurkan frekuensi pemeriksaan menjadi seminggu sekali atau lebih

   Biasanya, tabel MySQL membutuhkan sedikit perawatan. Jika Anda melakukan banyak pembaruan pada

   shell> mysqldump --single-transaction --flush-logs --master-data=2 \
            --all-databases --delete-master-logs > backup_sunday_1_PM.sql
   

   8 tabel dengan baris berukuran dinamis (tabel dengan , , atau kolom) atau memiliki tabel dengan banyak baris yang dihapus, Anda mungkin ingin mendefrag/mengklaim kembali ruang dari tabel dari waktu ke waktu. Anda dapat melakukan ini dengan menggunakan tabel yang dimaksud. Alternatively, if you can stop the server for a while, change location into the data directory and use this command while the server is stopped

   Apa saja jenis cadangan di MySQL?

   1. 1 Jenis Pencadangan dan Pemulihan .

   Physical (Raw) Versus Logical Backups. .

   Pencadangan Online Versus Offline. .

   Pencadangan Lokal Versus Jarak Jauh. .

   Snapshot Backups. .

   Pencadangan Penuh Versus Inkremental. .

   Pemulihan Penuh Versus Point-in-Time (Incremental). .

   Table Maintenance. .

   Backup Scheduling, Compression, and Encryption

   What are the 3 types of backups?

   Jenis cadangan yang paling umum adalah cadangan penuh, cadangan inkremental, dan cadangan diferensial . Jenis pencadangan lainnya termasuk pencadangan penuh sintetik dan pencerminan.

   Cadangan mana yang mencakup semua perubahan di MySQL?

   A differential backup includes all changes to the data since the last full backup. Ini lebih cepat daripada pencadangan penuh, menghemat ruang penyimpanan di server basis data, dan menghemat lalu lintas jaringan saat cadangan dipindahkan ke server lain.

   What type of backup is performed by Mysqldump?

   The mysqldump client utility performs logical backups , producing a set of SQL statements that can be executed to reproduce the original database object definitions and table data. It dumps one or more MySQL databases for backup or transfer to another SQL server.