Apa max_allowed_packet cukup besar, dan mengapa saya perlu mengubahnya?


14

Saya memiliki MySQL (5.5) dalam pengaturan master-slave dan membuat server slave lain.

Saya menghentikan budak asli, membuang data, menyalin dan mengimpor kembali dan itu bekerja dengan baik. Saya mencatat pos master_log dari slave asli dan menggunakan perintah ini untuk meletakkannya di slave baru

CHANGE MASTER TO MASTER_HOST='<ipaddress>', 
MASTER_USER='<username>', MASTER_PASSWORD='<password>', 
MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000851', 
MASTER_LOG_POS=15824150, 
MASTER_CONNECT_RETRY=10;

Ketika saya memulai budak baru yang saya dapatkan

Last_IO_Error: Mendapat kesalahan fatal 1236 dari master saat membaca data dari log biner: 'log event entry melebihi max_allowed_packet; Tingkatkan max_allowed_packet pada master '

Namun ketika saya memulai budak asli, itu berhasil dengan baik, dan sekarang sinkron.

Jadi pertanyaannya:

  • nilai saat ini adalah 16 juta, bagaimana saya tahu seberapa besar yang harus saya lakukan? (Saya lebih suka menghindari coba-coba dengan server produksi).

  • mengapa saya perlu meningkatkan nilai pada master ketika budak asli diatasi dengan baik, mungkinkah masalahnya dengan budak baru?

memperbarui

Saya meningkatkan max_allowed_packet menjadi 1073741824 ketika Rolando menyarankan master, slave lama dan slave baru, dan memulai kembali ( SET GLOBAL max_allowed_packet = 1073741824;untuk beberapa alasan sepertinya tidak mengambil)

sekarang kesalahan IO terakhir sama dengan sebelumnya, tapi sekarang saya mengerti

Last_SQL_Error: Kegagalan membaca log relai: Tidak dapat mengurai entri log aktivitas relai. Alasan yang mungkin adalah: log biner master rusak (Anda dapat memeriksa ini dengan menjalankan 'mysqlbinlog' pada log biner), log relay slave rusak (Anda dapat memeriksa ini dengan menjalankan 'mysqlbinlog' pada log relay), sebuah masalah jaringan, atau bug pada kode MySQL master atau slave. Jika Anda ingin memeriksa log biner master atau log relay slave, Anda akan dapat mengetahui namanya dengan mengeluarkan 'SHOW SLAVE STATUS' pada slave ini.

Jika saya melakukan mysqlbinlog pada file master, itu bergulir melewati dengan cukup senang selama berabad-abad - file adalah 722M - jika saya melakukan itu untuk log relay slave saya mendapatkan

GALAT: Kesalahan di Log_event :: read_log_event (): 'Sanity check gagal', data_len: 38916267, event_type: 69

GALAT: Tidak dapat membaca entri di offset 253: Kesalahan dalam format log atau kesalahan baca.

Saya memeriksa variabel dan perubahan berhasil

mysql> tampilkan variabel LIKE '% max_allowed_packet%';

pada budak baru menunjukkan max_allowed_packetDAN di slave_max_allowed_packetmana pada master itu hanya memilikimax_allowed_packet

jadi saya melakukan pemeriksaan versi pada master:

mysql> show variables LIKE '%version%';
+-------------------------+--------------------------------------+
| Variable_name           | Value                                |
+-------------------------+--------------------------------------+
| innodb_version          | 1.1.6                                |
| protocol_version        | 10                                   |
| slave_type_conversions  |                                      |
| version                 | 5.5.11-log                           |
| version_comment         | MySQL Community Server (GPL) by Remi |
| version_compile_machine | x86_64                               |
| version_compile_os      | Linux                                |
+-------------------------+--------------------------------------+

dan pada budak baru

mysql> show variables LIKE '%version%';
+-------------------------+--------------------------------------+
| Variable_name           | Value                                |
+-------------------------+--------------------------------------+
| innodb_version          | 5.5.32                               |
| protocol_version        | 10                                   |
| slave_type_conversions  |                                      |
| version                 | 5.5.32-log                           |
| version_comment         | MySQL Community Server (GPL) by Remi |
| version_compile_machine | x86_64                               |
| version_compile_os      | Linux                                |
+-------------------------+--------------------------------------+

Apakah kedua versi ini terlalu jauh?


Ada beberapa hal yang menarik di sini . Semoga ini bisa membantu.
Sathish D

Jawaban:


18

Tidak apa-apa untuk memaksimalkan max_allowed_packetke 1G. Setiap kali Paket MySQL dibangun, itu tidak akan melompat ke 1G dari awal. Mengapa?

Pertama, Anda perlu tahu apa itu Paket MySQL. Halaman 99 dari Buku

Memahami MySQL Internal

menjelaskannya dalam paragraf 1-3 sebagai berikut:

Kode komunikasi jaringan MySQL ditulis dengan asumsi bahwa permintaan selalu cukup pendek, dan karena itu dapat dikirim ke dan diproses oleh server dalam satu potongan, yang disebut paket dalam terminologi MySQL. Server mengalokasikan memori untuk buffer sementara untuk menyimpan paket, dan meminta cukup untuk sepenuhnya cocok. Arsitektur ini memerlukan tindakan pencegahan untuk menghindari server kehabisan memori --- batas pada ukuran paket, yang dicapai opsi ini.

Kode yang terkait dengan opsi ini ditemukan di sql / net_serv.cc . Lihatlah my_net_read () , lalu ikuti panggilan ke my_real_read () dan perhatikan net_realloc () .

Variabel ini juga membatasi panjang hasil dari banyak fungsi string. Lihat sql / field.cc dan sql / intem_strfunc.cc untuk detailnya.

Bandingkan dengan Dokumentasi MySQL pada max_allowed_packet:

Ukuran maksimum satu paket atau string yang dihasilkan / perantara, atau parameter apa pun yang dikirim oleh fungsi mysql_stmt_send_long_data () C API. Standarnya adalah 4MB pada MySQL 5.6.6, 1MB sebelum itu.

Buffer pesan paket diinisialisasi ke net_buffer_length byte, tetapi dapat tumbuh hingga max_allowed_packet byte saat dibutuhkan. Nilai ini secara default kecil, untuk menangkap paket besar (mungkin salah).

Anda harus meningkatkan nilai ini jika Anda menggunakan kolom BLOB besar atau string panjang. Itu harus sebesar BLOB terbesar yang ingin Anda gunakan. Batas protokol untuk max_allowed_packet adalah 1GB. Nilai harus kelipatan 1024; nonmultiples dibulatkan ke kelipatan terdekat.

Ketika Anda mengubah ukuran buffer pesan dengan mengubah nilai variabel max_allowed_packet, Anda juga harus mengubah ukuran buffer di sisi klien jika program klien Anda mengizinkannya. Di sisi klien, max_allowed_packet memiliki standar 1GB. Beberapa program seperti mysql dan mysqldump memungkinkan Anda untuk mengubah nilai sisi klien dengan mengatur max_allowed_packet pada baris perintah atau dalam file opsi.

Dengan informasi ini, Anda seharusnya senang MySQL akan memperluas dan mengontrak Paket MySQL sesuai kebutuhan. Karena itu, silakan dan

Master dan Slave harus cocok dengan siapa yang mereka kirimkan data, terutama data BLOB.

UPDATE 2013-07-04 07:03 EDT

Dari pesan Anda tentang log relai, sepertinya Anda memiliki yang berikut ini

  • log relay yang rusak
  • master log yang bagus

SARAN

SHOW SLAVE STATUS\G
STOP SLAVE;
CHANGE MASTER TO
MASTER_LOG_FILE='(Relay_Master_Log_File from SHOW SLAVE STATUS\G)',
MASTER_LOG_POS=(Exec_Master_Log_Pos from SHOW SLAVE STATUS\G);
START SLAVE;

Menjalankan CHANGE MASTER TOmenghapus semua log relai dan mulai dengan yang baru. Anda akan mereplikasi dari Event Master BinLog Terakhir (BinLog, Posisi) yang dijalankan pada Slave.

Cobalah !!!


terima kasih, itu bagus karena aman; tapi saya masih belum mengerti mengapa saya harus mengubahnya sama sekali ketika nilai saat ini cocok dengan master, dan budak lain yang bekerja dengan sempurna?
CodeMonkey

sesuatu yang lain sedang terjadi, saya telah menambahkan rincian lebih lanjut
CodeMonkey

1
Sekadar informasi: Ini terjadi ketika saya mengatur ulang proses replikasi dan tidak sengaja memasukkan MASTER_LOG_FILEnama yang salah . Misalnya digunakan mysql-bin.000001ketika saya seharusnya menggunakannya mysql-bin.000003dari SHOW MASTER STATUSdalam CHANGE MASTER TO.
Mikko Ohtamaa

8

Agak memalukan masalahnya adalah nama file yang salah untuk log, menyebabkan hasil yang aneh, diterapkan kembali dengan nama file yang benar dan semuanya baik-baik saja hang malu


Terima kasih banyak! Anda bukan satu-satunya yang melakukan kesalahan ini.
Mikko Ohtamaa

3
Selalu layak memposting jawaban meskipun itu konyol. Semua orang membuat kesalahan konyol karena kita semua manusia. Terlepas dari kita yang merupakan robot.
John Hunt
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.