وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

خطای Unknown collation هنگام انتقال MySQL به MariaDB

خطای

انتشار:
توسط تیم فنی نت‌آرام
۵ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله خطای Unknown collation هنگام انتقال MySQL به MariaDB در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
اگر هنگام واردکردن فایل پایگاه داده پیام #1273 – Unknown collation می‌بینید، معمولاً فایل از نسخه‌ای از MySQL آمده که مقصد از آن collation پشتیبانی نمی‌کند. برای نمونه، نام utf8mb4_0900_ai_ci در برخی فایل‌های خروجی MySQL 8 دیده می‌شود و ممکن است در نسخه‌های قدیمی‌تر MariaDB شناخته نشود. این خطا به‌تنهایی نمی‌گوید داده خراب است؛ می‌گوید مقصد نامی را که در فایل آمده نمی‌شناسد.

قبل از تغییر فایل، مبدا و مقصد را مشخص کنید

از سرور قبلی نسخهٔ دیتابیس و از هاست مقصد نسخهٔ MariaDB یا MySQL را بپرسید. در phpMyAdmin معمولاً صفحهٔ خانه نسخه را نشان می‌دهد. اگر SQL دسترسی دارید، می‌توانید اجرا کنید:
کد / دستورSELECT VERSION(); SHOW COLLATION LIKE 'utf8mb4%';
دستور اول نسخهٔ مقصد را می‌گوید و دستور دوم نام collationهای پشتیبانی‌شده را. از خروجی مطمئن شوید نام جایگزین واقعاً در مقصد هست؛ همهٔ نسخه‌ها فهرست یکسانی ندارند. راهنمای collationهای MariaDB تفاوت نسخه‌ها را نشان می‌دهد.
خط کامل خطا را بخوانید. phpMyAdmin معمولاً نزدیک محل توقف، جدول یا نام collation را نشان می‌دهد. اگر خطا به نام دیگری اشاره می‌کند، فقط همان مورد را بررسی کنید؛ چند نام ممکن است نیاز به تصمیم جدا داشته باشند. همزمان مطمئن شوید فایل خروجی برای همان دیتابیس و نسخه‌ای ساخته شده که قصد انتقالش را دارید.

فایل اصلی را دست‌نخورده نگه دارید

فایل .sql اصلی را کنار بگذارید و یک کپی تازه با نامی مانند database-test.sql بسازید. اگر فایل فشرده است، اول کپی را خارج کنید. در نسخهٔ آزمایشی، متن دقیق collation گزارش‌شده را جست‌وجو کنید. قبل از جایگزینی، بررسی کنید همان نام چند بار و در چه جاهایی آمده است: ممکن است به‌عنوان collation جدول، ستون یا دستور تنظیم اتصال باشد.
برای هر مورد، از فهرست SHOW COLLATION نامی انتخاب کنید که مجموعه‌حروف utf8mb4 را نگه دارد و مقصد می‌شناسد. بعضی نسخه‌های قدیمی‌تر utf8mb4_unicode_ci یا utf8mb4_general_ci دارند، ولی این‌ها رفتار مرتب‌سازی و مقایسهٔ متن را دقیقاً مثل utf8mb4_0900_ai_ci تضمین نمی‌کنند. به همین دلیل نام جایگزین را از روی حدس انتخاب نکنید و رشتهٔ utf8mb4 را به utf8 تبدیل نکنید؛ این کار می‌تواند پشتیبانی از نویسه‌های چهار‌بایتی را از بین ببرد.
در ویرایشگر متن، فقط نام collation موجود در نسخهٔ کپی را جایگزین کنید؛ جست‌وجو و جایگزینی کل واژهٔ utf8mb4 کار درستی نیست. فایل را با همان کدگذاری و بدون تبدیل پایان خط عجیب ذخیره کنید. اندازهٔ نسخهٔ اصلی و کپی را مقایسه کنید؛ تغییر ناگهانی اندازه یا خالی‌شدن فایل نشانهٔ ذخیرهٔ اشتباه است.

اول روی پایگاه دادهٔ آزمایشی import کنید

در مقصد یک پایگاه دادهٔ خالی برای آزمایش بسازید و همان فایل کپی‌شده را وارد کنید. اگر import نیمه‌کاره متوقف شد، آزمون را روی دیتابیس آزمایشی پاک و دوباره از اول انجام دهید؛ چند بار واردکردن در همان دیتابیس ممکن است جدول تکراری یا دادهٔ ناقص بسازد. دیتابیس اصلی سایت را در این مرحله انتخاب نکنید.
پس از import موفق، تعداد جدول‌ها، چند نوشته و کاربر آزمایشی را با مبدا مقایسه کنید. اگر دسترسی SQL دارید، شمار ردیف‌های جدول‌های مهم را هم مقایسه کنید. متن فارسی، حروف عربی، علامت‌های نگارشی و ایموجی را در یک صفحهٔ تست ببینید؛ درست‌بودن تعداد جدول‌ها به‌تنهایی درستی متن را ثابت نمی‌کند. برای جدول‌هایی که ستون یکتا دارند، چند مقدار شبیه به هم را هم بررسی کنید؛ collation روی برابر بودن متن‌ها اثر می‌گذارد.

اگر همچنان خطا می‌ماند

اگر فایل چند collation ناشناخته دارد، برای هر نام جداگانه مقصد را بررسی کنید. گاهی راه بهتر این است که خروجی را از سرور مبدأ در نسخه‌ای سازگارتر بگیرید یا مقصد را به نسخه‌ای ارتقا دهید که قواعد لازم را پشتیبانی می‌کند. تبدیل collation همهٔ ستون‌ها می‌تواند روی مرتب‌سازی، جست‌وجو و قیدهای یکتا اثر بگذارد؛ این کار را بدون آزمون روی کپی انجام ندهید.
هنگام تماس با میزبان، نسخهٔ مبدا، نسخهٔ مقصد، خط کامل خطا و نام collation را بفرستید؛ فایل کامل پایگاه داده ممکن است اطلاعات خصوصی مشتری داشته باشد، آن را در گفت‌وگوی عمومی قرار ندهید. پس از موفقیت، نسخهٔ اصلی SQL را تا پایان بررسی سایت نگه دارید. راهنمای انتقال MySQL به MariaDB هم دربارهٔ تفاوت نسخه‌ها و سازگاری پیش از جابه‌جایی توضیح می‌دهد.
اگر فایل چندصد مگابایت است، ویرایشگر سادهٔ مرورگر آن را باز نکند. از ویرایشگری استفاده کنید که فایل بزرگ را درست ذخیره می‌کند. پس از جایگزینی، عبارت قدیمی را دوباره جست‌وجو کنید؛ اگر هنوز باقی مانده، احتمال دارد یکی از جدول‌ها collation دیگری داشته باشد و import دوباره در همان نقطه بایستد. نام‌ها را بر اساس خطای واقعی پیش ببرید، نه اینکه همهٔ واژه‌های مشابه را یک‌جا عوض کنید.
فایل SQL ممکن است پیش از ساخت جدول، دستور SET NAMES یا تنظیم collation اتصال داشته باشد. خطای 1273 را بخوانید تا نام دقیق را بیابید. اگر charset با collation مقصد سازگار نباشد، import خطای تازه‌ای می‌دهد. نگه‌داشتن utf8mb4 به حفظ فارسی و شکلک‌های چهار‌بایتی کمک می‌کند؛ نام collation جایگزین را باید از فهرست مقصد انتخاب کنید.
تفاوت مقایسهٔ متن می‌تواند مرتب‌سازی و قید یکتا را عوض کند. اگر سایت از ایمیل یا نام کاربری به‌عنوان مقدار یکتا استفاده می‌کند، در نسخهٔ آزمایشی چند ورودی شبیه هم را آزمایش کنید. برای مثال دو نشانی که فقط در حروف بزرگ و کوچک فرق دارند ممکن است در مقصد یکسان دیده شوند. این آزمون پیش از انتقال فروشگاه یا حساب کاربری مهم است؛ یک import موفق به‌تنهایی سازگاری کامل را ثابت نمی‌کند.
اشتراک‌گذاری:
لینکدینتلگرامایکس

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام