কোন ম্যাক্স_গ্রেড_প্যাকেটটি যথেষ্ট বড়, এবং কেন এটি পরিবর্তন করার দরকার?

Question

আমি মাস্টার-স্লেভ সেটআপে মাইএসকিউএল (5.5) রেখেছি এবং অন্য একটি ক্রীতদাস সার্ভার তৈরি করেছি।

আমি আসল ক্রীতদাসকে থামিয়ে দিয়েছি, ডেটা ফেলে দিয়েছি, অনুলিপি করেছি এবং পুনরায় আমদানি করেছি এবং এটি ভাল কাজ করেছে। আমি মূল দাসের মাস্টার_লগ পোস্টগুলি লক্ষ্য করেছি এবং নতুন দাসের উপরে সেট করতে এই আদেশগুলি ব্যবহার করেছি

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;

আমি যখন নতুন দাসটি শুরু করি তখন

শেষ_আইও_এররার: বাইনারি লগ থেকে ডেটা পড়ার সময় মাস্টার থেকে মারাত্মক ত্রুটি পেয়েছে: 'লগ ইভেন্টের এন্ট্রি ম্যাক্স_গ্রেড_প্যাককেট ছাড়িয়ে গেছে; মাস্টারের উপরে সর্বোচ্চ_গোলিত_প্যাকটি বাড়ান

তবে আমি যখন আসল দাসটি শুরু করি তখন তা ঠিক হয়ে যায় এবং এখন সিঙ্ক হয়।

সুতরাং প্রশ্নগুলি:

• বর্তমান মান 16M, আমি কীভাবে যেতে পারি তা আরও বড় হতে পারে? (আমি বরং প্রোডাকশন সার্ভার দিয়ে পরীক্ষা এবং ত্রুটি এড়াতে চাই)।

• মূল দাস যখন ঠিক জরিমানা করেছিল তখন আমার কেন গুরু বাড়ানোর দরকার আছে, নতুন দাসের সাথে সমস্যাটি আসলেই হতে পারে?

হালনাগাদ

রোল্যান্ডো মাস্টার, পুরানো দাস এবং নতুন দাসের পরামর্শ হিসাবে আমি ম্যাক্স_গ্ল্যাড_প্যাকেটটি 1073741824 এ বাড়িয়েছি এবং সেগুলি পুনরায় চালু করেছি ( SET GLOBAL max_allowed_packet = 1073741824;কোনও কারণে এটি মনে হয় নি)

এখন শেষ আইও ত্রুটি আগের মতই তবে এখন আমি দেখতে পাচ্ছি

শেষ_কিউএসএল_এরর: রিলে লগ পড়ার ব্যর্থতা: রিলে লগ ইভেন্ট এন্ট্রিটিকে পার্স করতে পারেনি। সম্ভাব্য কারণগুলি হ'ল: মাস্টারের বাইনারি লগটি দুর্নীতিগ্রস্থ হয়েছে (বাইনারি লগে 'mysqlbinlog' চালিয়ে আপনি এটি পরীক্ষা করতে পারেন), স্লেভের রিলে লগটি ক্ষতিগ্রস্থ হয়েছে (আপনি রিলে লগটিতে 'mysqlbinlog' চালিয়ে এটি পরীক্ষা করতে পারেন), একটি নেটওয়ার্ক সমস্যা বা মাস্টার বা স্লেভের মাইএসকিউএল কোডে একটি বাগ। আপনি যদি মাস্টারের বাইনারি লগ বা স্লেভের রিলে লগটি পরীক্ষা করতে চান তবে আপনি এই ক্রীতদাসের উপর 'স্লেভ স্ট্যাটাস দেখান' জারি করে তাদের নামগুলি জানতে পারবেন।

যদি আমি মাস্টারের ফাইলটিতে একটি মাইএসকিএলবিনলগ করি তবে এটি কমান্ডগুলি সহকারে বয়সের জন্য বেশ আনন্দের সাথে স্ক্রোল করে - ফাইলটি 722 এম - যদি আমি দাস রিলে লগের জন্য এটি করি তবে আমি পাই

ত্রুটি: লগ_সেন্টে ত্রুটি :: পঠন-লগ_সেন্ট (): 'স্যানিটি চেক ব্যর্থ হয়েছে', ডেটা_লেন: 38916267, ইভেন্ট_ টাইপ: 69

ত্রুটি: অফসেটে এন্ট্রি পড়তে পারা যায়নি 253: লগ ফর্ম্যাটে ত্রুটি বা পড়ার ত্রুটি।

আমি ভেরিয়েবলগুলি পরীক্ষা করেছি এবং পরিবর্তনগুলি তবে কাজ করেছে

mysql> দেখান ভেরিয়েবলগুলি '% সর্বাধিক_নীত_প্যাক্ট%' পছন্দ করুন;

নতুন দাস দেখানো হয়েছে max_allowed_packetএবং slave_max_allowed_packetযেখানে তার উপর কেবলমাত্র মাস্টার রয়েছেmax_allowed_packet

সুতরাং আমি মাস্টারের উপর একটি সংস্করণ পরীক্ষা করেছি:

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

এবং নতুন দাস উপর

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

এই 2 সংস্করণগুলি কি খুব দূরে রয়েছে?

Comments

এখানে আকর্ষণীয় কিছু আছে । আশা করি এটি সহায়ক হবে।

— সতীশ ডি

Answer 1

max_allowed_packet1 জি থেকে সর্বোচ্চ সীমাবদ্ধ করা ঠিক আছে । যখনই কোনও মাইএসকিউএল প্যাকেট নির্মিত হয়, এটি শুরু থেকে 1 জি-তে লাফ দেয় না। কেন?

প্রথমে আপনাকে একটি মাইএসকিউএল প্যাকেটটি জানতে হবে। বইয়ের 99 পৃষ্ঠা

এটি অনুচ্ছেদগুলিতে 1-3 হিসাবে ব্যাখ্যা করেছেন:

মাইএসকিউএল নেটওয়ার্ক যোগাযোগ কোড এই অনুমানের অধীনে লেখা হয়েছিল যে প্রশ্নগুলি সর্বদা যুক্তিযুক্তভাবে সংক্ষিপ্ত থাকে এবং তাই সার্ভারের মাধ্যমে একটি অংশে প্রেরণ এবং প্রক্রিয়া করা যায়, যা মাইএসকিউএল পরিভাষায় একটি প্যাকেট বলে । প্যাকেটটি সংরক্ষণ করার জন্য সার্ভার অস্থায়ী বাফারের জন্য মেমরির বরাদ্দ করে এবং এটি পুরোপুরি ফিট করার জন্য এটি যথেষ্ট অনুরোধ করে। এই আর্কিটেকচারটির জন্য সার্ভারের স্মৃতিশক্তি শেষ না হওয়া এড়ানোর জন্য একটি সতর্কতা প্রয়োজন --- প্যাকেটের আকারের একটি ক্যাপ, যা এই বিকল্পটি সম্পাদন করে।

এই বিকল্পের সাথে সম্পর্কিত আগ্রহের কোডটি স্কুয়েল / নেট_জারি.সি.সি তে পাওয়া যায় । কটাক্ষপাত my_net_read () , তারপর থেকে কল অনুসরণ my_real_read () এবং বিশেষভাবে নজর দিতে net_realloc () ।

এই পরিবর্তনশীলটি অনেকগুলি স্ট্রিং ফান্টাক্টনের ফলাফলের দৈর্ঘ্যও সীমাবদ্ধ করে। দেখুন SQL / field.cc এবং SQL / intem_strfunc.cc বিস্তারিত জানার জন্য।

এর সাথে মাইএসকিউএল ডকুমেন্টেশনের সাথে তুলনা করুন max_allowed_packet:

একটি প্যাকেট বা যেকোন উত্পন্ন / মধ্যবর্তী স্ট্রিংয়ের সর্বাধিক আকার, বা মাইএসকিএল_এসটিএমটি_সেন্ড_লং_ডাটা () সি এপিআই ফাংশন দ্বারা প্রেরিত কোনও প্যারামিটার। ডিফল্টটি মাইএসকিউএল 5.6.6 হিসাবে 4MB, এর আগে 1MB।

প্যাকেট বার্তা বাফারটি নেট_বুফার_ দৈর্ঘ্য বাইটে শুরু করা হয়, তবে যখন প্রয়োজন হয় তখন সর্বোচ্চ_নিয়েলড_প্যাকেট বাইটে বাড়তে পারে। বৃহত্তর (সম্ভবত ভুল) প্যাকেটগুলি ধরতে, ডিফল্টরূপে এই মানটি ছোট।

আপনি যদি বড় BLOB কলাম বা দীর্ঘ স্ট্রিং ব্যবহার করছেন তবে আপনার অবশ্যই এই মানটি বাড়াতে হবে। এটি আপনি যে বৃহত্তম BLOB ব্যবহার করতে চান তার চেয়ে বড় হওয়া উচিত। সর্বোচ্চ_গনিত_প্যাককেটের প্রোটোকল সীমাটি 1 জিবি। মান 1024 এর একাধিক হওয়া উচিত; ননমুটটিপলগুলি নিকটতম একাধিকটিতে গোল হয়।

আপনি যখন ম্যাসেজ বাফার আকারটি সর্বাধিক_নয়েড_প্যাক্ট ভেরিয়েবলের মান পরিবর্তন করে পরিবর্তন করেন, আপনার ক্লায়েন্ট প্রোগ্রাম যদি অনুমতি দেয় তবে আপনার ক্লায়েন্টের পাশে বাফার আকারও পরিবর্তন করা উচিত। ক্লায়েন্টের পক্ষে, ম্যাক্স_গ্রেড_প্যাককেটে 1 জিবি ডিফল্ট রয়েছে। কিছু প্রোগ্রাম যেমন মাইএসকিএল এবং মাইএসকিএলডাম্প আপনাকে কমান্ড লাইনে অথবা বিকল্প ফাইলে ম্যাক্স_গ্রেড_প্যাক্ট সেট করে ক্লায়েন্ট-সাইড মান পরিবর্তন করতে সক্ষম করে।

এই তথ্যটি দেওয়া, আপনার মাইএসকিউএলটি প্রয়োজন হিসাবে মাইএসকিউএল প্যাকেটটি প্রসারিত করবে এবং চুক্তি করবে সে সম্পর্কে আপনারা আনন্দিত হওয়া উচিত। অতএব, এগিয়ে যান এবং

• max_allowed_packetমাস্টার এবং স্লেভ উভয়কেই 1G তে সেট করুন
• net_buffer_lengthমাস্টার এবং স্লেভ উভয়কেই এর সর্বোচ্চ মান 1 এম সেট করে

মাস্টার এবং স্লেভের সাথে তারা কে ডেটা প্রেরণ করে বিশেষত বিএলওবি ডেটা মেনে চলতে হবে।

আপডেট 2013-07-04 07:03 ইডিটি

রিলে লগ সম্পর্কিত আপনার বার্তাগুলি থেকে দেখে মনে হচ্ছে আপনার নিম্নলিখিত রয়েছে

• একটি দুর্নীতিগ্রস্থ রিলে লগ
• একটি ভাল মাস্টার লগ

পরামর্শ

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;

চলমান CHANGE MASTER TOসমস্ত রিলে লগ সাফ করে এবং একটি নতুন দিয়ে শুরু হয়। স্লেভের উপর মৃত্যুদন্ড কার্যকর করা সর্বশেষ মাস্টার বিনলগ ইভেন্ট (বিনলগ, অবস্থান) থেকে আপনি প্রতিলিপি তৈরি করবেন।

একবার চেষ্টা করে দেখো !!!

Comments

ধন্যবাদ, এটি দুর্দান্ত যে এটি নিরাপদ; তবে আমি এখনও পাই না কেন যখন বর্তমান মানটি মাস্টার এবং অন্য দাসের সাথে পুরোপুরি কাজ করছে তখন কেন আমাকে এটিকে পরিবর্তন করতে হবে?

— কোডমনকি

অন্য কিছু চলছে, আমি আরও বিশদ যুক্ত করেছি

— CodeMonkey

কেবল আপনার তথ্যের জন্য: যখন আমি প্রতিলিপি প্রক্রিয়াটি পুনরায় সেট করি এবং ঘটনাক্রমে ভুল MASTER_LOG_FILEনামে প্রবেশ করি তখন এটি আমার ঘটেছিল । যেমন ব্যবহৃত mysql-bin.000001যখন আমি ব্যবহার করা উচিত ছিল mysql-bin.000003থেকে SHOW MASTER STATUSএ CHANGE MASTER TO।

— মিক্কো ওহতামা

Answer 2

বরং বিব্রতকরভাবে সমস্যাটি লগগুলির জন্য ভুল ফাইলের নাম ছিল, অদ্ভুত ফলাফলের কারণ হয়েছিল, সঠিক ফাইলের নামগুলির সাথে পুনর্মিলনী করা হয়েছিল এবং লজ্জার কারণেই সবকিছু ঠিকঠাক ছিল head

Comments

অনেক ধন্যবাদ! আপনি কেবল এই ভুলটি করছিলেন না।

— মিক্কো ওহতামা

মূর্খতা থাকলেও উত্তর পোস্ট করা সর্বদা মূল্যবান। আমরা সবাই মানুষ হওয়ায় সকলেই মূর্খ ভুল করে। আমাদের মধ্যে রোবট ছাড়াও।

— জন হান্ট