মাইএসকিউএল রিলে লগ দূষিত হয়েছে, আমি কীভাবে এটি ঠিক করব? চেষ্টা করেছেন কিন্তু ব্যর্থ হয়েছেন

Question

মেশিনটি হঠাৎ বন্ধ হয়ে গেলে একটি মাইএসকিউএল ভি 5.1.61 রিলে ক্ষতিগ্রস্থ হয়েছিল। আমি এটি ঠিক করার চেষ্টা করেছি কিন্তু এটি কার্যকর হয়নি।
- আমি কীভাবে এটি ঠিক করব? আমি কি কিছু ভুল করবেন?

আমি যতদূর পড়েছি, দূষিত মাইএসকিউএল রিলে লগগুলি সহজেই ঠিক করা হয়েছে:

change master to master_log_file='<Relay_Master_Log_File>',
                 master_log_pos=<Exec_Master_Log_Pos>;

কোথায় Relay_Master_Log_Fileএবং Exec_Master_Log_Posতালিকাভুক্ত:
mysql> show slave status;

তবে যখন আমি এটি করি change master status ..., তখন আমি একটি প্রাথমিক কী লঙ্ঘনের ত্রুটি পেয়েছি। কীভাবে সম্ভব? উপরের পদ্ধতিটি কি সঠিক নয় বা উদাহরণস্বরূপ কিছু +1 অনুপস্থিত?

_{(আপাতত আমি কেবল মাস্টার থেকে দাসের কাছে একটি - মাস্টার-ডেটা মাইসকিডম্প্প আমদানি করেছি এবং এটি সমস্যার সমাধান করেছে solved তবে, ভবিষ্যতে এটি করা উপযুক্ত নাও হতে পারে))}

এখানে আমার বিশেষ সমস্যা সম্পর্কে বিশদ বিবরণ অনুসরণ করা হয়েছে:

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: the-master-host
                  Master_User: replication
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000021
          Read_Master_Log_Pos: 33639968
               Relay_Log_File: mysql-relay-bin.000271
                Relay_Log_Pos: 2031587
        Relay_Master_Log_File: mysql-bin.000020
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: the_database
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1594
                   Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 66395191
              Relay_Log_Space: 36559177
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 1594
               Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.

এবং এটি আমিই করেছি:

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_host='the-master-host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

এবং এটি ঘটেছে, একটি পিকে ত্রুটি:

131122 15:17:29 [Note] Slave I/O thread: connected to master 'replication@the-master-host:3306',replication started in log 'mysql-bin.000020' at position 66395191
131122 15:17:29 [ERROR] Slave SQL: Error 'Duplicate entry '71373' for key 'PRIMARY'' on query. Default database: 'the_database'. Query: 'insert into ...  values ...', Error_code: 1062
131122 15:17:29 [Warning] Slave: Data truncated for column 'date' at row 1 Error_code: 1265
131122 15:17:29 [Warning] Slave: Duplicate entry '71373' for key 'PRIMARY' Error_code: 1062

আমি মনে করি আমি প্রস্তাবিত পদ্ধতিটি অনুসরণ করেছি (ঠিক নীচে লিঙ্কগুলি দেখুন), এখনও একটি পিকে ত্রুটি ছিল :-(? Http://bugs.mysql.com/bug.php?id=26489 , "ওয়ার্কআরাউন্ডস" অনুসন্ধান করুন http //mhbarr.wordpress.com/2013/07/26/mysql-slave-corped-relay-log/ /programming//a/14438408

Comments

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

— মাইকেল - স্কলবট

ধন্যবাদ @ মাইকেল-স্ক্লবট, এর পরে আমি মনে করি যে যদি এই সমস্যাটি আবার ঘটে তবে আমি SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;দাসের উপর একটি ঘটনা এড়িয়ে যাব এবং আশা করি যে এটি সহায়তা করে - এর অর্থ কি কোনও বোঝায়? যদি এটি সহায়তা না করে (যদি এখনও পিকে ত্রুটি থাকে) তবে আমি --master-dataআবার একটি ডাম্প আমদানি করব ।

— KajMagnus

Answer 1

ত্রুটি: সর্বশেষ_এসকিউএল_আর্নো: 1594 লাস্ট_এসকিউএল_ইরর: রিলে লগ পড়ার ব্যর্থতা: রিলে লগ ইভেন্ট এন্ট্রিটিকে পার্স করতে পারেনি।

এই ত্রুটিটির অর্থ হ'ল হয় মাস্টার লগ ফাইলটি দুর্নীতিগ্রস্থ হয়েছে বা রিলে লগ ফাইলটি নষ্ট হয়েছে।

• আপনার সমস্ত ডাটাবেস, লগ, ইমেজ সার্ভার, পুনরাবৃত্তি, কয়েকবার ব্যাকআপ করার আগে এবং কেবল নিজের ঝুঁকিতে চালিয়ে যান।

প্রথমে দাসের উপরে "দাসের অবস্থা \ G" দেখান এবং দ্রষ্টব্য:

Master_Log_File: mysql-bin.000026
Read_Master_Log_Pos: 2377104
Relay_Log_File: mysqld-relay-bin.000056
Relay_Log_Pos: 1097303
Relay_Master_Log_File: mysql-bin.000026
Exec_Master_Log_Pos: 1097157

প্রথমে আমরা মাস্টার লগ ফাইলটি অক্ষত আছে তা নিশ্চিত করতে চাই, সুতরাং মাস্টার সার্ভারে ঝাঁপুন এবং রিলে_মাস্টার_লগ_ফাইলে (চেক / ভার / লগ / মাইএসকিএল) সন্ধান করুন এবং নিম্নলিখিত কমান্ডটি চালান:

mysqlbinlog mysql-bin.000026

লগ প্রদর্শিত হবে তবে আশা করি আপনি কোনও ত্রুটি বার্তা দেখতে পাবেন না। আপনি যদি ত্রুটির বার্তা দেখতে পান তবে মাস্টার লগগুলি দুর্নীতিগ্রস্থ এবং আপনার সম্ভবত পুনরায় চিত্র দেখাতে হবে।

পরবর্তী স্লেভ রিলে লগে একই কমান্ডটি চালান (প্রায়শই / var / lib / mysql তে)

mysqlbinlog mysqld-relay-bin.000056

দুর্নীতি দেখাতে কিছু ত্রুটি আপনি সম্ভবত দেখতে পাবেন যা প্রতিরূপ বন্ধ করেছে, এরকম:

ERROR: Error in Log_event::read_log_event(): 'read error', data_len: 336, event_type: 2
ERROR: Could not read entry at offset 1097414: Error in log format or read error.
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
root@db:/var/lib/mysql#

যদি আপনি কোনও ত্রুটি দেখতে পান তবে লগটি মাস্টারের উপর ঠিক আছে এবং কেবলমাত্র দাসের রিলে লগটি দুর্নীতিগ্রস্থ। এটি সুসংবাদ, আমরা দাসটিকে পুনরায় সেট করতে পারি এবং এটি মাস্টার্সের বিশদ এবং কোথা থেকে চালিয়ে যেতে পারি তা বলতে পারি। যদি আপনি কোনও ত্রুটি না দেখেন তবে এখনই পড়া বন্ধ করুন, আপনার একটি আলাদা সমস্যা আছে।

যদি স্লেভ রিলে লগটিতে ত্রুটি থাকে তবে স্লেভকে পুনরায় সেট করার জন্য নিম্নলিখিত কমান্ডগুলি চালনা করুন এবং দূষিত লগগুলি মাস্টারের সাথে পুনরায় সংযোগ স্থাপন করুন, ঠিক আছে লগগুলি পান এবং আবার স্লেভিং শুরু করুন। মনে রাখবেন যে MASTER_LOG_POS হ'ল Exec_Master_Log_Posএবং MASTER_LOG_FILE হ'ল Relay_Master_Log_File( প্রথমটি নয় , যা রিলে লগগুলির সাথে মেলে যা প্রাপ্ত হয়েছে এবং ফেলে দেওয়া দরকার) উভয়ই প্রথম কমান্ড থেকে।

mysql> stop slave;
Query OK, 0 rows affected (0.14 sec)

mysql> reset slave all;
Query OK, 0 rows affected (0.43 sec)

mysql>  CHANGE MASTER TO MASTER_HOST='master.host.com', MASTER_USER='masteruser', MASTER_PASSWORD='masterpass', MASTER_LOG_FILE='mysql-bin.000026', MASTER_LOG_POS=1097157;
Query OK, 0 rows affected (0.93 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

Comments

হাই, আপনার উত্তরের জন্য ধন্যবাদ। আপনি যদি প্রশ্নটি মনোযোগ সহকারে পড়েন তবে আপনি লক্ষ্য করবেন যে এটি "রিলে লগ ক্ষতিগ্রস্থ হয়েছে" - কারণ mysqlbinlogএটি আপনার পরামর্শ মতো আমরা ইতিমধ্যে ব্যবহার করেছি এবং খুঁজে পেয়েছি যে রিলে লগ (মাস্টার লগ নয়) দূষিত হয়েছিল। আপনার প্রস্তাবিত ফিক্সকে কেন্দ্র করে - আপনি যদি প্রশ্নটি মনোযোগ সহকারে পড়েন তবে আপনি লক্ষ্য করবেন যে আপনার প্রস্তাবিত ফিক্সটি হ'ল আমরা ইতিমধ্যে চেষ্টা করেছি। কিন্তু এটি কার্যকর হয়নি, এবং এটাই প্রশ্নটি। - তবে আপনার উত্তরটি একই রকম সমস্যাযুক্ত অন্যান্য ব্যক্তির পক্ষে কার্যকর হতে পারে।

— কাজম্যাগনুস

এটি সম্ভবত লক্ষ MASTER_LOG_FILEকরা CHANGE MASTERউচিত , যে থেকে নেওয়া উচিত Relay_Master_Log_Fileএবং থেকে নেওয়া উচিত নয় Master_Log_File। সাধারণত এগুলি একই রকম হয় তবে এটি সর্বদা ক্ষেত্রে নাও হতে পারে ( পারকোনা . com/blog/2008/07/07/… দেখুন )।

— brablc

@ ব্রাবল্ক ঠিক আছে। Relay_Master_Log_Fileব্যবহার করা উচিত, না Master_Log_File। আরও দেখুন: percona.com/blog/2008/07/07/…

— মিরসিয়া ভুটকোভিচি

বেশিরভাগ ক্ষেত্রে, এর প্রয়োজন নেই reset slave allকারণ মাস্টার সেটিংস পরিবর্তন করার প্রয়োজন নেই (যেমন মাস্টার_হোস্ট, মাস্টার_উজার, মাস্টার_পাশওয়ার্ড), কেবলমাত্র ম্যাসিস্ট_লগ_ফায়াল এবং মাস্টার_লোগ_পোস, তারপরে একটি reset_slaveযথেষ্ট হওয়া উচিত

— ympostor

এই প্রশ্ন এবং উত্তর আমার বাট ইতিমধ্যে বেশ কয়েকবার সংরক্ষণ করেছে। ধন্যবাদ.

— আর্টেম রাশাকোভস্কিই

Answer 2

[দাসদের রিলে লগের পরে মাইএসকিউএল প্রতিলিপি ঠিক করা]

স্লেভের উপর MySQL প্রতিলিপি (সংস্করণ 5.XX) বন্ধ হয়ে গেছে। স্লেভ_আইও_রানিংকে হ্যাঁ হিসাবে চিহ্নিত করা হয়েছে, তবে স্লেভ_এসকিউএল_ রেনিং নং হিসাবে সরল স্টপ / স্টাভ স্লেভ সহায়তা করেনি সুতরাং আরও সমস্যা বিশ্লেষণের প্রয়োজন ছিল। দেখে মনে হয়েছিল যে বর্তমান দাসের রিলে লগটি দূষিত হয়েছিল কারণ "মাইএসকিএলবিনলগ" দিয়ে পরীক্ষা করার ফলে একটি ত্রুটি মুদ্রিত হয়েছে। সুতরাং, সমাধানটি ছিল বর্তমান রিলে বিনলোগগুলি বাতিল এবং শেষ মাস্টার বিনলগ অবস্থানে স্লেভকে নির্দেশ করা।

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

Relay_Master_Log_File: mysql-bin.002045
Exec_Master_Log_Pos: 103641119

ঠিক আছে, এই মানগুলির সাথে, নতুন বেনলোগ অবস্থানটি সেট করা যেতে পারে:

# stop slave
mysql> stop slave;

# make slave forget its replication position in the master's binary log
mysql> reset slave;

# change slave to start reading from stopped position
mysql> change master to master_log_file='mysql-bin.002045', master_log_pos=103641119;

# start slave
mysql> start slave;

শুধু নোট যে reset slaveমুছে ফেলবে master.info, relay-log.infoএবং সমস্ত রিলে লগ ফাইল, তাই এটি মধ্যে পরিষ্কার উচ্ছিষ্ট করা প্রয়োজন না /var/lib/mysqlনির্দেশিকা।

Comments

উত্তম উত্তর - সাধারণত আমাদের মাস্টার হোস্ট, পাসওয়ার্ড ইত্যাদির দরকার হয় না!

— andy250

Answer 3

আমি জানি এটি এক বছর কেটে গেছে, তবে এই বিশেষ সমস্যাটি ঘটেছে এমনটি এখানে রয়েছে।

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_host='the-master-host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

দেখে মনে হচ্ছে এটি ঠিক করা উচিত ছিল কারণ এটি দুর্নীতিগ্রস্থ রিলে লগটিকে সরিয়ে ফেলে।

তারপরে, আপনি একটি পিকে ত্রুটি পেয়েছেন 1062 Why কেন?

মাইএসকিউএল 5.5 এ এখনও সক্রিয় রয়েছে এমন একটি অসামান্য বাগ ( http://bugs.mysql.com/bug.php?id=60847 ) আছে

যদিও বাগটি মাইএসকিএল - স্যান্সেল-লেনদেন - ফ্লাশ-লগগুলি ব্যবহারের সাথে সম্পর্কিত, তবে একটি সম্পর্কিত ক্রিক উপস্থিত রয়েছে।

আমি দেখেছি যে কিছু ইসি 2 সার্ভারের ক্লায়েন্টের স্লেভ হিসাবে চলছিল কেবল গত সপ্তাহে মাইএসকিউএল 5.5.15 এ

মাস্টারটিতে, একটি বিচিত্র একাধিক সারি INSERT প্রসারিত ছিল যেখানে প্রতিটি টিপল beingোকানো হচ্ছে একটি নির্বাচন ছিল। যা ঘটেছিল তা হ'ল রিলে লগের LAST_INSERT_ID, যা নির্ধারিত পরবর্তী অটো ইনক্রিমেন্ট গঠন করে, একাধিক সারি সন্নিবেশ করার আগেই স্লেভটিতে ইতিমধ্যে ব্যবহৃত হয়েছিল।

রিলে লগটিতে সিরিয়ালযুক্ত INSERT দেখতে ভাল লাগছিল

INSERT INTO tablname (column,column) VALUES (value,value,...)

কলামের তালিকায় সংখ্যার প্রাথমিক কীটি অন্তর্ভুক্ত হয়নি। 1062 ত্রুটিটি ফিরে এলে, আমি একই ক্যোয়ারীটি ব্যর্থ করব যা এটি ব্যর্থ হয়েছিল, ক্যোয়ারিকে ম্যানুয়ালি চালান। এটি 1062 ত্রুটিটি আঘাত করে নি। তারপরে, আমি সাধারণ স্কিপ স্লেভ কমান্ডগুলি চালিত করেছিলাম:

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE;
SET @sleepnumber = SLEEP(3);
SHOW SLAVE STATUS\G

তারপরে, প্রতিরূপ ধরা পড়ে।

আমার পরামর্শটি হ'ল মাস্টারকে আপনার ইনসার্টগুলি সঠিকভাবে সিরিয়াল করা হবে কারণ এই বাগ-জাতীয় পরিস্থিতিটি আসলে বেশ এড়ানো যায় quite

Answer 4

আপনি এটি বেশ সঠিকভাবে করেছেন (অন্য ইতিমধ্যে বলেছে)।

একমাত্র সমস্যা হ'ল মাস্টার.info ফাইলের সাথে (মাস্টারের মাইএসকিএল-বিন.লগের অবস্থান সম্পর্কিত তথ্য রয়েছে) কারণ প্রতিটি ক্যোয়ারী প্রক্রিয়া করার পরে এই ফাইলটি ডিস্কে সিঙ্ক হয় না।

সুতরাং মাস্টারের লগের অবস্থানগুলি সম্পর্কে আপনার তথ্য পুরানো এবং আপনি ইতিমধ্যে প্রক্রিয়াজাত ক্যোয়ারী প্রসেস করছেন যা এড়ানো উচিত SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;।

দুর্ভাগ্যক্রমে, আপনি যদি কিছু ডাটা UPDATE table SET counter=counter+1 WHERE id = 12345ব্যবহার করেন এবং binlog_format=STATEMENTআপনার ডাটাবেসগুলি ব্যবহার করে সিঙ্কের বাইরে চলে যেতে পারে তবে আমার ধারণা।

আপনি মাইএসকিউএল সার্ভারকে ভেরিয়েবল সিঙ্ক_মাস্টার_ইনফো সেট আপ করে প্রতিটি ইভেন্টের পরে মাস্টার.info সিঙ্ক করতে বলতে পারেন তবে এতে সম্ভবত এর বিশাল কার্যকারিতা হবে।