তথ্য
আপনি বলেছেন আপনি ব্যবহার করছেন ext4। ফাইলের আকারের সীমা 16TB। সুতরাং, Sample.ibdপূর্ণ হতে হবে না।
তুমি তোমার বললেন innodb_data_file_pathহয় ibdata1:10M:autoextend। সুতরাং, ইবদাতা 1 ফাইলটি নিজেই ওএস বাদে এর আকারের কোনও ক্যাপ নেই।
কেন এই বার্তাটি আসছে? লক্ষ্য করুন বার্তাটি "টেবিলে ... পূর্ণ", "ডিস্ক ... পূর্ণ নেই"। এই টেবিলের পূর্ণ শর্তটি একটি যৌক্তিক দৃষ্টিকোণ থেকে । ইনোডিবি সম্পর্কে চিন্তা করুন। কী ইন্টারঅ্যাকশন চলছে?
আমার অনুমান ইনোডিবি একক লেনদেন হিসাবে 93 জিবি ডেটা লোড করার চেষ্টা করছে। Table is Fullবার্তাটি কোথা থেকে প্রকাশিত হবে? আমি ইবদাটা 1-এর দিকে নজর দেব, এর দৈহিক আকারের দিক দিয়ে নয় (যা আপনি ইতিমধ্যে বাতিল করেছেন), তবে লেনদেনের সীমাটি কী পৌঁছেছে তার পরিপ্রেক্ষিতে।
ইনোডাব_ফিল_পিটার_সামগ্রী সক্ষম হয়ে থাকে এবং আপনি মাইএসকিউএলে নতুন ডেটা লোড করলে আইবডাটা 1-র ভিতরে কী থাকে ?
- তথ্য অভিধান
- ডাবল রাইট বাফার
- ডেটা দুর্নীতি রোধে সুরক্ষা নেট
- ক্যাচিংয়ের জন্য বাইপাস ওএসকে সহায়তা করে
- বাফারটি সন্নিবেশ করুন (দ্বিতীয় সূচকে স্ট্রিমলাইন পরিবর্তনগুলি)
- রোলব্যাক সেগমেন্টস
- লগগুলি পূর্বাবস্থায় ফেরান
- এর চিত্রগত উপস্থাপনা দেখতে এখানে ক্লিক করুন
ibdata1
আমার সন্দেহগুলি আমাকে বলে যে পূর্বাবস্থায় ফেরানো লগ এবং / অথবা পুনরায় লগ দোষারোপ করে।
এই লগ কি? বই অনুসারে
অধ্যায় 10: "স্টোরেজ ইঞ্জিনগুলি" পৃষ্ঠা 203 অনুচ্ছেদগুলি 4,4 নীচে বলে:
InnoDB ইঞ্জিন দুটি ধরণের লগ রাখে: একটি পূর্বাবস্থায় ফেরানো লগ এবং একটি পুনরায় লগ। পূর্বাবস্থায় ফেরানো লগের উদ্দেশ্য হ'ল লেনদেনকে রোল করা, পাশাপাশি লেনদেনের বিচ্ছিন্নতার স্তরে প্রয়োজনীয় কোয়েরিগুলির জন্য ডেটার পুরানো সংস্করণগুলি প্রদর্শন করা। পূর্বাবস্থায় লগ পরিচালনা করে এমন কোডটি স্টোরেজ / ইনানোবেস / বুফ / লগ / লগ লগ.লগ.তে পাওয়া যাবে ।
পুনরায় লগের উদ্দেশ্য হ'ল ক্র্যাশ পুনরুদ্ধারে ব্যবহৃত তথ্য সংরক্ষণ করা। এটি পুনরুদ্ধার প্রক্রিয়াটিকে ক্র্যাশের আগে সম্পন্ন বা নাও হতে পারে এমন লেনদেনগুলি পুনরায় কার্যকর করার অনুমতি দেয়। সেই লেনদেনগুলি পুনরায় কার্যকর করার পরে, ডাটাবেসগুলি একটি সামঞ্জস্যপূর্ণ অবস্থায় আনা হয়। রিডো লগের সাথে সম্পর্কিত কোডটি স্টোরেজ / ইনানোবেস / লগ / লগ0recv.c পাওয়া যাবে ।
বিশ্লেষণ
আইবডাটা 1 এর মধ্যে 1023 পূর্বাবস্থায় ফেরানো লগ রয়েছে (রোলব্যাক অংশগুলি এবং পূর্বে স্থানটি দেখুন) । যেহেতু পূর্বাবস্থায় ফেরানো লগগুলি ডেটাগুলির অনুলিপিগুলি পুনরায় লোডের আগে উপস্থিত হয়েছিল, তাই সমস্ত 1023 পূর্বাবস্থায় ফেরানো লগগুলি এর সীমাতে পৌঁছেছে। অন্য দৃষ্টিকোণ থেকে, সমস্ত 1023 পূর্বাবস্থায় ফেরানো লগগুলি Sampleসারণিটি লোড করে এমন এক লেনদেনে উত্সর্গ করা হতে পারে ।
কিন্তু অপেক্ষা করো...
আপনি সম্ভবত বলছেন "আমি একটি খালি Sampleটেবিল লোড করছি "। কীভাবে পূর্বাবস্থায় ফিরবেন জড়িত? Sampleটেবিলটি 93 গিগাবাইট ডেটা লোড করার আগে এটি খালি ছিল। অস্তিত্ব নেই এমন প্রতিটি সারি উপস্থাপনের জন্য অবশ্যই পূর্বাবস্থায় ফেরানো লগগুলিতে কিছু গৃহসজ্জার জায়গা নেওয়া উচিত। 1023 পূর্বাবস্থায় ফেরত লগগুলি পূরণ করা ডেটা pourালার পরিমাণের ভিত্তিতে তুচ্ছ মনে হয় ibdata1। আমি সন্দেহ করা প্রথম ব্যক্তি নই:
মাইএসকিউএল ৪.১ ডকুমেন্টেশন থেকে নোট করুন Posted by Chris Calender on September 4 2009 4:25pm:
নোট করুন যে 5.0 (প্রাক-5.0.85) এবং 5.1 (প্রাক-5.1.38) এ, আপনি ইনোডিবি টেবিলের জন্য "টেবিল পূর্ণ" ত্রুটিটি পেতে পারেন যদি ইনোডিবি পূর্বাবস্থা স্লটগুলির বাইরে চলে যায় (বাগ # 18828)।
মাইএসকিউএল 5.0 এর জন্য বাগ প্রতিবেদনটি এখানে রয়েছে: http://bugs.mysql.com/bug.php?id=18828
পরামর্শ
আপনি যখন Sampleটেবিলের মাইএসকিএলডাম্প তৈরি করবেন , দয়া করে - নন-অটোকমমিট ব্যবহার করুন
mysqldump --no-autocommit ... mydb Sample > Sample.sql
এটি COMMIT;প্রতিটি পরে একটি স্পষ্ট করা হবে INSERT। তারপরে, টেবিলটি পুনরায় লোড করুন।
যদি এটি কাজ না করে ( আপনি এটি পছন্দ করেন না ), এটি করুন
mysqldump --no-autocommit --skip-extended-insert ... mydb Sample > Sample.sql
এটি প্রতিটি INSERT এর মাত্র একটি সারি তৈরি করবে। Mysqldump আরও বড় হবে (10+ গুণ বেশি) এবং পুনরায় লোড করতে 10 থেকে 100 গুণ বেশি সময় নিতে পারে।
উভয় ক্ষেত্রেই, এটি পূর্বাবস্থায়িত লগগুলি ডুবে যাওয়া থেকে বাঁচায়।
একবার চেষ্টা করে দেখো !!!
আপডেট 2013-06-03 13:05 ইডিটি
অতিরিক্ত পরামর্শ IT
যদি InnoDB সিস্টেম টেবিল (ওরফে ibdata1) একটি ফাইল আকার সীমাতে আঘাত করে এবং পূর্বে লোগগুলি ব্যবহার করা যায় না, আপনি কেবল অন্য একটি সিস্টেমের টেবিল স্পেস (আইবিডাটা 2) যুক্ত করতে পারেন।
মাত্র দুদিন আগে আমি এই পরিস্থিতির মুখোমুখি হয়েছি। আমি আমার পুরানো পোস্টটি যা করেছি তা দিয়ে আপডেট করেছি: ডাটাবেস ডিজাইন দেখুন - টেবিলের আকারের সীমাবদ্ধতার মাথাব্যথা এড়াতে একাধিক ডাটাবেস তৈরি করা
সংক্ষেপে, একটি নতুন সিস্টেমের টেবিল স্পেস ফাইলের জন্য আপনাকে ইনোডাব_ডাটা_ফিল_পথটি পরিবর্তন করতে হবে। আমাকে কীভাবে ব্যাখ্যা করুন:
দৃশ্যকল্প
ডিস্কে (Ext3), আমার ক্লায়েন্টের সার্ভারে নিম্নলিখিতগুলি ছিল:
[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql 362807296 Jun 2 00:15 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun 2 00:15 ibdata2
সেটিং ছিল
innodb_data_file_path=ibdata1:346M;ibdata2:500M:autoextend:max:10240000M
দ্রষ্টব্য যেটি ibdata22196875759616 এ বেড়েছে 2145386484M।
আমাকে ibdata2ইনোডাব_ডাটা_ফিল_পথে ফাইল সাইজ এম্বেড করে যুক্ত করতে হয়েছিলibdata3
innodb_data_file_path=ibdata1:346M;ibdata2:2196875759616;ibdata3:10M:autoextend
আমি যখন মাইএসকিএলডি পুনরায় চালু করলাম তখন এটি কাজ করেছিল:
[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql 362807296 Jun 3 17:02 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun 3 17:02 ibdata2
-rw-rw---- 1 s-em7-mysql s-em7-mysql 32315015168 Jun 3 17:02 ibdata3
40 ঘন্টা, ibdata331G এ বেড়েছে। মাইএসকিউএল আবার কাজ করছিল।