شما اینجایید
خانه > آموزش > انعطاف‌پذیری بیشتر مدیریت Undo Tablespace در MySQL 8.0.2

انعطاف‌پذیری بیشتر مدیریت Undo Tablespace در MySQL 8.0.2

ویژگی‌هایی از DMR  MySQL 8.0.2 را معرفی می‌کنیم که مدیریت undo tablespace را در InnoDB آسان‌تر می‌کنند.

بخش اصلی ارتقایی که صورت گرفته این است که می‌توانید undo tablespace-ها را در هرموقع بسازید و مستقر کنید. می‌توانید فایل config را تغییر بدهید و قبل از هر راه‌اندازی (startup)، تعیین کنید که آیا به بازیابی (recovery) نیاز است یا خیر.

innodb_undo_tablespaces

undo tablespace-ها دربردارندۀ Rollback Segment-ها هستند که آن‌ها  نیز undo log-ها را دربردارند. undo log-ها برای ‘roll back’ یا «عقب‌گرد» تراکنش‌ها و ایجاد نسخه‌های اولیۀ داده‌هایی استفاده می‌شود که Multi Version Concurrency Control (کنترل هم‌زمانی چندنسخه‌ای) از آن‌ها برای ارائۀ یک نمای منسجم از پایگاه‌داده درطی یک تراکنش استفاده می‌کند.

قبلاً تعداد undo tablespace-هایی که InnoDB به‌کار می‌گرفت هنگام آماده‌سازی پایگاه‌داده (initialization) تعیین می‌شد. اکنون می‌توان به آن، هرموقع، مقداری بین ۰ تا ۱۲۷ داد؛ چه هنگام راه‌اندازی در فایل config یا در خط فرمان (command line)، یا به‌طور آنلاین با تعیین ‘SET GLOBAL INNODB_UNDO_TABLESPACES=n’.

وقتی که undo tablespace-های صفر را انتخاب می‌کنید، system tablespace تمام rollback segment -ها را دنبال می‌کند. این شیوۀ قدیمی ذخیرۀ  system tablespace قبل از اضافه شدن undo tablespace-های مجزا به نسخۀ ۵.۶ است. به‌این‌ترتیب تلاش می‌کنیم که از این نحوۀ استفاده از system tablespace فاصله بگیریم تا مقدار پیش‌فرض برابر ۲ قرار نگیرد. در آیندۀ نزدیک مقدار کمینه برابر ۲ خواهد بود که به این معناست که system tablespace برای هیچ rollback segment-ئی استفاده نخواهد شد. پس لطفاً در فایل‌های config خود قرار ندهید: innodb_undo_tablespaces=0.

innodb_undo_log_truncate

 مقدار کمینۀ ۲ را برای undo tablespace-ها انتخاب کردیم زیرا برای اینکه حداقل یکی از آن‌ها کوتاه‌سازی شود (truncate)، حداقل به ۲ نیاز داریم. Undo truncation به InnoDB این امکان را می‌دهد که اندازۀ undo tablespace را بعد از تراکنش‌هایی که بزرگیِ غیرعادی دارند، کوچک‌سازی کند. پیش‌ازاین تنظیماتinnodb_undo_log_truncate  به‌طور پیش‌فرض OFF قرار داده می‌شد. در نسخۀ ۸.۰.۲  به‌طور پیش‌فرض ON قرار داده می‌شود.

innodb_rollback_segments

می‌توان، هرموقع در راه‌اندازی چه در فایل config  و چه از خط فرمان (command line) و چه به‌طور آنلاین با تعیین ‘SET GLOBAL INNODB_ROLLBACK_SEGMENTS=n’، به آن مقداری بین ۱ تا ۱۲۸ داد.

این تنظیمات قبلاً برابر تعدادrollback segment -هایی بود که کل سِرور می‌توانست پشتیبانی کند. اکنون برابر تعدادrollback segment-ها در هر undo tablespace است و ازاین‌رو تراکنش‌های هم‌زمان از rollback segment-های بیشتری استفاده می‌کنند. مقدار پیش‌فرض هنوز ۱۲۸ است.

innodb_undo_logs

این تنظیمات در ۵.۶، به‌عنوان یک جایگزین یا با نام مستعار innodb_rollback_segments معرفی شد. ازلحاظ لغتی گیج‌کننده بود زیرا در InnoDB، Undo Log-ها در Rollback Segment-ها ذخیره می‌شدند که file segment-های یک Undo Tablespace هستند. در v8.0.2 استفاده از این تنظیمات را کنار می‌گذاریم و به‌جای آن لازم است که از Innodb_rollback_segments استفاده کنیم. آخرین نسخۀ عرضه‌شدۀ ۵.۷.۱۹  هشدارهایی مبنی بر منسوخ شدن آن دارد.

Undo Tablespace Name and Location

undo tablespace-ها در مسیری (دایرکتوری‌ای) که با تنظیم innodb_undo_directory تعیین می‌شود قرار دارد. اگر از این تنظیمات استفاده نشود، در محل ‘datadir’ ایجاد می‌شوند. قبلاً اسم‌هایی مثل ‘undo001’ یا ‘undo002’ و غیره داشتند. در v8.0.2 DMR اسم‌هایی مثل undo_001 و undo_002 و غیره دارند. علت تغییر اسم این است که این undo tablespace-های جدیدتر یک صفحۀ سرایند (هدر) جدید دارند که محل‌هایی را که هر rollback segment دارد نگاشت می‌کند. در نسخۀ ۵.۶ وقتی که undo tablespace-های مجزا ارائه شدند، تعداد صفحات سرآیندِ (هدرِ) rollback segment ِآن‌ها در system tablespace پیگیری شدند که تعداد rollback segment-ها را برای کل نمونه (instance) به ۱۲۸ محدود کرد.

به دلیل اینکه هر undo tablespace می‌تواند rollback segment-های خودش را با این صفحۀ جدید پیگیری کند، واقعاً انواع جدیدی از undo tablespace-ها محسوب می‌شوند که باید مقررات نام‌دهی متفاوتی داشته باشند. به این دلیل است که اکنون innodb_rollback_segments ، به‌جای تعداد کل نمونۀ MySQL، تعداد rollback segment-ها را برای هر undo tablespace تعریف می‌کند.

Automatic Upgrade

 قبل از این تغییر، system tablespace تمام rollback segment-ها را پیگیری می‌کرد، چه در system tablespace و چه در undo tablespace-ها. اگر MySQL 8.0.2 را بر پایگاه‌دادۀ موجود که از system tablespace برای پیگیری rollback segment-ها استفاده می‌کند راه‌اندازی کرده باشید، حداقل دو undo tablespace ِجدید به‌طور خودکار تولید می‌شوند. این کار رایج خواهد شد زیرا مقدار پیش‌فرض قبلی برای innodb_undo_tablespaces برابر ۰ بود. پایگاه‌داده‌های MySQL 5.7 متحمل یک روند به‌روزرسانی می‌شوند که DD ِجدید را از فایل‌های قدیمی FRM می‌سازد. بخشی از این فرایند ایجاد حداقل دو undo tablespace ِجدید است. InnoDB همچنان می‌تواند از rollback segment-های موجود و undo tablespace-های تعریف‌شده در system tablespace استفاده کند، اگر هنگام راه‌اندازی در خودشان undo log-ها را داشته باشند. اما این کار rollback segment-های قدیمی را برای هیچ‌کدام از تراکنش‌های جدید تعیین نخواهد کرد.  بنابراین وقتی  undo recovery (دوباره‌کاری بازیابی) تمام شد، و دیگر به این undo log-ها نیاز نبود، undo tablespace-های قدیمی حذف می‌شوند.

پاسخ دهید

بالا