Apakah punca dan penyelesaian biasa untuk ranap pangkalan data MySQL

Semak masa permulaan pangkalan data MySQL

Systemd dan mysqld_safe dalam sistem Linux akan memulakan semula perkhidmatan MySQL secara automatik selepas proses mysqld ranap bahawa Jika anda menggunakan kill -9 untuk mematikan proses mysqld, sistem akan dimulakan semula secara automatik, tetapi jika anda hanya menggunakan perintah kill, ia tidak akan dimulakan semula Kerana apabila anda melaksanakan perintah kill, sistem akan menghantar isyarat SIGTERM ke mysqld , dan pangkalan data mysql akan ditutup seperti biasa, dan ia akan muncul dalam log yang serupa dengan yang berikut:

2020-10-26T09:06:48.435181Z 0 [System] [MY-. 010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.19 ) MySQL Community Server - GPL.

Pangkalan data MySQL akan dimulakan semula selepas ranap sistem, jadi kadangkala kita mungkin tidak tahu bahawa pangkalan data MySQL telah ranap, tetapi kita boleh mencari petunjuk daripada masa permulaan pangkalan data mysql, seperti berikut Memperkenalkan empat kaedah untuk menyemak masa permulaan pangkalan data MySQL.

Menyemak status perkhidmatan MySQL

scutech@scutech:~$ service mysql status
● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-10-21 05:54:18 NDT; 4 days ago
  Process: 774 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid (code=exited, status=0/SUCCESS)
  Process: 708 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 791 (mysqld)
    Tasks: 27 (limit: 2328)
   CGroup: /system.slice/mysql.service
           └─791 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid

menunjukkan bahawa pangkalan data MySQL telah berjalan selama lebih 4 hari.

Semak status masa aktif dalam MySQL

mysql> show global status like 'uptime';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Uptime        | 428334 |
+---------------+--------+
1 row in set (0.32 sec)

Nilai ini dalam saat Penukaran berikut kepada hari adalah lebih daripada 4 hari.

mysql> select 428334/60/60/24;
+-----------------+
| 428334/60/60/24 |
+-----------------+
|  4.957569444444 |
+-----------------+
1 row in set (0.01 sec)

Cara lain untuk menanyakan status masa aktif ialah menggunakan versi mysqladmin atau menggunakan "s" dalam klien mysql untuk membuat pertanyaan.

Gunakan ps untuk menyemak masa permulaan proses

Gunakan arahan ps untuk membuat pertanyaan dan mendapati mysqld telah dimulakan selama 4 hari, 23 jam, 3 minit dan 54 saat

scutech@scutech:~$ ps -eo pid,user,args,etime|grep mysqld
  791 mysql    /usr/sbin/mysqld --daemoniz  4-23:03:54

Semak log MySQL

Cari kata kunci "sedia untuk sambungan" untuk mencari maklumat permulaan.

2020-10-21T08:24:18.986765Z 0 [Nota] /usr/sbin/mysqld: sedia untuk sambungan.
Versi: '5.7.28-log' soket: '/ var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)

Sebab biasa untuk ranap pangkalan data MySQL

Terdapat dua sebab yang paling biasa untuk ranap pangkalan data MySQL , satu adalah pepijat dalam mysql, dan satu lagi adalah kegagalan mysql untuk memohon sumber sistem atau kebocoran memori.

Pepijat MySQL

Salah satu sebab paling biasa untuk ranap pangkalan data MySQL sudah tentu pepijat MySQL. 95% pepijat adalah berkaitan dengan sql tertentu Biasanya terdapat masalah dengan sql terakhir yang dilaksanakan sebelum MySQL ranap Oleh itu, apabila mencari pepijat, anda harus membuka log pertanyaan umum dan mencari petunjuk berdasarkan sql terakhir.
Selepas anda menentukan punca ranap sistem, anda harus menyemak perpustakaan pepijat MySQL (https://bugs.mysql.com), biasanya menggunakan carian Terperinci, untuk melihat sama ada terdapat sebarang masalah yang serupa. Jika anda menemui pepijat yang mungkin berkaitan dengan anda, sahkan bahawa ia telah dibetulkan. Jika ia telah diperbaiki, kemudian naik taraf MySQL kepada versi yang pepijat telah diperbaiki.

Terdapat bahagian Pepijat Dibetulkan dalam Nota Keluaran bagi setiap versi, di mana anda boleh menyemak pepijat tetap.

MySQL gagal memohon sumber sistem atau kebocoran memori

Memori yang tidak mencukupi atau MySQL gagal memohon sumber sistem akan menyebabkan MySQL ranap, seperti ruang cakera penuh, fail pada cakera rosak, dsb. Pada masa ini, terdapat beberapa kaedah untuk mencari punca ranap sistem:

• Baca log ralat MySQL dengan teliti Sesetengah maklumat penyahpepijatan program dalam log ini mungkin kelihatan mengelirukan, tetapi ia adalah senyap. Jika anda melihat dengan teliti, anda akan sering menemui petunjuk; bina semula jika terdapat sebarang masalah Ini biasanya menyelesaikan masalah.

• Gunakan strace, pstack, pmap, gdb untuk menganalisis kod mysqld, anda mungkin perlu membuka core dump; = 1 Kompil semula mysqld, kemudian jalankan mysqld yang dikompilasi semula, semak fail surih dan log ralat untuk penyelesaian masalah.

• Pengiraan penggunaan memori MySQL

Memori global
• saiz innodb_buffer_pool_size innodb_log_buffer_size thread_cache_size table_open_cache table_definition_cache key che_size thread_st ack

  operasi tunggal Memori

  join_buffer_size read_buffer_size read_rnd_buffer_size tmp_table_size sort_buffer_size

Formula pengiraan

Formula pengiraan nilai rujukan penggunaan memori maksimum dalam MySQL 8:

rreee

rreee
<🎜 🎜>
saiz_penimbalan_kunci

sambungan_maks*(saiz_penampan_isih+saiz_penimbal_baca+saiz_cache_binlog)

sambungan_maks*2MB

• Sebagai penyelesaian sementara, anda boleh menggunakan arahan berikut untuk melepaskan cache:

  SELECT ( @@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@key_buffer_size 
  + @@max_connections * (@@binlog_cache_size + @@thread_stack + @@read_buffer_size 
  + @@read_rnd_buffer_size + @@sort_buffer_size + @@join_buffer_size + @@tmp_table_size ) 
  ) / 1024 /1024 AS MAX_MEM_MB;

  0: 0 ialah nilai lalai sistem, yang bermaksud bahawa memori tidak dikeluarkan secara lalai dan diuruskan secara automatik oleh operasi sistem 1: Lepaskan cache halaman
• 2 : Lepaskan dentri dan inod

  3: Lepaskan semua cache

  Dalam jangka masa panjang, masih perlu mengubah suai parameter yang sepadan untuk menyelesaikan masalah.
• Kebocoran memori klien MySQL
  Kebocoran memori klien MySQL biasanya mempunyai gesaan berikut

mysql: Kehabisan memori pada baris 42, 'malloc.c'
mysql: diperlukan 8136 bait (8k), memori yang digunakan: 12481367 bait (12189k)
RALAT 2008: Pelanggan MySQL dijalankan kehabisan ingatan

Ini biasanya disebabkan oleh set hasil pulangan yang diterima oleh klien terlalu besar Terdapat dua penyelesaian:

Semak SQL yang sedang berjalan untuk melihat sama ada anda benar-benar Melakukannya anda memerlukan set hasil pulangan yang begitu besar?
Tambah pilihan --quick apabila mysql dibenarkan, yang akan mengurangkan set pulangan yang diterima oleh klien dalam satu masa, tetapi akan meningkatkan beban mysqld.

Atas ialah kandungan terperinci Apakah punca dan penyelesaian biasa untuk ranap pangkalan data MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!