10

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

যাইহোক, আমি গত রাতে নিম্নলিখিত পরিস্থিতিটি ধরেছি:

সম্পূর্ণ প্রক্রিয়া তালিকা প্রদর্শন থেকে অংশ:

যারা শত শত ...

   Command: Query
   Time: 291
   State: Waiting for table flush
   Info: insert into db_external_notification.....

তারপর এই:

Command: Query
Time: 1204
State: Sending data
Info: SELECT /*!40001 SQL_NO_CACHE */ * FROM `db_external_notification`

এবং বাকি থ্রেডগুলি ঘুমের মধ্যে রয়েছে

কারও কি ধারণা আছে যে এই সন্নিবেশগুলি কীসের জন্য অপেক্ষা করছে? আমি কোনও FLUSH টেবিল বা ডিডিএল বা ম্যানুয়ালটিতে উল্লিখিত এমন কোনও কিছুই দেখতে পাচ্ছি না যা প্রশ্নের জন্য অপেক্ষা করতে পারে।

সম্পূর্ণ mysqldump কমান্ড

mysqldump --quick --add-drop-table --single-transaction --master-data=2 -uxx -pxx dbname

আমি অনুমান করি - এখানে এখানে দ্রুত কাজ করা সম্ভব নয়, সম্ভবত পূর্ববর্তী কাল থেকে একটি অবশিষ্টাংশ, এই স্ক্রিপ্টটি খুব পুরানো, তবে কাউকে আঘাত করা উচিত নয়

— আলেকসান্দার ইভানিসেভিক
সূত্র

শো পুরো প্রক্রিয়া তালিকা এবং শো ইনোডাব স্থিতির সম্পূর্ণ আউটপুট (নাম প্রকাশিত নয়) এখানে রয়েছে: পেস্টবিন.

— আলেকজান্ডার ইভানিসেভিক

আপনার সম্পূর্ণ কমান্ড লাইন কি জন্য mysqldump? বিশেষত, আপনি ব্যবহার করছেন --flush-logsবা --master-data...? বিকল্পগুলির মধ্যে সম্ভাব্য ইন্টারঅ্যাকশন রয়েছে।

— মাইকেল -

পূর্ণ মাইসকিলডাম্প কমান্ড যুক্ত হয়েছে, দেখার জন্য ধন্যবাদ

— আলেকসান্দার ইভানিসেভিক

6

--Single-লেনদেন করার বিকল্প mysqldump করে না FLUSH TABLES WITH READ LOCK;। এটি সমস্ত টেবিলগুলি ডাম্প করার জন্য পুনরাবৃত্তযোগ্য পঠন লেনদেন সেটআপ করার জন্য মাইএসকিএলডাম্প তৈরি করে।

আপনার প্রশ্ন থেকে, আপনি বলেছিলেন যে db_external_notificationটেবিলের জন্য মাইএসকিল্ডাম্পের SELECT একই টেবিলে কয়েকশ INSERT কমান্ড ধরে রেখেছে। ইহা কি জন্য ঘটিতেছে ?

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

আপনার এটি চালিয়ে স্পর্শ করতে সক্ষম হওয়া উচিত SHOW ENGINE INNODB STATUS\Gএবং জেন_ক্লাস্ট_আইডেক্সের যে কোনও পৃষ্ঠাতে একচেটিয়া লক রয়েছে তা সন্ধান করতে হবে। ক্লাস্টারড ইনডেক্সের সাথে একটি টেবিলের মধ্যে INSERTs করার জন্য প্রাইমারি কী এর বিটিআরই পরিচালনা করার জন্য একটি অসাধারণ লক প্রয়োজন, পাশাপাশি অটো_সংশোধনের সিরিয়ালকরণ ization

আমি আগে এই ঘটনাটি নিয়ে আলোচনা করেছি

আপডেট 2014-07-21 15:03 ইডিটি

আপনার পাস্তবিনের 614-617 লাইনগুলি দেখুন

mysql tables in use 1, locked 0
MySQL thread id 6155315, OS thread handle 0x85f11b70, query id 367774810 localhost root Sending data
SELECT /*!40001 SQL_NO_CACHE */ * FROM `db_external_notification`
Trx read view will not see trx with id >= 1252538405, sees < 1252538391

নোট করুন যে লাইন 617 বলেছেন

Trx read view will not see trx with id >= 1252538405, sees < 1252538391

এটি আমাকে কী বলে? আপনার অটো_সন্ট্রিমেন্ট সহ কিছু প্রাথমিক কী আছে id।

idটেবিলের জন্য আপনার সর্বোচ্চটি যখন মাইএসকিএলডাম চালু হয়েছিল তখন db_external_notificationতার চেয়ে কম 1252538391ছিল। আপনি যখন 1252538391থেকে বিয়োগ করেন 1252538405, এর অর্থ 14 বা ততোধিক INSERT কমান্ড চেষ্টা করা হয়েছে। অভ্যন্তরীণভাবে, এই টেবিলটির স্বতঃআগ্রহটি কমপক্ষে 14 বার স্থানান্তরিত করতে হবে। তবুও, এই idফাঁকটি পরিচালনা করার কারণে কোনও কিছুই লগ বাফারে প্রতিশ্রুতিবদ্ধ বা এমনকি ধাক্কা দেওয়া যায় না ।

এখন, আপনার পেস্টবিন থেকে প্রসেসলিস্টটি দেখুন। আমি যদি ভুল হিসাব না করে, 38 ডিবি সংযোগগুলি একটি INSERT করছে (19 টি mysqldump প্রক্রিয়া করার আগে (প্রক্রিয়া ID 6155315), 19 পরে)। আমি নিশ্চিত যে 14 বা ততোধিক সংযোগগুলি অটো_সংশোধন ব্যবধানটি পরিচালনা করার কারণে হিমশীতল।

— RolandoMySQLDBA
সূত্র

আমি দীর্ঘ সময় খুঁজছিলাম এবং কোনও এক্সক্লুসিভ লক খুঁজে পাইনি। আমি পেস্টবিন. com/ ডি 7 ডাব্লু এস 3 কিএই-তে পুরো শো ইনোডাব স্ট্যাটাসটি পেস্ট করেছি , আমার কাছে কোনও কিছুর উপর একচেটিয়া লকের মতো কিছুই মনে হচ্ছে না

— আলেকসান্দার ইভানিসেভিক

স্পষ্টতার জন্য ধন্যবাদ। আমি ভাবছি কেন তারা কেবল পঠনযোগ্য লেনদেন ব্যবহার করবেন না কারণ এটি পরিষ্কার যে ব্যাকআপ কখনও লিখবে না, তবে আমি অনুমান করছি যে তারা তাদের বৈশিষ্ট্যটি তাদের এন্টারপ্রাইজ ব্যাকআপের জন্য রাখছে।

— আলেকসান্দার ইভানিসেভিক

10

--single-transactionবিকল্প mysqldump আছে একটি FLUSH TABLES WITH READ LOCKব্যাকআপ কাজ শুরু করার পূর্বে কিন্তু শুধুমাত্র কিছু অবস্থার অধীনে। এই বিকল্পগুলির মধ্যে একটি হ'ল আপনি যখন --master-dataবিকল্পটিও নির্দিষ্ট করেন ।

mysql-5.6.19/client/mysqldump.c5797 লাইনে সোর্স কোডে :

if ((opt_lock_all_tables || opt_master_data ||
     (opt_single_transaction && flush_logs)) &&
    do_flush_tables_read_lock(mysql))
  goto err;

পুনরাবৃত্তযোগ্য-পঠন লেনদেন শুরু করার আগে সুনির্দিষ্ট বিনলগ স্থানাঙ্কের উপর একটি দৃ lock় লক পাওয়ার জন্য, --master-dataবিকল্পটি এই লকটি পাওয়ার জন্য ট্রিগার করে এবং তারপরে বিনলগের স্থানাঙ্কগুলি পাওয়ার পরে মুক্তি দেওয়া হয়।

আসলে, mysqldumpএকটি FLUSH TABLESঅনুসরণ করে FLUSH TABLES WITH READ LOCKকারণ দুটি জিনিসই প্রাথমিক প্রবাহে কিছুটা সময় নেয় এমন ক্ষেত্রে রিড লকটি দ্রুত পাওয়া যায়।

...যাহোক...

এটি বিনলগ স্থানাঙ্কগুলি পাওয়ার সাথে সাথেই mysqldumpএকটি UNLOCK TABLESবিবৃতি জারি করে , সুতরাং আপনি যে ফ্লাশ শুরু করেছিলেন তার ফলস্বরূপ কোনও অবরুদ্ধ হওয়া উচিত নয়। উভয়ই থ্রেড হ'ল Waiting for table flushলেনদেনের ফলস্বরূপ হওয়া উচিত নয় mysqldump।

আপনি যখন Waiting for table flushরাজ্যে কোনও থ্রেড দেখেন , তার অর্থ এই হওয়া উচিত যে FLUSH TABLES [WITH READ LOCK]বিবৃতিটি জারি করা হয়েছিল এবং ক্যোয়ারি শুরু হওয়ার পরে এখনও চলছে - সুতরাং ক্যোয়ারিকে কার্যকর করার আগে টেবিল ফ্লাশের জন্য অপেক্ষা করতে হবে। আপনার পোস্ট করা প্রসেসলিস্টের ক্ষেত্রে, mysqldumpএই একই টেবিলটি থেকে পড়া হচ্ছে এবং কোয়েরিটি কিছুক্ষণ চলছিল, তবুও ব্লক করা অনুসন্ধানগুলি এত দিন ধরে অবরুদ্ধ ছিল না।

এগুলি থেকে বোঝা যায় যে অন্য কিছু ঘটেছে।

অভ্যন্তরীণভাবে কাজ করার উপায়টি বাগ # 44884 -এ একটি দীর্ঘস্থায়ী সমস্যা রয়েছে FLUSH TABLES। ~~সমস্যাটি যদি এখনও অব্যাহত থাকে তবে~~ আমি অবাক হব না, এই সমস্যাটি যদি কখনও "স্থির" হয় তবে আমি অবাক হব কারণ এটি সমাধান করা খুব জটিল সমস্যা - উচ্চতর সংমিশ্রিত পরিবেশে সত্যিকার অর্থে সমাধান করা কার্যত অসম্ভব - এবং যে কোনও প্রচেষ্টা এটিকে ঠিক করে তোলা অন্য কিছু ভাঙার, বা নতুন, আলাদা এবং এখনও অনাকাঙ্ক্ষিত, আচরণ তৈরির তাৎপর্যপূর্ণ ঝুঁকি বহন করে।

মনে হচ্ছে এটি আপনি যা দেখছেন তার ব্যাখ্যা হবে।

বিশেষ করে:

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

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

পরবর্তী সময়ে কোনও অজানা প্রক্রিয়া দ্বারা এই জিজ্ঞাসাটি হত্যা করা হয়েছিল বা সময়সীমা নির্ধারণ করা হয়েছিল, তবে এর প্রতিক্রিয়াগুলি প্রশ্নযুক্ত mysqldumpটেবিল থেকে পড়া শেষ না হওয়া পর্যন্ত দীর্ঘস্থায়ী ছিল ।

FLUSH TABLESদীর্ঘ-চলমান ক্যোয়ারী প্রক্রিয়া চলাকালীন চেষ্টা করে আপনি এই অবস্থার প্রতিলিপি করতে পারেন । তারপরে আর একটি ক্যোয়ারী শুরু করুন, যা ব্লক হয়ে যাবে। তারপরে FLUSH TABLESক্যোয়ারীটি মেরে ফেলুন, এটি সর্বশেষ কোয়েরিটিকে অবরুদ্ধ করবে না। তারপরে প্রথম ক্যোয়ারীটি মেরে ফেলুন বা শেষ করুন এবং চূড়ান্ত ক্যোয়ারীটি সফলভাবে চলবে।

অনাগ্রহিত হিসাবে, এটি সম্পর্কিত নয়:

Trx read view will not see trx with id >= 1252538405, sees < 1252538391

এটি সাধারণ, কারণ mysqldump --single-transactionসমস্যাগুলি এ START TRANSACTION WITH CONSISTENT SNAPSHOT, যা ডাম্পের প্রক্রিয়া চলাকালীন পরিবর্তিত হওয়া ডেটা ডাম্পিং থেকে বাধা দেয়। এটি ছাড়া, শুরুতে প্রাপ্ত বিনলগ স্থানাঙ্কগুলি অর্থহীন হবে, যেহেতু --single-transactionএটি দাবি করবে না। এটি কোনওভাবেই Waiting for table flushসমস্যার সাথে সম্পর্কিত হওয়া উচিত নয় , কারণ এই লেনদেনটিতে স্পষ্টত কোনও লক থাকে না holds

— মাইকেল - sqlbot
সূত্র

এই উত্তরটি আসলে সঠিক।

— বোবান পি।

2

আমি একটি বৈশিষ্ট্য অনুরোধ জমা দিয়েছি: https://support.oracle.com/epmos/faces/BugDisplay?id=27103902 ।

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

--- mysql-5.6.37/client/mysqldump.c.bak 2017-11-14 12:24:41.846647514 -0600
+++ mysql-5.6.37/client/mysqldump.c 2017-11-14 14:17:51.187050091 -0600
@@ -4900,10 +4900,10 @@
   return 0;
 }

+/*
 static int do_stop_slave_sql(MYSQL *mysql_con)
 {
   MYSQL_RES *slave;
-  /* We need to check if the slave sql is running in the first place */
   if (mysql_query_with_error_report(mysql_con, &slave, "SHOW SLAVE STATUS"))
     return(1);
   else
@@ -4911,23 +4911,21 @@
     MYSQL_ROW row= mysql_fetch_row(slave);
     if (row && row[11])
     {
-      /* if SLAVE SQL is not running, we don't stop it */
       if (!strcmp(row[11],"No"))
       {
         mysql_free_result(slave);
-        /* Silently assume that they don't have the slave running */
         return(0);
       }
     }
   }
   mysql_free_result(slave);

-  /* now, stop slave if running */
   if (mysql_query_with_error_report(mysql_con, 0, "STOP SLAVE SQL_THREAD"))
     return(1);

   return(0);
 }
+*/

 static int add_stop_slave(void)
 {
@@ -5841,10 +5839,12 @@
   if (!path)
     write_header(md_result_file, *argv);

+  /*
   if (opt_slave_data && do_stop_slave_sql(mysql))
     goto err;
+  */

-  if ((opt_lock_all_tables || opt_master_data ||
+  if ((opt_lock_all_tables || opt_master_data || opt_slave_data ||
        (opt_single_transaction && flush_logs)) &&
       do_flush_tables_read_lock(mysql))
     goto err;
@@ -5853,7 +5853,7 @@
     Flush logs before starting transaction since
     this causes implicit commit starting mysql-5.5.
   */
-  if (opt_lock_all_tables || opt_master_data ||
+  if (opt_lock_all_tables || opt_master_data || opt_slave_data ||
       (opt_single_transaction && flush_logs) ||
       opt_delete_master_logs)
   {
 static int add_stop_slave(void)
 {
@@ -5841,10 +5839,12 @@
   if (!path)
     write_header(md_result_file, *argv);

+  /*
   if (opt_slave_data && do_stop_slave_sql(mysql))
     goto err;
+  */

-  if ((opt_lock_all_tables || opt_master_data ||
+  if ((opt_lock_all_tables || opt_master_data || opt_slave_data ||
        (opt_single_transaction && flush_logs)) &&
       do_flush_tables_read_lock(mysql))
     goto err;
@@ -5853,7 +5853,7 @@
     Flush logs before starting transaction since
     this causes implicit commit starting mysql-5.5.
   */
-  if (opt_lock_all_tables || opt_master_data ||
+  if (opt_lock_all_tables || opt_master_data || opt_slave_data ||
       (opt_single_transaction && flush_logs) ||
       opt_delete_master_logs)
   {

আমি এফকে সম্পর্কের সাথে প্রচুর ইনোডিবি টেবিল ব্যবহার করে খুব ব্যস্ত মাস্টারের কাছে দাসদের সাথে নিম্নলিখিত প্রক্রিয়াটি দিয়ে পরীক্ষা করেছি:

বন্ধ দাস এ।
15 মিনিট অপেক্ষা করুন।
স্লেভ বি থেকে ডিবি 1 ডাম্প বিকল্প - একসেল-লেনদেন এবং - ডাম্প-স্লেভ = 2 দিয়ে with
পদক্ষেপ 3 থেকে ডাম্পের স্থানাঙ্ক না হওয়া পর্যন্ত স্লেভ এ শুরু করুন।
গোলাম এ থেকে ডিবি 1 এবং 2 ফেলে দিন A.
গোলাম এ-তে খালি ডিবি 1 এবং 2 তৈরি করুন
তৃতীয় ধাপ থেকে দাস এ-তে লোড করুন
একই বিকল্পগুলির সাথে স্লেভ বি থেকে ডিবি 2 ডাম্প করুন। ডিবি 2 এর সাথে ডিবি 1 এর সাথে এফকে সম্পর্ক রয়েছে।
ডিবি 2 এর জন্য প্রতিলিপি_ইগনোর_ডিবি যুক্ত করুন এবং স্লেভ এ-তে স্কিপ_স্লেভ_স্টার্টটি যুক্ত করুন
পুনর্সূচনা স্লেভ এ।
দাস এ-এর 8 ম ধাপে ডাম্প থেকে স্থানাঙ্ক না হওয়া পর্যন্ত ক্রীতদাস শুরু করুন A.
আট ধাপ থেকে দাস এ-তে লোড করুন
দাস এ থেকে প্রতিলিপি_গিনোর_ডিবি এবং skip_slave_start বিকল্পগুলি সরান
পুনর্সূচনা স্লেভ এ।
~ 1 সপ্তাহ অপেক্ষা করুন।
ডেটা অখণ্ডতা যাচাই করতে পিটি-চেকসাম ব্যবহার করুন।

ওরাকল এর প্যাচ সাবম্যাটাল প্রক্রিয়া বরং নিবিড় তাই কেন আমি এই পথে চলেছি। এটি একীভূত করার জন্য আমি পারকোনা এবং / অথবা মারিয়াডিবি দিয়ে চেষ্টা করতে পারি।

— user44127
সূত্র

mysqldump --single- লেনদেন, তবুও আপডেট অনুসন্ধানগুলি ব্যাকআপের জন্য অপেক্ষা করছে

আপডেট 2014-07-21 15:03 ইডিটি