InnoDB টেবিল থেকে স্থান মুছে ফেলা এবং দাবি দাবি করা

Question

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

রোল্যান্ডোমাইএসকিউএলডিবিএ সম্পাদনা করুন

আপনার টেবিলটি ধরে নিচ্ছেন mydb.mytable, দয়া করে নীচের ক্যোয়ারীটি চালান এবং এটি এখানে পোস্ট করুন যাতে আপনি টেবিলের সঙ্কুচিত হওয়ার জন্য প্রয়োজনীয় ডিস্কস্পেস নির্ধারণ করতে পারেন:

SELECT
    FORMAT(dat/POWER(1024,3),2) datsize,
    FORMAT(ndx/POWER(1024,3),2) ndxsize,
    FORMAT((dat+ndx)/POWER(1024,3),2) tblsize
FROM (SELECT data_length dat,index_length ndx
FROM information_schema.tables WHERE
table_schema='mydb' AND table_name='mytable') A;

আমাদের যদি অনুমতি দেওয়া হয় সারণী কাঠামোও দেখতে হবে।

নোম সম্পাদনা করুন

এটি কোয়েরির আউটপুট:

datsize ndxsize tblsize
682.51 47.57 730.08

এটি টেবিল কাঠামো ( SHOW CREATE TABLE)

`CREATE TABLE `mybigtable` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `uid` int(11) NOT NULL,  
  `created_at` datetime NOT NULL,  
  `tid` bigint(20) NOT NULL,  
  `text` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, 
  `ft` tinyint(1) NOT NULL,  
  `irtsd` bigint(20) NOT NULL,  
  `irtuid` int(11) NOT NULL,  
  `rc` int(11) NOT NULL,  
  `r` tinyint(1) NOT NULL,  
  `e` text CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,  `timezone` varchar(5) NOT NULL,  PRIMARY KEY (`id`),  UNIQUE KEY `uid_tid` (`uid`,`tid`)) ENGINE=InnoDB AUTO_INCREMENT=2006963844 DEFAULT CHARSET=utf8`

Comments

কেবলমাত্র ডেটা ধরতে আপনার কি অন্য ডিস্ক ভলিউম আছে ???

— রোল্যান্ডোমাইএসকিউএলডিবিএ 21

@ রোল্যান্ডোমাইএসকিউএলডিবিএ আমার একটি বাহ্যিক হার্ড-ড্রাইভ রয়েছে যা আমি মাউন্ট করতে পারি। সেটা কি হিসাবের মধ্যে আসে?

— নওম

@ রোল্যান্ডোমাইএসকিউএলডিবিএ তবে অবশ্যই অন্য একটি 700 জিবি প্রয়োজন ছাড়াই কিছু জায়গা মুছে ফেলার বিকল্পটির মত হবে

— নোম

@ রোল্যান্ডোমাইএসকিউএলডিবিএ অতিরিক্ত ডিস্ক আকারের কারণে কোনও পারফরম্যান্সের সমস্যা সৃষ্টি করে?

— এরিস

@ এরিস এটি ডিস্ক এবং তার সন্ধানের সময়ের উপর নির্ভর করে। এই দিনগুলিতে, বেশিরভাগ ডিস্কগুলি এখন আরও ভাল পারফর্ম করে তবে আপনার টেবিলে ডিস্কস্পেসের বড় বড় পকেট থাকলে আপনার চক্রগুলি (এমনকি সত্যই দ্রুত চলছে) নষ্ট করা ভাল good এটি InnoDB- র ক্ষেত্রে বিশেষত সত্য যা সাধারণত 16 কে ব্লকে স্থির থাকে। 16 কে ব্লকের অভ্যন্তরীণ বিভাজন সহ, আপনি টেবিলটি ডিফ্র্যাগমেন্ট করতে চাইতে পারেন ALTER TABLE ... ENGINE=InnoDB;(যদি আপনি এটির জন্য ঘর পেয়ে থাকেন)। বেশিরভাগই তাদের খুব দ্রুত এসএসডি নিয়ে সন্তুষ্ট এবং আর উদ্বিগ্ন হবেন না।

— রোল্যান্ডোমাইএসকিউএলডিবিএ

Answer 1

এটা একটা ভালো প্রশ্ন। আপনার বেশ কয়েকটি সমাধান রয়েছে তবে আপনার টেবিলটি বেশ বড় তাই কোনও ব্যথা ছাড়াই হবে না :)

InnoDB টেবিলগুলি "সঙ্কুচিত" করার জন্য আপনার কাছে তিনটি সমাধান রয়েছে:

1. টেবিলটি অপ্টিমাইজ করুন

আপনি OPTIMIZE TABLEযেমন উল্লেখ করেছেন তেমন ব্যবহার করতে পারেন তবে আপনার innodb_file_per_tableপরিবর্তনশীল সম্পর্কে যত্ন নেওয়া উচিত :

mysql> show variables like "innodb_file_per_table";
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_file_per_table | ON    |
+-----------------------+-------+
1 row in set (0.00 sec)

আমাকে ব্যাখ্যা করতে দাও:

OPTIMIZE TABLEসাথে থাক InnoDB টেবিল, টেবিল লক, একটি নতুন পরিচ্ছন্ন সারণী (যে কেন ফলাফলের shrinked হয়), মূল টেবিল ড্রপ এবং মূল নামের সঙ্গে নতুন টেবিল নামান্তর ডাটা কপি করুন। এজন্য আপনার ডিস্কে আপনার টেবিলের ভলিউম্যাট্রি দ্বিগুণ থাকার যত্ন নেওয়া উচিত (অপারেশনের সময় আপনার 2x700 গিগাবাইট প্রয়োজন হবে)।

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

আপনি যখন ইনোডাব_ফাইলে_পার_সেবিকা = বন্ধ থাকবেন। সমস্ত ডেটা এক ডেটা ফাইলে যায়: ইবদাটা । এই ফাইলটির একটি দু: খপূর্ণ বৈশিষ্ট্য রয়েছে, এটি সঙ্কুচিত করা যায় না। OPTIMIZEপ্রক্রিয়া চলাকালীন , আপনার নতুন টেবিলটি তৈরি করা হবে (GB০০ গিগাবাইটের কাছাকাছি), তবে ড্রপ এবং পুনর্নামকরণ অপারেশন (এবং OPTIMIZEপর্বের সমাপ্তির ) পরেও আপনার ইবদাটা GB 700 গিগাবাইট প্রকাশ করবে না, তাই আপনি কিছু তথ্য নিখরচায় চেয়েছিলেন তবে আপনার কাছে 700 গিগাবাইট রয়েছে আরও, দুর্দান্ত তাই না?

টেবিল পরিবর্তন করুন

আপনি একটি ALTER TABLEবিবৃতিও ব্যবহার করতে পারেন , ALTER TABLEঠিক একইভাবে কাজ করবে OPTIMIZE TABLE। আপনি কেবল ব্যবহার করতে পারেন:

ALTER TABLE myTable EGINE=InnoDB;

৩. টেস্টের বিকল্প (অনলাইন)

অপারেশন চলাকালীন সমস্যাটি OPTIMIZEএবং ALTER TABLEএটি টেবিলটি লক করে। আপনি পারকোনা সরঞ্জামটি ব্যবহার করতে পারেন: পিটি-অনলাইন-স্কিমা-পরিবর্তন (পারকোনা টুলকিট থেকে: লিঙ্ক )। পিটি-অনলাইন-স্কিমা ... ট্রিগার এবং টেম্প টেবিল সহ একটি মেকানিজম তৈরি করবে যা আপনি অপারেশন চলাকালীন পড়ার জন্য এবং লেখার জন্য মূল সারণিকে উপলব্ধ হওয়ার অনুমতি দেন। আমি উত্পাদনে এই সরঞ্জামটি বড় হিসাবে ALTERএটি দুর্দান্ত।

মনে রাখবেন যে FOREIGN KEYআপনার টেবিল, এফকে এবং আপনার কাছে কোনও জগাখিচুড়ি তৈরির ঝুঁকির কারণ উল্লেখ করা উচিত । এই পূর্বশর্তগুলি পরীক্ষা করতে, ক্যোয়ারী:

mysql> SELECT COUNT(*) FROM information_schema.REFERENTIAL_CONSTRAINTS WHERE REFERENCED_TABLE_NAME = "myTable";
+----------+
| COUNT(*) |
+----------+
|        0 |
+----------+
1 row in set (0.04 sec)

এখানে আমি কীভাবে পিটি-অনলাইন-স্কিমা-পরিবর্তন ব্যবহার করি:

pt-online-schema-change --alter "ENGINE=InnoDB" D=myBase,t=myTable --user --ask-pass

নোট করুন যে ইনোডাব_ফিল_পিটার_ট্যাবেলে আমার নোটটিও এই সমাধানের জন্য সত্য।

4. মাইএসকিএলডম্প

শেষ সমাধানটি হ'ল ডাম্প থেকে সমস্ত ডাটাবেস পুনরায় তৈরি করা। ভয়ানকভাবে দীর্ঘ, তবে অত্যন্ত দক্ষ। মনে রাখবেন যে ইবদাটা ফাইলটি "সঙ্কুচিত" করার একমাত্র সমাধান।

সর্বোচ্চ।

Comments

এছাড়াও পারকোনার সরঞ্জামে অনলাইনে পরিবর্তন সারণী বিকল্পে আমার 700 গিগাবাইট ফ্রি ডিস্ক স্থানের প্রয়োজন হবে?

— নোম

হ্যাঁ, পিটি-অনলাইন কেবলমাত্র ALTER অনলাইনে করার জন্য কিছু মেকানিজম ব্যবহার করে তবে এটি যেভাবেই হোক না কেন একটি বিকল্প তৈরি করে।

— ম্যাক্সিমাম ফিউইলুল

@ ম্যাক্সিমফিউইলুল অতিরিক্ত ডিস্ক আকারের কারণে কোনও পারফরম্যান্সের সমস্যা দেখা দেয়?

— এরিস

Answer 2

আপনি যদি ডিস্ক আকারে সংক্ষিপ্ত হন তবে আমি আপনাকে পরামর্শ দিচ্ছি যে আপনি সর্বোচ্চভাবে পিটি-অনলাইন-স্কিমা-পরিবর্তন (অনলাইন) এর পরামর্শ দিয়েছেন do আমি অনেক ছোট টেবিল (200 গিগাবাইট) নিয়ে একই পরিস্থিতিতে রয়েছি এবং একই সাথে কিছু সংকোচনের জন্য বেছে নিয়েছি। এর লাইন ধরে কিছু কাজ করা উচিত:

pt-online-schema-change --alter="ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4" D=myBase,t=myTable --user --ask-pass

এটি কেবল তখনই কাজ করবে যদি আপনি ব্যারাকুডা ফাইল ফর্ম্যাট এবং টেবিলের সংযোগ বিন্যাসে থাকেন। এছাড়াও আপনার অবশ্যই ইনোডাব_ফিল_পিটার_সামগ্রী সক্ষম থাকতে হবে। এটি আপনার টেবিলের আকারে বিস্ময়কর কাজ করতে পারে বিশেষত যদি খুব বেশি পাঠ্য থাকে এবং আপনি যদি ছোট KEY_BLOCK_SIZE যেমন 8K বা 4K (ডিফল্টটি 16 কে হয়) ব্যবহার করেন। অন্যান্য ব্লগে এই সমস্যা সম্পর্কিত একাধিক মানদণ্ড থেকে আপনি কতটা স্থান অর্জন করতে পারবেন তাও পরীক্ষা করতে পারেন তবে মাইএসকিউএল ডকুমেন্টেশন 25% থেকে 50% বিজ্ঞাপন দেয় (এটি আমার জন্য প্রায় 90% ছিল) was

নোট করুন যে এটি নির্বাচন করার সময়ও পারফরম্যান্সকে প্রভাবিত করতে পারে (মাইএসকিউএল ডকুমেন্টেশন থেকে):

সুতরাং, যে কোনও সময়, বাফার পুলটিতে পৃষ্ঠার সংকুচিত এবং সঙ্কুচিত উভয় ফর্ম থাকতে পারে, বা কেবল পৃষ্ঠার সংকুচিত ফর্ম, বা নাও থাকতে পারে।

মাইএসকিউএল-কে বাফার পুলে না থাকলে ডেটা সঙ্কুচিত করতে হবে। সুতরাং সতর্ক করা উচিত।

এটি আমার ক্ষেত্রে সত্যই কাজ করেছে। আমার একটি দীর্ঘ পাঠ্য ছিল 200 গিগাবাইট হয়ে উঠেছে 26 জিবি। পারফরম্যান্স পরিবর্তন করা হয়নি।

গভীরতার তথ্যের আরও তথ্যের জন্য এই লিঙ্কগুলি পরীক্ষা করুন:

https://dev.mysql.com/doc/refman/5.5/en/innodb-compression-usage.html

https://dev.mysql.com/doc/refman/5.5/en/innodb-compression-internals.html