|
Baru-baru ini, server MySQL ditemui karena beberapa faktor khusus“KESALAHAN 1129 (00000): Host 'xxx' diblokir karena banyak kesalahan koneksi. Buka blokir dengan 'mysqladmin flush-hosts'”Setelah masalah terpecahkan, dalam proses mempelajari lebih lanjut tentang parameter max_connect_errors, beberapa deskripsi yang kontradiktif dari data jaringan yang berbeda sedikit membingungkan saya (tentang kesalahan ini, alasan utamanya adalah bahwa IP yang sama menghasilkan terlalu banyak koneksi database yang terputus (melebihi nilai maksimum max_connect_errors) dalam waktu singkat, dan berikut ini adalah proses mengeksplorasi masalah saya, menganalisis masalah, dan mengklarifikasi keraguan. Pertama-tama, saya mencari beberapa informasi di Internet, banyak di antaranya bersumpah untuk memperkenalkan bahwa jika jumlah upaya input kata sandi melebihi variabel max_connect_errors, MySQL akan memblokir login klien ini, dan kemudian saya menemukan informasi resmi tentang pengenalan max_connect_errors, seperti yang ditunjukkan di bawah ini, MySQL 5.6/5.7 sama Jika lebih dari ini banyak permintaan koneksi berturut-turut dari host terganggu tanpa koneksi yang berhasil, server memblokir host tersebut dari koneksi lebih lanjut. Anda dapat membuka blokir host yang diblokir dengan membuang cache host. Untuk melakukannya, keluarkan pernyataan FLUSH HOSTS atau jalankan perintah mysqladmin flush-hosts. Jika koneksi berhasil dibuat dalam waktu kurang dari max_connect_errors upaya setelah koneksi sebelumnya terganggu, jumlah kesalahan untuk host dihapus menjadi nol. Namun, setelah host diblokir, membuang cache host adalah satu-satunya cara untuk membuka blokirnya. Defaultnya adalah 100. Seperti yang ditunjukkan di atas, terjemahannya kira-kira sebagai berikut: Jika server MySQL menerima permintaan berturut-turut dari host yang sama, dan semua permintaan berturut-turut ini terganggu tanpa berhasil membuat koneksi, ketika nilai kumulatif dari permintaan berturut-turut ini lebih besar dari nilai yang ditetapkan max_connect_errors, server MySQL akan memblokir semua permintaan berikutnya dari host ini. Saya percaya bahwa ketika Anda melihat informasi ini di awal, Anda juga akan diserang“Banyak permintaan koneksi berturut-turut dari host terganggu tanpa koneksi yang berhasil”Bingung, nyatanya hal ini karena koneksi database dibatalkan karena kelainan jaringan. Saya mencari informasi seperti itu di Internet: Tampaknya ada kebingungan seputar variabel itu. Itu tidak benar-benar memblokir host untuk kata sandi tidak valid berulang tetapi untuk koneksi yang dibatalkan karena kesalahan jaringan. Nah, kalau begitu kita bisa bereksperimen dan memverifikasinya sendiri untuk mengetahui mana yang benar. Buat akun pengujian di database MySQL, lalu kita atur variabel max_connect_errors ke3. Kemudian kami menggunakan mesin uji lain untuk terhubung ke database MySQL dengan kata sandi yang salah, seperti yang ditunjukkan di bawah ini, meskipun tiga kata sandi sebelumnya yang salah dimasukkan, input keempat tidak mengalami kesalahan di atas.Kemudian Anda dapat mengesampingkan bahwa variabel ini ada hubungannya dengan entri kata sandi yang salah. [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Masukkan kata sandi: KESALAHAN 1045 (28000): Akses ditolak untuk pengguna 'test'@'mytestlnx02' (menggunakan kata sandi: YA) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Masukkan kata sandi: KESALAHAN 1045 (28000): Akses ditolak untuk pengguna 'test'@'mytestlnx02' (menggunakan kata sandi: YA) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Masukkan kata sandi: KESALAHAN 1045 (28000): Akses ditolak untuk pengguna 'test'@'mytestlnx02' (menggunakan kata sandi: YA) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Masukkan kata sandi: KESALAHAN 1045 (28000): Akses ditolak untuk pengguna 'test'@'mytestlnx02' (menggunakan kata sandi: YA) [root@mytestlnx02 tmp] # Faktanya, jika IP memasukkan kata sandi yang salah, MySQL akan mencatatnya di tabel host_cache di bawah database performance_schema. Ini secara kumulatif dicatat dalam bidang COUNT_AUTHENTICATION_ERRORS sebagai berikut:
Menurut informasi resmi, bidang host_cache secara statistik dianggap sebagai“Penyumbatan”kesalahan koneksi (dinilai berdasarkan variabel sistem max_connect_errors). Hanya kesalahan jabat tangan protokol yang dihitung dan hanya digunakan untuk host yang diautentikasi (HOST_VALIDATED = YA). SUM_CONNECT_ERRORS Jumlah kesalahan koneksi yang dianggap "memblokir" (dinilai berdasarkanmax_connect_errorsvariabel sistem). Hanya kesalahan jabat tangan protokol yang dihitung, dan hanya untuk host yang lulus validasi (HOST_VALIDATED = YA). MySQLKlien perlu memulai protokol jabat tangan tiga kali untuk membuat koneksi dengan database, dalam keadaan normal, waktu ini sangat singkat, tetapi begitu kelainan jaringan, batas waktu jaringan, dan faktor lainnya muncul, itu akan menyebabkan protokol jabat tangan tidak dapat diselesaikan, MySQL memiliki parameter connect_timeout, ini adalah waktunya bagi server MySQL proses mysqld untuk menunggu koneksi dibuat, dalam hitungan detik. Jika jabat tangan protokol masih belum selesai setelah jangka waktu connect_timeout, klien MySQL akan menerima pengecualian dengan pesan pengecualian yang mirip dengan: Kehilangan koneksi ke server MySQL di 'XXX', kesalahan sistem: errno, variabel default ke 10 detik:
Mari kita bangun kasus di mana koneksi database terputus disebabkan oleh batas waktu jaringan, kami menggunakan perintah netem dan tc di Linux untuk mensimulasikan kasus penundaan transmisi jaringan di lingkungan yang kompleks, setelah pengaturan berikut, saat ini dari server uji untuk mengakses server MySQL, akan ada penundaan 11 detik: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) byte data. 64 byte dari 10.20.57.24: icmp_seq=1 ttl=62 waktu=0.251 ms 64 byte dari 10.20.57.24: icmp_seq=2 TTL=62 Waktu=0.330 ms 64 byte dari 10.20.57.24: icmp_seq=3 ttl=62 waktu=0.362 ms 64 byte dari 10.20.57.24: icmp_seq=4 ttl=62 waktu=0.316 ms 64 byte dari 10.20.57.24: icmp_seq=5 TTL=62 Waktu=0.281 ms 64 byte dari 10.20.57.24: icmp_seq=6 TTL=62 Waktu=0.377 ms ^C --- 10.20.57.24 statistik ping --- 6 paket ditransmisikan, 6 diterima, kehilangan paket 0%, waktu 5716ms RTT min/rata-rata/maks/mdev = 0,251/0,319/0,377/0,047 ms [root@gettestlnx02 ~]# TC QDISC Tambahkan Dev Eth0 root Netem Delay 11000ms [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) byte data. 64 byte dari 10.20.57.24: icmp_seq=1 ttl=62 waktu=11000 ms 64 byte dari 10.20.57.24: icmp_seq=2 TTL=62 Waktu=11000 ms 64 byte dari 10.20.57.24: icmp_seq=3 TTL=62 Waktu=11000 ms 64 byte dari 10.20.57.24: icmp_seq=4 TTL=62 Waktu=11000 ms 64 byte dari 10.20.57.24: icmp_seq=5 TTL=62 Waktu=11000 ms 64 byte dari 10.20.57.24: icmp_seq=6 ttl=62 waktu=11000 ms 64 byte dari 10.20.57.24: icmp_seq=7 TTL=62 Waktu=11000 ms
Kami terhubung ke database MySQL di server uji gettestlnx02 seperti yang ditunjukkan di bawah ini (perhatikan bahwa jika Anda terhubung ke server ini melalui ssh, akan sangat lambat untuk beroperasi di gettestlnx02 saat ini.) Tentu saja, Anda juga dapat mensimulasikan latensi jaringan di server MySQL, atau Anda dapat membuat latensi connect_timeout dan jaringan lebih kecil) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Masukkan kata sandi: KESALAHAN 2013 (HY000): Kehilangan koneksi ke server MySQL saat 'membaca paket otorisasi', kesalahan sistem: 0 [root@gettestlnx02 ~] # Seperti yang ditunjukkan di atas, karena penundaan jaringan lebih dari 10 detik, koneksi ke MySQL gagal, saat ini, ketika Anda mengkueri tabel host_cache di server MySQL, maka Anda akan melihat bahwa SUM_CONNECT_ERRORS telah menjadi 1, dan COUNT_HANDSHAKE_ERRORS juga telah berubah1.
Kemudian kami melemparkan seperti ini tiga kali berulang kali, dan Anda akan melihat bahwa SUM_CONNECT_ERRORS menjadi 3, dan COUNT_HANDSHAKE_ERRORS menjadi 3. Kemudian kami menggunakan perintah netem dan tc untuk membatalkan simulasi latensi jaringan pada server pengujian, lalu pergi ke koneksi pengujian ke database MySQL, seperti yang ditunjukkan dalam pengujian berikut: [root@gettestlnx02 ~]# TC QDISC del Dev Eth0 root Netem Delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Masukkan kata sandi: KESALAHAN 1129 (HY000): Host '192.168.27.180' diblokir karena banyak kesalahan koneksi; Buka blokir dengan 'MySQLADMIN flush-hosts' [root@gettestlnx02 ~] #
Saat ini, dapat dibangun“KESALAHAN 1129 (HY000): Host '192.168.27.180' diblokir karena banyak kesalahan koneksi; Buka blokir dengan 'MySQLADMIN flush-hosts'”Salah. larutan Terselesaikan ERROR 1129 (00000): Host 'xxx' diblokir karena banyak kesalahan koneksi. Ada banyak cara untuk mendapatkan kesalahan Buka blokir dengan 'mysqladmin flush-hosts', tetapi beberapa bersifat sementara. Rencana sementara adalah bahwa indikator tidak mengatasi akar penyebabnya. Kuncinya adalah memperbaiki kesalahan jaringan (yang seringkali memerlukan konsultasi dengan administrator jaringan atau administrator sistem) Solusi: 1, atur nilai variabel max_connection_errors ke nilai yang lebih besar
Solusi sementara ini hanyalah kondisi penundaan yang memicu IP untuk dilarang, dan dalam kasus yang kompleks atau konkurensi tinggi, perlu untuk menetapkan nilai yang besar, jika tidak, itu akan dengan mudah dipicu lagi. Selain itu, variabel hanya berlaku pada lingkungan saat ini, dan akan kedaluwarsa jika dimulai ulang. 2: penggunaanFlush host mysql> host siram; Kueri OK, 0 baris terpengaruh (0,00 detik) mysql> pilih * dari performance_schema.host_cache; Set kosong (0,00 detik) MySQL> Tentu saja, Anda juga dapat menggunakan perintah mysqladmin flush-hosts untuk membersihkan informasi cache host [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Masukkan kata sandi: Jadi apa itu cache host? Pengantar resmi adalah sebagai berikut: Server MySQL memelihara cache host dalam memori yang berisi informasi tentang klien: alamat IP, nama host, dan informasi kesalahan. Server menggunakan cache ini untuk koneksi TCP nonlokal. Itu tidak menggunakan cache untuk koneksi TCP yang dibuat menggunakan alamat antarmuka loopback (127.0.0.1 atau ::1), atau untuk koneksi yang dibuat menggunakan file soket Unix, pipa bernama, atau bersama memori. Secara sederhana, server MySQL memelihara cache dalam memori yang berisi informasi klien: alamat IP, nama host, pesan kesalahan, dll. Server menyimpan informasi koneksi TCP non-lokal. Itu tidak menyimpan koneksi TCP dalam cache yang dibuat menggunakan alamat antarmuka loopback (127.0.0.1 atau::1), atau koneksi yang dibuat menggunakan file soket Unix, alur bernama, atau memori bersama. Informasi cache host dapat dikueri melalui tabel host_cache di database performance_schema. 3: Atur variabel host_cache_size ke0 Faktanya, saya akan mengatakan bahwa ini adalah solusi yang paling tidak dapat diandalkan, hanya untuk membuat server MySQL tidak mencatat informasi cache host. Metode ini dapat diabaikan sama sekali.
| 
Diposting pada 08/04/2019 11.01.48
|
|
|
|
