Hangi max_allowed_packet yeterince büyük ve neden değiştirmem gerekiyor?


14

Master-slave kurulumunda MySQL (5.5) var ve başka bir slave sunucu oluşturdum.

Orijinal köleyi durdurdum, verileri döktüm, kopyaladım ve yeniden gönderdim ve işe yaradı. Orijinal köle master_log pos kaydetti ve yeni slave ayarlamak için bu komutları kullandım

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;

Yeni köle başladığımda

Last_IO_Error: İkili günlükten veri okurken master'dan 1236'da önemli hata var: 'log olay girişi max_allowed_packet'i aştı; Master'da max_allowed_packet değerini artır '

Ancak orijinal köleyi başlattığımda, gayet iyi yakalandı ve şimdi senkronize.

Yani sorular:

  • mevcut değer 16M, ne kadar büyük gideceğini nasıl bilebilirim? (Bir üretim sunucusu ile deneme yanılma önlemek istiyorum).

  • neden orijinal köle iyi başa çıkarken ustanın değerini arttırmam gerekiyor, sorun gerçekten yeni köle ile ilgili olabilir mi?

Güncelleme

Rolando'un usta, yaşlı köle ve yeni köle üzerinde önerdiği gibi max_allowed_packet'i 1073741824'e yükselttim ve onları yeniden başlattım ( SET GLOBAL max_allowed_packet = 1073741824;bir nedenden dolayı görünmüyordu)

şimdi son IO hatası öncekiyle aynı, ama şimdi görüyorum

Last_SQL_Error: Geçiş günlüğü okuma hatası: Geçiş günlüğü olay girişi ayrıştırılamadı. Olası nedenler: kaptanın ikili günlüğü bozuk (bunu ikili günlüğünde 'mysqlbinlog' çalıştırarak kontrol edebilirsiniz), slave'in geçiş günlüğü bozuk (bunu aktarma günlüğünde 'mysqlbinlog' çalıştırarak kontrol edebilirsiniz), ağ sorunu veya master veya slave'in MySQL kodundaki bir hata. Kaptanın ikili günlüğünü veya köle'nin geçiş günlüğünü kontrol etmek isterseniz, bu slave üzerinde 'SLAVE STATUS GÖSTER' komutunu kullanarak adlarını öğrenebileceksiniz.

Master'ın dosyasında mysqlbinlog yaparsam, çağlar için oldukça mutlu komutlar ile geçmiş kaydırır - dosya 722M - köle geçiş günlüğü için bunu yaparsam

HATA: Log_event'te hata :: read_log_event (): 'Sağlık kontrolü başarısız', data_len: 38916267, event_type: 69

HATA: Ofset 253'teki giriş okunamadı: Günlük biçiminde hata veya okuma hatası.

Değişkenleri kontrol ettim ve değişiklikler çalıştı

mysql> değişkenleri göster LIKE '% max_allowed_packet%';

yeni köle gösterdi max_allowed_packetVE slave_max_allowed_packetnerede usta sadece olduğu gibimax_allowed_packet

bu yüzden master üzerinde bir versiyon kontrolü yaptım:

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                                |
+-------------------------+--------------------------------------+

ve yeni kölede

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                                |
+-------------------------+--------------------------------------+

Bu 2 versiyon çok mu fazla?


Burada ilginç bir şey var . Umarım bu yardımcı olur.
Sathish D

Yanıtlar:


18

Dışarı max için en TAMAM max_allowed_packet1G kadar. Bir MySQL Paketi oluşturulduğunda, başlangıçtan itibaren 1G'ye atlamaz. Neden?

Öncelikle ne bir MySQL Paketini bilmeniz gerekir. Sayfa 99

MySQL Dahili Öğelerini Anlama

1-3. paragraflarda şöyle açıklar:

MySQL ağ iletişim kodu, sorguların her zaman makul derecede kısa olduğu ve bu nedenle MySQL terminolojisinde paket olarak adlandırılan bir yığın halinde sunucuya gönderilebileceği ve işlenebileceği varsayımı altında yazılmıştır . Sunucu, paketi saklamak için belleği geçici bir arabellek için ayırır ve tamamen sığdırmak için yeterli bilgi ister. Bu mimari, sunucunun belleğinin bitmemesini önlemek için bir önlem gerektirir - bu seçeneğin gerçekleştirdiği paket boyutunda bir kapak.

Bu seçenekle ilgili ilgi kodu sql / net_serv.cc'de bulunur . Bir göz atın my_net_read () , ardından çağrısına izleyin my_real_read () ve özellikle dikkat ) (net_realloc .

Bu değişken ayrıca birçok dize işlevinin sonucunun uzunluğunu da sınırlar. Ayrıntılar için sql / field.cc ve sql / intem_strfunc.cc adresine bakın.

Bunu MySQL Belgeleri ile karşılaştırın max_allowed_packet:

Bir paketin veya oluşturulan / ara dizenin veya mysql_stmt_send_long_data () C API işlevi tarafından gönderilen herhangi bir parametrenin maksimum boyutu. Varsayılan değer, MySQL 5.6.6'dan itibaren 4MB, bundan 1MB önce.

Paket ileti arabelleği net_buffer_length bayt olarak başlatılır, ancak gerektiğinde max_allowed_packet bayta kadar büyüyebilir. Büyük (büyük olasılıkla yanlış) paketleri yakalamak için varsayılan olarak bu değer küçüktür.

Büyük BLOB sütunları veya uzun dizeler kullanıyorsanız bu değeri artırmalısınız. Kullanmak istediğiniz en büyük BLOB kadar büyük olmalıdır. Max_allowed_packet için protokol sınırı 1 GB'dir. Değer 1024'ün katı olmalıdır; çoklu olmayanlar en yakın katına yuvarlanır.

İleti arabellek boyutunu max_allowed_packet değişkeninin değerini değiştirerek değiştirdiğinizde, istemci programınız buna izin veriyorsa, istemci tarafında arabellek boyutunu da değiştirmelisiniz. İstemci tarafında, max_allowed_packet varsayılan olarak 1GB'dir. Mysql ve mysqldump gibi bazı programlar, komut satırında veya bir seçenek dosyasında max_allowed_packet ayarlayarak istemci tarafı değerini değiştirmenizi sağlar.

Bu bilgiler göz önüne alındığında, MySQL'in MySQL Paketini gerektiği gibi genişletip büzeceğinden memnun olmalısınız. Bu nedenle, devam edin ve

Master ve Slave, özellikle BLOB verileri olmak üzere, verileri kim aktardıklarına göre eşleşmelidir.

GÜNCELLEME 2013-07-04 07:03 EDT

Geçiş günlüğü ile ilgili iletilerinizden, aşağıdakilere sahip gibi görünüyorsunuz

  • bozuk bir röle günlüğü
  • iyi bir ana günlük

ÖNERİ

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;

Koşu CHANGE MASTER TOtüm röle günlüklerini temizler ve yenisiyle başlar. Slave üzerinde yürütülen Son Ana BinLog Olayından (BinLog, Konum) çoğaltılmış olacaksınız.

Bir şans ver !!!


teşekkürler, güvenli olması harika; ama hala geçerli değer master ve mükemmel çalışan diğer slave ile eşleştiğinde neden değiştirmem gerektiğini anlamıyorum?
CodeMonkey

başka bir şey oluyor, daha fazla ayrıntı ekledim
CodeMonkey

1
Sadece bilginiz için: Bu, çoğaltma işlemini sıfırladığımda ve yanlışlıkla yanlış MASTER_LOG_FILEad girdiğimde ortaya çıktı . Örneğin kullanılan mysql-bin.000001Kullanmış gerekirken mysql-bin.000003dan SHOW MASTER STATUSiçinde CHANGE MASTER TO.
Mikko Ohtamaa

8

Daha ziyade sorun utanç verici bir şekilde günlükler için yanlış dosya adlarıydı, garip sonuçlara neden oldu, doğru dosya adlarıyla yeniden içe aktarıldı ve her şey yolundaydı utanç içinde kafa asılı


Çok teşekkürler! Bu hatayı yapan tek kişi sen değilsin.
Mikko Ohtamaa

3
Aptalca olsa bile her zaman cevabı göndermeye değer. Hepimiz insan olduğumuz için herkes aptalca hatalar yapıyor. Robot olan bizler dışında.
John Hunt
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.