it-swarm.asia

Mengapa DROP DATABASE begitu lama? (MySQL)

Instalasi CentOS baru.

Saya menjalankan impor DB besar (file 2GB sql) dan punya masalah. Klien SSH tampaknya kehilangan koneksi dan impor tampaknya membeku. Saya menggunakan jendela lain untuk login ke mysql dan impor tampaknya sudah mati, terjebak pada tabel baris 3M tertentu.

Jadi saya mencoba

DROP DATABASE huge_db;

15-20 menit kemudian, tidak ada apa-apa. Di jendela lain, saya melakukannya:

/etc/init.d/mysqld restart

Jendela DROP DB mengirim pesan: SERVER SHUTDOWN. Kemudian saya benar-benar me-restart server fisik.

Masuk kembali ke mysql, diperiksa dan db masih di sana, berlari

DROP DATABASE huge_db;

lagi, dan lagi saya sudah menunggu sekitar 5 menit.

Sekali lagi, ini instalasi baru. huge_db adalah satu-satunya db (selain sistem dbs). Aku bersumpah aku sudah menjatuhkan db sebesar ini sebelumnya dan dengan cepat, tapi mungkin aku salah.

Saya berhasil menjatuhkan basis data. Butuh sekitar 30 menit. Perhatikan juga bahwa saya pikir saya salah ketika saya pikir impor mysqldump sudah mati. Koneksi terminal terputus, tapi saya pikir prosesnya masih berjalan. Saya kemungkinan besar membunuh impor mid-table (tabel baris 3M) dan mungkin 3/4 dari keseluruhan db. Itu menyesatkan bahwa "atas" menunjukkan mysql menggunakan hanya 3% dari memori, ketika sepertinya itu harus menggunakan lebih banyak.

Menjatuhkan DB akhirnya memakan waktu 30 menit, jadi, sekali lagi, saya mungkin tidak perlu me-restart server dan mungkin bisa menunggu DROP selesai, tapi saya tidak tahu bagaimana reaksi mysql untuk mendapatkan permintaan DROP untuk db yang sama yang diimpor melalui mysqldump.

Namun, pertanyaannya tetap, mengapa butuh 30 menit + untuk MENGHAPUS database 2GB ketika semua yang harus dilakukan adalah menghapus semua file db dan menghapus semua referensi ke DB dari information_schema? Apa masalahnya?

49
Buttle Butkus

Daripada mematikan prosesnya, akan lebih aman jika Anda melakukannya di MySQL:

$ mysqladmin processlist -u root -p
Enter password: 
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| Id  | User | Host      | db                | Command | Time | State | Info             |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| 174 | root | localhost | example           | Sleep   | 297  |       |                  |
| 407 | root | localhost |                   | Query   | 0    |       | show processlist |
+-----+------+-----------+-------------------+---------+------+-------+------------------+

Permintaan dengan id 174 adalah penghapusan satu pemblokiran dari database 'contoh', jadi sebelum Anda membunuh proses apa pun terlebih dahulu, biarkan MySQL mencoba untuk menghentikan permintaan:

$ mysqladmin kill 174

Jalankan perintah processlist di atas lagi untuk mengonfirmasi bahwa itu sudah dimatikan.

Jika ini tidak berhasil, maka Anda mungkin bisa melihat cara membunuh proses yang salah, tetapi sebelum itu Anda bisa mencoba me-restart server MySQL.

Anda juga dapat menjalankan perintah seperti 'SHOW FULL PROCESSLIST' dan 'KILL 174' di MySQL Shell, misalnya jika Anda hanya menginstal klien MySQL. Poin utama adalah untuk menghindari membunuh proses menggunakan 'bunuh' di Shell kecuali benar-benar diperlukan.

Secara umum Anda dapat menggunakan mysql atau mysqladmin. Anda seharusnya tidak perlu menjalankan perintah seperti ini sesering itu; setelah Anda mulai membunuh kueri secara teratur, ada sesuatu yang salah dan Anda akan lebih baik memperbaiki masalah itu (membunuh proses kueri hanya mengobati gejalanya).

80
Stefan Magnuson

Meskipun saya berpikir bahwa proses impor telah mati, itu mungkin masih berjalan.

DROP DATABASE perintah mungkin menunggu database selesai mengimpor sebelum dijalankan.

Jadi, bukannya DROP DATABASE memakan waktu lama, mungkin itu hanya impor.

Jika ada orang lain yang membaca ini dan mencoba untuk membatalkan impor database dan drop database, saya sarankan Anda pertama kali menemukan PID (id proses) untuk impor dan menjalankan ini dari terminal yang berbeda:

$ kill [PID]

... di mana [PID] akan menjadi PID aktual untuk proses tersebut.

Anda akan melihat impor berhenti segera jika terminal lain masih terhubung.

Anda juga bisa menjalankan SHOW PROCESSLIST di tab phpMyAdmin SQL. Tabel yang dihasilkan menunjukkan proses yang sedang berjalan, dan mengklik 'x' di sebelah baris yang ingin Anda bunuh harus melakukan trik.

Lalu lari

DROP DATABASE `database_name`;

Dan semuanya harus bersih.


Jawaban lain menyatakan bahwa mematikan proses di mysql lebih baik daripada melakukannya dari luar. Saya belum menguji jawaban itu, tetapi kedengarannya sangat masuk akal. Jadi saya telah menandainya sebagai "jawaban yang diterima" bukan yang ini.

11
Buttle Butkus

Cobalah untuk memotong tabel terbesar di database Anda sebelum Anda menjatuhkannya. Saya melihat perilaku yang sangat mirip ketika bekerja dengan arsip lalu lintas firewall MySQL dan ini sangat membantu.

3
Tim Brigham

Saya menghadapi masalah yang sama. Tapi kali ini saya memeriksa daftar proses show; katanya memeriksa izin untuk waktu yang lebih lama. Kemudian saya menemukan bahwa mysqld_safe berjalan sebagai root sedangkan izin level folder hanya untuk pengguna mysql. Oleh karena itu saya membunuh permintaan, tentu saja butuh waktu lama mengatakan itu dalam keadaan mati, tetapi saya menunggu untuk bereaksi kemudian membunuh permintaan dan mengubah izin tingkat folder untuk me-root juga dengan menambahkannya ke grup dan chmod ke 770. Kemudian saya mengeksekusi drop database yang sama bla; itu berhasil bagi saya dalam 2 detik untuk database 20GB.

3
Mannoj

Hal pertama yang terlintas dalam pikiran adalah status Checking Permissions...

Kapan Anda menerbitkan DROP DATABASE mydb; segala sesuatu di dalam/var/lib/mysql/mydb diperiksa untuk melihat apakah ada izin OS untuk hak menjatuhkan setiap file.

Beberapa orang merasa bahwa mengurangi jumlah pengguna mysql dapat membant

3
RolandoMySQLDBA