نوشته‌ها

mysql ha dbaas

دسترسی پذیری بالا (HA) برای MySQL و MariaDB: مقایسه رپلیکیشن مستر-مستر با گالرا کلاستر

گالرا کلاستر (Galera Cluster) یکی از راهکارهای جدید پیاده‌سازی دسترسی بالا (High Availability) برای دیتابیس‌های MySQL (و MariaDB) است که نسبت به رپلیکیشن MySQL پیشینه کوتاه‌تری دارد. رپلیکیشن (Replication) MySQL، که بصورت درونی (native) از نسخه MySQL v3.23 پشتیبانی می‌شود، بصورت master-slave طراحی شده است اما با تغییر تنظیمات می‌توان آن را بصورت مستر-مستر (master-master) هم پیاده‌سازی کرد. گرچه پیاده‌سازی آن نسبتا آسان است و برای بعضی کاربردها جواب می‌دهد، اما محدودیت‌هایی هم دارد. در طرف دیگر، گالرا کلاستر تکنولوژی متفاوتی است پیاده‌سازی و مدیریت آن نیازمند دانش مروبط به خودش است.

آیا مزایای کلاستر MySQL گالرا استفاده از آن را بجای رپلیکیشن MySQL توجیه می‌کند؟ در این مطلب گالرا کلاستر را با رپلیکیش درونی دیتابیس MySQL مقایسه می‌کنیم.

رپلیکیشن دیتابیس چیست؟

بگذارید قبل از شروع مقایسه، مفاهیم مربوط به مکانیزم پیاده‌سازی رپلیکیشن در این ۲ راهکار را توضیح دهیم. بصورت کلی، هر تغییری در پایگاه داده MySQL یک رویداد بصورت فایل باینری ایجاد می‌کند. بعد از فعال‌سازی رپلیکیشن، این رویداد به نودهای همتا فرستاده می‌شود تا با اعمال آن با نود اصلی سینک شوند.

رپلیکیشن MySQL

نمودار زیر روند ارسال اطلاعات از نود مستر به نود رپلیکا بعد از انجام یک تراکنش موفق در دیتابیس MySQL را نشان می‌دهد.

mysql replication

ابتدا رویداد به صورت باینری در لاگ باینری نود مستر MySQL ذخیره می‌شود. سپس نود یا نودهای slave بوسیله slave_IO_thread رویدادهای باینری را از لاگ‌های نود مستر پول (pull) کرده و در لاگ relay خودشان ذخیره می‌کنند. سپس slave_SQL_thread این رویدادها را خوانده و بصورت آسنکرون (Asynchronous) در پایگاه داده خود اعمال می‌کنند. با توجه به ذات آسنکرون این رپلیکیشن، تضمینی وجود ندارد که نود رپلیکا، در همان لحظه‌ی انجام تراکنش در نود مستر، اطلاعات جدید را اعمال کند.

به صورت ایده‌آل نودهای slave در رپلیکیشن دیتابیس MySQL با تنظیمات read_only=ON  یا super_read_only=ON  بصورت فقط خواندنی کانفیگ می‌شوند تا ارسال دستورات write تصادفی به این نودها، باعث ایجاد تناقض بین نودهای مستر و رپلیکا نشود. این ناهماهنگی بین نودهای رپلیکیشن مخصوصا هنگام failover ممکن است باعث بروز خطا شود. ولی در رپلیکیشن master-master باید آپشن فقط خواندنی در نود مستر دوم غیرفعال باشد تا امکان پردازش نوشتن‌های همزمان بین نودهای مستر وجود داشته باشد. در این سناریو با استفاده از آپشن CHANGE MASTER در مستر اول این امکان فراهم می‌شود تا بصورت چرخشی نود مستر اول هم با نود مستر دوم سینک شود.

رپلیکیشن گالرا کلاستر

نمودار زیر روند ارسال اطلاعات از یک نود به نود دیگر بعد از انجام یک تراکنش موفق در کلاستر گالرا را نشان می‌دهد.

Galera replication

در این سناریو رویدادها در یک writeset کپسوله شده و از نود مبدا به بقیه نودها برادکست می‌شوند. هر کدام از نودها بسته‌های دریافتی را بررسی کرده و در صورت تایید آن‌ها را بصورت آسنکرون اعمال می‌کنند. در نهایت همه نودها بعد از بررسی و اعمال تغییرات، یکپارچه خواهند شد. این روند بصورت لاجیکال سنکرون (Synchronous) است اما عملیات نوشتن و اعمال تغییرات بصورت مستقل (و در نتیجه آسنکرون) و با تضمین یکپارچگی نهایی در رپلیکاهای مختلف انجام می‌شود.

جلوگیری از تصادم کلید اصلی در کلاستر MySQL

برای پیاده‌سازی رپلیکیشن مستر-مستر در دیتابیس MySQL باید افزایش خودکار کلیدهای اصلی پایگاه داده را طوری تنظیم کرد تا به مشکل تصادم کلید اصلی (Primary Key Collision) بین نودهای مستر برنخوریم؛ به این صورت که کلیدهای اصلی در نودهای مختلف به گونه‌ای افزایش یابند که با هم همپوشانی نداشته و در نتیجه یک شماره دو بار استفاده نشود. این کانفیگ باید براساس تعداد نودهای مستر در کلاستر،‌ به صورت دستی تنظیم شود. در زیر نمونه‌ای از تنظیمات نودهای مستر در رپلیکیشن مستر-مستر MySQL (در فایل my.cnf) را مشاهده می‌کنید.

Master1:
log-slave-updates
auto_increment_increment=2
auto_increment_offset=1

Master2:
log-slave-updates
auto_increment_increment=2
auto_increment_offset=2

مقدار auto_increment_increment باید در هر نود مستر برابر با تعداد کل مسترهای کلاستر باشد. متغیرهای auto_increment_offset هم باید با مقادیر منحصر به فرد در هر پایگاه داده مستر تنظیم شوند.

به طریق مشابه گالرا کلاستر هم راهکاری برای جلوگیری از تصادم کلیدهای اصلی در دیتابیس دارد؛ در این راهکار مقدار افزایش خودکار کلید اصلی بصورت خودکار و با استفاده از متغیر wsrep_auto_increment_control انجام می‌شود. در صورتی که این متغیر یک باشد (که بصورت پیشفرض هست) گالرا کلاستر متغیرهای auto_increment_increment و auto_increment_offset را بصورت خودکار و براساس تعداد نودهای مستر تنظیم می‌کند. مسلما در کلاسترهای master-slave این متغیر باید غیرفعال یا off باشد. جدول زیر نمونه‌ای از مقادیر کلید اصلی در یک کلاستر MySQL با ۳ نود مستر را نشان می‌دهد.

Auto increment value Auto_increment_offset Auto_increment_increment Node
1, 4, 7, 10, 13, 16… 1 3 Node 1
2, 5, 8, 11, 14, 17… 2 3 Node 2
3, 6, 9, 12, 15, 18… 3 3 Node 3

اگر یک برنامه عملیات اینسرت (INSERT) را با ترتیب زیر روی این کلاستر MySQL انجام دهد:

Node1, Node3, Node2, Node3, Node3, Node1, Node3 ..

کلیدهای اصلی ذخیره شده در جدول دیتابیس به این صورت خواهد بود:

1, 6, 8, 9, 12, 13, 15 ..

به طور ساده، در صورتی که از رپلیکیش مستر-مستر استفاده می‌کنید (چه رپلیکیشن MySQL چه گالرا کلاستر)، برنامه شما باید قابلیت تحمل کلیدهای اصلی نامتوالی را داشته باشد.

همخوانی یا سازگاری (Consistency) داده‌ها در کلاستر MySQL

گالرا کلاستر دارای یک مکانیزم کنترل جریان داده است که به نودهای یک کلاستر دیتابیس MySQL این امکان را می‌دهد تا در اعمال تغییرات از بقیه نودها عقب نیفتند؛ به این صورت که بقیه نودها سرعت اعمال تغییرات را کم می‌کنند تا نود کم سرعت از سینک خارج نشود. با این راهکار، احتمال لگ بین نودها به حداقل می‌رسد. به صورت پیش‌فرض Galera Cluster به نودهای کلاستر دیتابیس اجازه می‌دهد تا حداکثر ۱۶ تراکنش عقب بیفتند (که با متغیر gcs.fc_limit قابل تنظیم است). چنانچه بخواهید یک کوئری SELECT مهم انجام دهید که نیاز به به‌روزترین داده‌ها داشته باشد، باید قبل از انجام کوئری نشست wsrep_sync_wait را ست کنید. در این صورت پایگاه داده قفل می‌شود تا جدیدترین تراکنش‌ها را از کلاستر دریافت کند، سپس کوئری اجرا می‌شود تا جدیدترین اطلاعات را بازگرداند.

گالرا کلاستر دارای یک مکانیزم داخلی برای جلوگیری از ناسازگاری (inconsistency) داده‌ها است؛ به این صورت که اگر نودی به هر دلیلی نتواند writeset های کلاستر را اعمال کند، از گالرا کلاستر خارج می‌شود. این خروج با پیام‌های خطای زیر همراه خواهد بود:

 [ERROR] WSREP: Failed to apply trx 1 4 times
 [ERROR] WSREP: Node consistency compromized, aborting..

برای اینکه نود بتواند مجددا وارد کلاستر شود، باید دیتابیسِ نود ناسازگار مجددا سینک شود. این عمل می‌تواند به صورت دستی یا بازگردانی خودکار یک اسنپ شات (snapshot) انجام شود.

رپلیکیشن مستر-مستر خودِ MySQL اما سازگاری داده‌ها را اجبار نمی‌کند و این امکان وجود دارد که یکی از نودها از اعمال داده‌های جدید عقب بیفتد. بررسی ناسازگاری پایگاه داده در این سناریو یا باید بصورت دستی انجام شود، یا با ابزارهای دیتابیس پرکونا (Percona) مانند pt-table-checksum و mysql-replication-check.

حل تعارض در دیتابیس

به طور ذاتی کلاسترهای دیتابیس مستر-مستر به بیش از یک نود یا عضو کلاستر این امکان را می‌دهند تا کوئری‌های write را پردازش کنند. در رپلیکیشن داخلی MySQL مکانیزم خودکاری برای حل تعارض‌های احتمالی بین نودهای کلاستر MySQL وجود ندارد. در صورت بروز تعارض، پروسه SQL از اعمال کوئری‌های جدید خودداری کرده تا مشکل بصورت دستی (یا با اسکیپ کردن رویداد یا سینک مجدد دیتابیس) حل شود.

در طرف دیگر، گالرا کلاستر راهکار بهتری برای حل تعارض در رپلیکیشن دیتابیس دارد. با تنظیم متغیر wsrep_retry_autocommit می‌توان کلاستر MySQL را مجبور کرد تا در صورت تعارض مجددا تراکنش را اعمال کند. این متغیر بصورت پیشفرض ۱ است و برای غیر فعال کردن آن می‌توان مقدار آن را صفر گذاشت. این متغیر مخصوصا به درد برنامه‌هایی می‌خورد که می‌خواهند کامیت خودکار (Autocommit) آن‌ها با ددلاک (deadlock) مواجه نشود.

اجماع نودها و failover در کلاستر MySQL

گالرا کلاستر از پروتکل GCS (Group Communication System) برای اجماع کلاستر و بررسی دسترسی‌پذیری نودهای کلاستر MySQL استفاده می‌کند. در صورتی تایم اوت نود (پارامتر gmcast.peer_timeout که پیشفرض ۳ ثانیه است) پر شود، وضعیت نود به unhealthy تغییر کرده و بصورت خودکار از کلاستر اخراج می‌شود. یک نود گالرا در صورتی که در وضعیت synced قرار داشته باشد، healthy تلقی شده و به کوئری‌های read و write پاسخ می‌دهد. این مکانیزم، راهکارهای healthcheck توسط لایه‌های بالاتر (مانند لود بالانسر load balancer) را بسیار راحت می‌کند.

در رپلیکیشن داخلی MySQL، نود مستر اهمیت چندانی به نودهای slave نمی‌دهد، نودهای slave هم به صورت مجزا و از طریق پروسه slave_IO_thread سینک بودن خود با نود مستر و دریافت رویدادهای باینری از آن را بررسی می‌کنند. در صورت fail شدن نود مستر، رپلیکیشن هم شکسته شده و نودهای slave هر ۶۰ ثانیه (مقدار پیشفرض برای slave_net_timeout) اقدام به اتصال مجدد به نود مستر می‌کنند. از دید load balancer در این راهکار، مکانیزم health check باید مقادیر زیر را بررسی کند:

Seconds_Behind_Master

Slave_IO_Running

Slave_SQL_Running

read_only variable

super_read_only variable (MySQL 5.7.8 and later)

از نظر failover، هر دو راهکار گالرا کلاستر و رپلیکیشن داخلی MySQL مشابه هستند. با توجه به ذات مستر-مستر رپلیکیشن، هر کدام از نودهای کلاستر دارای داده‌های مشابه بوده و قابلیت پردازش کوئری‌های read و write بصورت همزمان را دارند. بنابرین از نظر پایگاه داده failover موضوعیتی نداشته و فقط برنامه‌ای که از کلاستر دیتابیس استفاده می‌کند باید توانایی نادیده گرفتن نودهای غیرعملیاتی را داشته باشد. به خاطر داشته باشید که رپلیکیشن MySQL آسنکرون بوده و احتمال وجود تاخیر در اعمال تغییرات در نودهای مختلف وجود دارد.

اضافه کردن نودهای جدید به کلاستر دیتابیس MySQL

در رپلیکیشن داخلی MySQL عملیات اضافه کردن نود جدید به کلاستر دیتابیس بصورت دستی انجام می‌شود. به این صورت که قبل از ایجاد رپلیکیشن جدید،‌ باید یک پکاپ از نود مستر گرفته شده و به نود جدید انتقال داده شود. برای نودهای فعلی هم که رپلیکیشن آن‌ها بر اساس expire_logs_days شکسته شده است، همین روند می‌تواند برای عضویت مجدد نود به کلاستر هم انجام شود. البته ابزارهای مختلفی، مانند تولکیت پرکونا (Percona Toolkit) برای کمک به این روند در رپلیکیشن MySQL وجود دارند. همچنین با استفاده از ClusterControl می‌توان عملیات سینک مجدد نود کلاستر دیتابیس را با دو کلیک (از طریق کپی مستر فعلی یا بکاپ دیتابیس قبلی) انجام داد.

در گالرا کلاستر دو روش برای اضافه کردن نود جدید به کلاستر دیتابیس MySQL وجود دارد؛ روش اول: IST یا انتقال رویداد پلکانی (incremental state transfer)،‌ روش دوم: SST یا انتقال بصورت اسنپ شات (state snapshot transfer). برای مواردی که فقط چند تراکنش از دست رفته‌اند، روش IST اولویت دارد. روش SST مانند گرفتن یک بکاپ کامل (Full Backup) و انتقال آن عمل می‌کند و از نظر پردازشی نسبتا سنگین است. کلاستر گالرا بصورت خودکار و بر اساس وضعیت کلاستر بهترین روش را برای سینک دیتابیس انتخاب می‌کند. در مواردی که اضافه کردن نود جدید به کلاستر گالرا با خطا روبرو می‌شود، کافی است محتویات دایرکتوری datadir در MySQL را پاک کنید و مجددا سرویس MySQL را اجرا کنید. روند اضافه کردن نود جدید به گالرا کلاستر ساده است و افزایش مقیاس کلاستر دیتابیس و رفع مشکلات نودهای خراب را بسیار راحت می‌کند.

اتصال سفت در برای اتصال سست در کلاستر پایگاه داده

جفت شدن پایگاه‌داده‌ها در رپلیکیشن داخلی MySQL به اصطلاح سست (Loosely Coupled) است؛ به عبارت دیگر، میزان وابستگی بین نودهای مختلف کم است. رپلیکیشن MySQL با اتصالات کم سرعت و روی سخت‌افزارها و سیستم‌عامل‌های مختلف به راحتی کار می‌کند. همچنین از موتورهای ذخیره‌سازی گوناگون مانند MyISAM، Aria، MEMORY و ARCHIVE پشتیبانی می‌کند. مجموعه این ویژگی‌ها باعث شده تا کلاستر MySQL اصطلاحا سست باشد و رپلیکیشن مستر-مستر را در محیط‌های متفاوت راحت‌تر کند.

در مقابل، اتصال نودها در کلاستر گالرا محکم (Tightly Coupled) است؛ به عبارت دیگر، وابستگی نودها در رپلیکیشن مستر-مستر به یکدیگر بالا بوده و سرعت رپلیکیشن به اندازه سرعت کندترین نود در کلاستر است. گالرا دارای مکانیزم کنترل جریان داده در رپلیکیشن است و به صورت خودکار سرعت رپلیکیشن بین نودهای مختلف را تنظیم می‌کند؛ این مکانیزم می‌تواند باعث افزایش یا کاهش سرعت در همه نودها شود. بنابرین توصیه می‌شود در کلاستر MySQL گالرا از منابع و زیرساخت مشابه (پردازشگر، رم، دیسک و سرعت شبکه و تاخیر) برای همه نودها استفاده شود.

نتیجه‌گیری

گالرا کلاستر در برابر رپلیکیشن مستر-مستر MySQL برتری محسوسی دارد. پشتیبانی از رپلیکیشن آسنکرون، سازگاری بالا و ویژگی‌های پیشرفته مانند کنترل عضویت خودکار و slave های چند نخی (multi-threaded)، انتخاب گالرا کلاستر برای رپلیکیشن MySQL را بسیار راحت می‌کند. با توجه به موارد ذکر شده، به طور خلاصه موارد استفاده از هر کدام از رپلیکیشن‌های MySQL به صورت زیر است:

در چه کاربردهایی از رپلیکیشن داخلی MySQL استفاده کنیم؟
  • زمانی که منابع، زیرساخت و سرعت شبکه هر کدام از نودهای master متفاوت باشد (سناریو Loosely Coupled).
  • زمانی که از قبل از رپلیکیشن داخلی MySQL استفاده می‌کنید و می‌خواهید برای افزونگی بیشتر (redundancy) یک نود جدید به کلاستر اضافه کنید.
  • مواقعی که برنامه کاربردی شما قابلیت کنار آمدن با محدودیت‌های گالرا کلاستر نداشته و امکان استفاده از یک لود بالانسر SQLی مانند ProxySQL یا MaxScale را ندارید.
محدودیت‌ها و مواردی که گالرا کلاستر ساپورت نمی‌کند:
  • جدول‌های غیر از InnoDB.
  • تراکنش‌های XA.
  • رپلیکیشن مبتنی بر Statement بین مسترها.
  • وابستگی به استفاده مستقیم از قفل جدول (LOCK TABLES statement).
  • لاگ عمومی دیتابیس و لاگ کوئری‌های کند (Slow Query Log) بجای فایل در جدول ذخیره می‌شوند.
دلایلی که از گالرا کلاستر برای رپلیکیشن MySQL استفاده کنیم؟
  • قابلیت اعمال ایمن کوئری‌های write روی مسترهای مختلف.
  • مدیریت خودکار سازگاری داده‌ها بین دیتابیس‌های مختلف.
  • اضافه و سینک کردن آسان نودهای جدید به کلاستر پایگاه داده.
  • پاک کردن خودکار خطاها و ناسازگاری‌ها.
  • ویژگی‌های HA (High Availability) پیشرفته‌تر.
  • پشتیبانی از کلاستر MariaDB.

منبع

دیتابیس ابری مدیریت شده پنکیک

در صورتی که برای اپلیکیشن یا برنامه خود نیاز به استفاده از یک پایگاه داده پرسرعت دارید، که علاوه بر امنیت بالا و پشتیبانی توسط متخصصین دیتابیس، روی دیتاسنتر مورد نظر خودتان میزبانی شود، می‌توانید از طریق پرتال ثبت نام کنید و برای شارژ رایگان دیتابیس ابری پنکیک از طریق تیکت یا تلفن با ما تماس بگیرید. دیتابیس‌های پنکیک به صورت کامل مدیریت شده هستند و در صورت نیاز توانایی کلاستر کردن دیتابیس‌های خود برای دسترسی پذیری بالا (HA) را خواهید داشت.

database backup plans

آموزش بکاپ گیری از دیتابیس MySQL

درباره اهمیت بکاپ گیری و ویژگی‌های یک پلن بکاپ گیری از دیتابیس مفصلا صحبت کردیم. اما بطور خلاصه، با توجه به اهمیت اطلاعات پایگاه داده و سرعت بالای تغییرات در آن، لازم است بطور دوره‌ای از دیتابیس خود نسخه پشتیبان تهیه کنیم. در این مقاله به انواع روش‌های بکاپ گیری از دیتابیس (به خصوص MySQL)، نحوه برگرداندن بکاپ دیتابیس، نحوه بکاپ گرفتن از دیتابیس در فضای ابری و بکاپ گیری اتوماتیک از دیتابیس خواهیم پرداخت.

روش‌های بکاپ گیری از دیتابیس MySQL

روش‌های مختلفی برای بکاپ گیری (Backup) از پایگاه داده MySQL وجود دارد که براساس نحوه پیادی‌سازی سرویس شما و زیرساختی که از آن استفاده می‌کنید متفاوت است. چنانچه سایت یا اپلیکیشن خود را بطور مستقیم روی سرور مجازی پیاده سازی کرده‌اید، باید از ابزار mysqldump برای بکاپ استفاده کنید. اگر در کنار سرویس‌های سایت یا اپلیکیشن خود، ابزار phpMyAdmin را هم نصب کرده‌اید، می‌توانید از رابط گرافیکی آن برای دانلود نسخه پشتیبان از پایگاه داده خود استفاده کنید. همچنین در صورتی که سرویس دهنده شما پنل دایرکت ادمین یا cpanel در اختیار شما قرار داده یا از ارائه دهندگان دیتابیس ابری خدمت می‌گیرید، می‌توانید به راحتی از پرتال آن‌ها برای زمان‌بندی و بک آپ گیری دیتابیس خود استفاده کنید. در ادامه هر کدام از این روش‌ها را با جزئیات بیشتر شرح می‌دهیم.

نحوه بکاپ گیری از دیتابیس با استفاده از خط فرمان CLI سرور

اگر سایت یا نرم افزار شما بدون واسطه روی سرور لینوکسی نصب شده که مدیریت آن بر عهده‌ی خود شماست، می‌توانید براحتی با استفاده از ابزار  mysqldump (که بصورت پیش‌فرض با دیتابیس mysql نصب می‌شود) از دیتایس بکاپ بگیرید. برای این کار به سرور خود ssh زده و دستور زیر را با دسترسی روت اجرا کنید:

$ sudo mysqldump -u [user] -p [database_name] > [filename].sql

فراموش نکنید که باید نام کاربری دیتابیس، نام دیتابیس و نام فایل را در دستور بالا جایگزین کنید. اگر می‌خواهید از همه دیتابیس‌های سیستم بکاپ بگیرید می‌توانید دستور مذکور را با آپشن‌های زیر اجرا کنید. این دستور تاریخ روز را هم به اسم فایل بکاپ اضافه می‌کند:

$ mysqldump --all-databases --single-transaction --quick --lock-tables=false > full-backup-$(date +%F).sql -u root -p

نحوه برگرداندن بکاپ دیتابیس با استفاده از خط فرمان CLI سرور

بازگردانی (Restore) بکاپ دیتابیسی که با استفاده از خط فرمان گرفته‌اید هم به اندازه بکاپ گیری آن ساده بوده و با یک خط انجام می‌شود. فقط به خاطر داشته باشید که برای برگرداندن بکاپ باید بجای mysqldump از دستور mysql استفاده کنید:

$ mysql -u [user] -p [database_name] < [filename].sql

نحوه بکاپ گیری از دیتابیس با استفاده از phpMyAdmin

یکی از ابزارهای اختیاری که مدیریت پایگاه داده MySQL را تسهیل می کند phpMyAdmin است. اگر این ابزار را روی سرور دیتابیس خود نصب کرده‌اید، می‌توانید از آن برای بکاپ گیری دیتابیس خود استفاده کنید.

برای این کار ابتدا وارد پنل phpMyAdmin شده و از ستون سمت چپ دیتابیس مورد نظر خود را انتخاب کنید.

سپس از نوار بالا روی لینک Export کلیک کنید. برای سرعت بیشتر متد بکاپ quick و فرمت sql را انتخاب کرده و دکمه Go را بزنید تا فایل بکاپ شما دانلود شود.

phpmyadmin database backup

نحوه برگرداندن بکاپ دیتابیس MySQL با استفاده از phpMyAdmin

بازگردانی بکاپ دیتابیس را هم می‌توانید بوسیله پنل phpMyAdmin انجام دهید. تنها نکته‌ای که هنگام برگرداندن بک آپ دیتابیس باید به آن توجه کنید خالی بودن دیتابیس فعلی است؛ چراکه اطلاعات بازگردانی شده با اطلاعات قبلی جایگزین (overwrite) نمی‌شود. بنابراین اگر داده‌ای از قبل در دیتابیس وجود داشته باشد، بازگردانی بک آپ ممکن است باعث ایجاد ردیف‌های تکراری یا اختلال و خطا شود.

بنابراین همیشه قبل از بازگردانی فایل پکاپ دیتابیس، دیتابیس فعلی را پاک کنید. برای این کار از ستون سمت چپ phpMyAdmin پایگاه داده مورد نظر خود را انتخاب کنید. سپس در انتهای لیست جدول‌ها گزینه Check All را انتخاب کرده و در لیست مقابل آن Drop را بزنید. برای تایید دکمه Yes را بزنید.

حالا برای بازگردانی بک آپ دیتابیس همانند ساخت بکاپ، روی دیتابیس مورد نظر کلیک کنید، فقط این بار بجای گزینه Export گزینه Import را انتخاب کنید. فایل بکاپ پایگاه داده را انتخاب کرده و دکمه Go را بزنید.

نحوه بکاپ گرفتن از دیتابیس در فضای ابری

اصولا نگهداری بکاپ روی فضای محلی سرور یا دانلود آن روی کامپیوتر شخصی کار درستی نیست. این کار دو ایراد اساسی دارد: اول اینکه در صورت خرابی سخت افزار سرور اصلی (هارد یا SSD) یا از دسترس خارج شدن آن (مشکل شبکه) شما دسترسی به بکاپ‌های دیتابیس خود را هم از دست می‌دهید؛ که در بدترین حالت ممکن است منجر به از دست رفتن همه اطلاعات دیتابیس شما شود و بازگردانی اطلاعات پایگاه داده در سروری دیگر را غیرممکن کند. دانلود بک آپ‌های دیتابیس هم خیلی کاربردی نیست چراکه در صورت بروز خرابی، زمان بازگردانی دیتابیس و به طبع آن سرویس شما را به شدت افزایش می‌دهد.

یکی از روش‌های بهینه برای ذخیره سازی و نگهداری بک آپ های دیتابیس استفاده از فضای ابری است. فضای ذخیره سازی ابری که پرکاربردترین نوع آن آبجکت استوریج (object storage) است، به شما این امکان را می‌دهد تا فایل‌های خود را بصورت آبجکت در فضای امن و همیشه در دسترس ذخیره و نگهداری کنید. شرکت‌های ارائه‌ دهنده فضای ابری معمولا پلن‌های مختلفی متناسب با نیازهای شما ارائه می‌دهند که ذخیره‌سازی بکاپ‌های شما در فضای ابری را بسیار مقرون به صرفه می‌کند. برای مثال آمازون AWS پلن آبجکت استوریج با عنوان S3 IA (Infrequently Accessed) ارائه می‌کند؛ S3 IA یک آبجکیت استوریج برای فایل‌هایی است که به ندرت به آن‌ها نیاز خواهید داشت، دقیقا مثل فایل‌های بکاپ پایگاه داده. با استفاده از این پلن، هزینه نگهداری بکاپ‌های شما در فضای ابری بسیار پایین خواهد بود اما به ازای هر دانلود هزینه‌ای به فاکتور شما اضافه می‌شود. در ادامه نحوه بکاپ گیری از دیتابیس در فضای ابری AWS و همچنین آبجکت استوریج ابر آروان (که از استاندارد S3 آمازون AWS استفاده می‌کند) را آموزش خواهیم داد.

آموزش بک آپ گیری از دیتابیس روی آبجکت استوریج آمازون AWS

بهترین گزینه برای فضای ابری، سرویس S3 آمازون AWS است. آمازون S3 نه تنها ماندگاری داده‌های شما را با درصد ۹۹.۹۹۹۹۹۹۹۹۹۹۹ تضمین می‌کند، بلکه ۵ گیگابایت فضای ذخیره سازی رایگان ابری در اختیار شما قرار می‌دهد. پلن فضای ذخیره سازی ابری رایگان AWS یک ساله بوده و شما علاوه بر ۵ گیگابایت فضای رایگان، تا ۲۰۰۰ ریکوئست آپلود و ۲۰۰۰۰ ریکوئست دانلود رایگان خواهید داشت.

ابتدا یک باکت (Bucket) در کنسول آمازون AWS ایجاد کنید (دقت کنید که پلن 5GB Standard Free Tier را انتخاب کرده باشید). این قسمت در بخش S3 (زیر مجموعه Storage) قرار دارد. دقت کنید که قبل از ساخت باکت، region یا ناحیه مورد نظر خود را درست انتخاب کرده باشید. برای تغییر ناحیه از لیستی که سمت راست نوار بالای کنسول قرار دارد استفاده کنید.

حتما بعد از ساخت باکت یک حساب کاربری جدید با سطح دسترسی به باکت‌های S3 ایجاد کنید. برای این کار به بخش IAM در کنسول AWS وارد شده و از قسمت Users یک حساب کاربری جدید بسازید. هنگام ساخت یوزر جدید این موارد را رعایت کنید: اول اینکه نوع دسترسی کاربر (Access Type) را Programmatic Access انتخاب کنید تا کاربر شما امکان دسترسی با aws cli را داشته باشد. مورد دوم که باید رعایت کنید نوع permission انتخابی برای کاربر است که حتما باید شامل policy ادمین یا S3 باشد. در مرحله آخر هم حتما کلیدهای access و secret را ذخیره کنید زیرا فقط یک بار برای شما نمایش داده می‌شوند.

در نهایت شما باید موارد زیر را در اختیار داشته باشید که هنگام ذخیره سازی بکاپ به آن‌ها نیاز خواهیم داشت.

AWS Bucket Name

AWS Access Key ID

AWS Secret Access Key

بعد از ساخت باکت به ترمینال SSH سرور مجازی خود برگردید. برای اینکه امکان ذخیره سازی بکاپ دیتابیس روی فضای ابری AWS را داشته باشید باید AWS CLI را روی ماشین مجازی خود نصب کرده و Access key  و Secret Key خود را روی آن تنظیم کنید. در صورتی که از سرور مجازی AWS یا همان اینستنس EC2 استفاده می‌کنید این ابزار به صورت پیشفرض روی سرور شما نصب است.

$ apt install unzip curl
$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ unzip awscliv2.zip
$ ./aws/install
$ aws configure

بعد از زدن دستور آخر، ترمینال Access Key و Secret Key اکانت AWS شما را خواهد پرسید. اطلاعات خود را وارد کرده و اینتر کنید. از این به بعد به راحتی و تنها با یک خط می‌توانید بک آپ های دیتابیس خود را به فضای ابری AWS منتقل کنید:

$ aws s3 cp [filename].sql s3://[bucket-name]

با استفاده از دستور زیر می‌توانید لیست بکاپ‌های دیتابیس My SQL روی فضای ابری را مشاهده کنید:

$ aws s3 ls s3://[bucket-name]/

آموزش بک آپ گیری از دیتابیس روی آبجکت استوریج ابر آروان

چنانچه تمایل دارید از فضای ذخیره سازی ابری ایرانی برای نگهداری بک آپ پایگاه داده خود استفاده کنید، آبجکت استوریج ابر آروان و ایرانسل گزینه‌های مناسبی هستند. با توجه به اینکه ابر آروان دارای پلن فضای ذخیره سازی رایگان ۵ گیگابایتی (با محدودیت پهنای باند ۲۰ گیگابایت) است، ما هم در ادامه نحوه پشتیبان گیری دیتابیس روی این فضای ابری را شرح می‌دهیم. قیمت فضای ذخیره سازی آبجکت با همین مشخصات در خدمات ابری ایرانسل ماهیانه حدودا ۱۱۸۸۰ تومان است.

نحوه ذخیره سازی بکاپ دیتبایس روی فضای ابری ابر آروان بسیار شبیه به آمازون AWS است، با این تفاوت که به جای ابزار aws باید از rclone استفاده کنید. rclone قابلیت انتقال فایل به اکثر ارائه دهندگان فضای ابری، مخصوصا آن‌هایی که از استاندارد S3 آمازون استفاده می‌کنند را داراست. برای این منظور ابتدا پکیج rclone را نصب کرده و تنظیمات آن را به صورت زیر انجام دهید:

$ apt install rclone
$ rclone config

بعد از زدن آخرین دستور، لیست استوریج‌هایی که به rclone اضافه کرده‌اید را مشاهده خواهید کرد. قاعدتا این لیست باید خالی باشد. کاراکتر n  را برای اضافه کردن استوریج جدید وارد کنید. سپس یک اسم دلخواه برای سرویس دهنده خود وارد کنید، مثلا arvan. در مراحل بعدی نوع آبجکت استوریج را s3 انتخاب کرده و other را برای provider وارد کنید.

در مرحله بعدی false را انتخاب کنید تا بتوانید access key و secret key آروان را به صورت دستی وارد کنید. سپس گزینه ۱ را برای ریجن انتخاب کرده و در آخر آدرس endpoint که از ابر آروان دریافت کرده‌اید را وارد کنید.

از این پس می‌توانید با دستور زیر بک اپ های خود را به فضای ابری آروان منتقل کنید:

$ rclone copy [filename].sql arvan:[bucket-name]/[filename].sql

بکاپ گیری و بازگردانی اتوماتیک دیتابیس MySQL

راهکارهایی که تا الان بررسی کردیم مزایا و معایب متفاوتی دارند. اما مشکل یا عیب اصلی که بین همه‌ی این روش‌ها مشترک است، مدت زمان زیاد بازیابی یا ریستور دیتابیس است که Disaster Recovery Plan شما را بسیار کند می‌کند.  در صورتی که سرور عملیاتی شما دچار خرابی شده یا از دسترس خارج شود، شما نسخه‌ای از دیتابیس خود را در فضای ابری خواهید داشت، اما برگرداندن دیتابیس از فضای ابری و راه اندازی آن در سرور عملیاتی جدید زمان زیادی نیاز دارد که صدمه زیادی به سایت یا سرویس شما می‌رساند.

مشکل دوم روش‌های مذکور، دستی بودن آن‌هاست. البته شما براحتی می‌توانید یک اسکریپت بنویسید تا عملیات بکاپ گیری از دیتابیس‌های شما بصورت اتوماتیک انجام شود. اما تاثیر بک آپ گیری روی کارایی سرور شما به اندازه کافی زیاد است که شما را مجبور کند در فاصله‌های زمانی طولانی اسکریپت بکاپ را اجرا کنید. در اکثر موارد کسب و کارها و استارتاپ‌ها مجبور می‌شوند زمان بکاپ گیری را به نیمه شب موکول کنند.

استفاده از سرویس دیتابیس ابری مدیریت شده به شما این امکان را می‌دهد تا در کنار مزایای همه روش‌های مذکور، این ۲ چالش برزگ را هم حل کنید.

بکاپ گیری و بازگردانی اتوماتیک دیتابیس با استفاده از دیتابیس ابری مدیریت شده

استفاده از دیتابیس ابری مدیریت شده به شما این توانایی را می‌دهد تا:

بکاپ اتوماتیک با فاصله زمانی کوتاه روی سرورهای عملیاتی جاری و ثالث ایجاد کنید.

هشدار کارایی و سلامت برای دیتابیس‌های خود داشته باشید.

تنها با یک کلیک و در عرض چند ثانیه بک آپ دیتابیس را روی سرور عملیاتی بازگردانید.

برای دسترسی به لیست بکاپ‌های دیتابیس ابتدا وارد پنل مدیریت پنکیک شوید. در صورتی که قبلا دیتابیس خود را ایجاد کرده باشید، سکوی ابری پنکیک بصورت خودکار هر ساعت از دیتابیس شما فول بکاپ می‌گیرد. برای مشاهده لیست بکاپ‌ها، کافی است دیتابیس مورد نظر خود را از ستون سمت راست انتخاب کرده و وارد تب Fork Database شوید. لیست نسخه‌های بکاپ دیتابیس شامل ۴۸ فول بکاپِ ساعتی از ۴۸ ساعت گذشته و همچنین ۲۸ فول بکاپِ روزانه از ۳۰ روز گذشته است.

pancake DBaaS backup

برای برگرداندن هر کدام از بکاپ‌ها کافی است روی آیکون کنار ردیف مورد نظر کلیک کرده تا در کمتر از یک دقیقه دیتابیس مورد نظر روی سرور عملیاتی ریستور شود. بک آپ گیری اتوماتیک از دیتابیس و بازگردانی آن در دیتابیس‌های ابری پنکیک منحصر به پایگاه داده ی خاصی نیست و به صورت پیش‌فرض برای همه‌ی دیتابیس‌های پنکیک شامل MySQL، PostgreSQL، MongoDB و SQL Server فعال است.

aws ec2 rds

مقایسه سرویس دیتابیس آمازون AWS با پیاده سازی دستی دیتابیس ابری در سرور مجازی EC2

طراحی و انتخاب معماری زیرساخت یکی از مهم‌ترین مراحل شروع استارتاپ و توسعه محصول است. اگر در این مرحله درست انتخاب کنیم، از بسیاری از مشکلات در آینده جلوگیری خواهد شد. مقیاس‌پذیری، کنترل هزینه و افزایش کارایی از معیارهای اصلی هستند که باید در انتخاب زیرساخت دیتابیس مورد توجه قرار گیرند. در این مطلب تمرکز ما بیشتر روی هزینه راهکارهای مختلف برای پیاده‌سازی پایگاه داده ابری، به خصوص مقایسه هزینه سرویس‌های دیتابیس مدیریت شده (DBaaS) با پیاده‌سازی شخصی دیتابیس ابری خواهد بود.

برای ساده‌تر شدن این مقایسه، در این مطلب مثال‌هایی از سرویس‌های AWS خواهیم آورد. خدمات وب آمازون یا همان AWS، از پیشگامان سرویس‌دهندگان ابری در سطح جهانی است که هر دو سرویس دیتابیس مدیریت‌شده و سرور مجازی ابری (برای پیاده‌سازی دستی دیتابیس) را ارائه می‌دهد. بنابرین با مقایسه این دو سرویس، درک درستی از ويژگی‌ها و مزایای هر روش، تغییر هزینه‌ها در کوتاه مدت و بلند مدت و راهکاری که بیشترین منفعت را برای کسب و کار شما ایجاد می‌کند کسب خواهید کرد.

پیاده سازی دستی دیتابیس ابری روی EC2

ابتدایی‌ترین روش برای افزایش کارایی دیتابیس و بهره‌مندی از ویژگی‌های زیرساخت ابری در پایگاه داده، خرید سرورهای مجازی ابری و نصب و پیاده‌سازی دیتابیس روی آن است.

سرور مجازی ابری EC2 آمازون AWS

ابر پردازشی الستیک یا همان EC2 از اولین خدمات AWS است که در سال ۲۰۰۶ به لیست سرویس‌های آمازون اضافه شد. به زبان ساده، EC2 یک سرور مجازی است که روی زیرساخت ابری میزبانی می‌شود، از مزایای اصلی آن می‌توان به پیاده‌سازی سریع و آسان، مقیاس‌پذیری آنی و سیستم پرداخت ساعتی اشاره کرد. مشابه این سرویس را می‌توانید در شرکت‌های هاستینگ ابری در ایران مانند ابر آروان بیابید. با انتقال پایگاه داده از سرورهای سنتی به سرور مجازی ابری EC2، می‌توانید دیتابیس ابری خود را پیاده‌سازی کرده و از مزایای زیرساخت ابری که پیش‌تر به آن‌ها اشاره کردیم بهره ببرید.

مزایای پیاده‌سازی دستی دیتابیس روی سرور مجازی EC2

در صورتی که شما هم مانند مثال ما در این مقاله از اینستنس‌های EC2 آمازون (یا زیرساخت‌های ابری دیگر با کیفیت مشابه) استفاده کنید، به چند مزیت بزرگ دست پیدا می‌کنید. اصلی‌ترین مزیت، مقیاس‌پذیری آنی است. به این نحو که در صورتی که با افزایش بازدید یا افزایش کوئری‌های دیتابیس، نیاز به منابع بیشتری داشتید می‌توانید با چند کلیک و بدون زمان قطعی، میزان منابع اینستنس EC2 آمازون خود را افزایش دهید تا حتی در زمان پیک، کاهش کارایی در سایت یا سرویس خود نداشته باشید. با توجه به مدل پرداخت pay per use، شما فقط برای همان ساعاتی که افزایش منابع داشته‌اید هزینه اضافه می‌پردازید.

توانایی گرفتن اسنپ‌شات از ماشین مجازی، رمزنگاری پارتیشن و کپی کردن ماشین مجازی از یک ناحیه یا دیتاسنتر به ناحیه یا دیتاسنتر دیگر از جمله مزایایی است که در صورت استفاده از سرور ابری EC2 آمازون به آن دست خواهید یافت.

معایب پیاده‌سازی دستی دیتابیس ابری روی EC2

در نگاه اول شاید عیب خاصی به این راهکار گرفته نشود، مخصوصا زمانی که از یک سرویس دهنده قوی مانند AWS استفاده می‌کنید! اما چند نکته وجود دارد که اشاره به آن‌ها خالی از لطف نیست.

اول اینکه حتما به هزینه‌های کناره در EC2 توجه کنید، از جمله هزینه پهنای باند. گرچه در AWS هزینه پهنای باند به ازای هر گیگابایت بسیار ناچیز است، اما در صورتی که مشتری پرمصرف هستید ممکن است افزایش محسوسی در فاکتور خود ببینید. همچنین اسنپ‌شات‌های (بکاپ های) EC2 روی فضای S3 آمازون ذخیره می‌شود، بنابرین اگر حجم EC2 شما و تعداد بکاپ‌هایی که از آن می‌گیرید زیاد است، هزینه S3 را هم مد نظر قرار دهید.

نکته دوم فضای ذخیره‌سازی اینستنس‌های EC2 است، به صورت پیش فرض SSD های معمولی (با iops حداکثر ۱۶۰۰۰) به سرورهای مجازی EC2 تخصیص داده می‌شود. در صورتی که بخواهید از فضای ذخیره‌سازی با iops بالا (تا ۶۴۰۰۰) استفاده کنید، باید هزینه بیشتری پرداخت کنید.

توجه! نکته اصلی که در این راهکار باید به آن توجه کنید این است که در صورت کوچ از سرورهای سنتی به ابری، الزاما دیتابیس شما افزایش کارایی یا سرعت نخواهد داشت. این فاکتور وابسته به کارایی ماشین مجازی ابری مورد استفاده شما و امکاناتی است که سرویس‌دهنده زیرساخت ابری در اختیار شما قرار می‌دهد، در صورتی که یک سرویس‌دهنده قدرتمند مانند آمازون را انتخاب کرده باشید، بهبود سرعت را هم در کنار دیگر مزایای زیرساخت ابری تجربه خواهید کرد. ولی اگر قصد خرید از یک هاستینگ ابری درجه ۳ را دارید باید کمی به شانس و دعا هم متوسل شوید.

استفاده از دیتابیس مدیریت شده RDS آمازون

سرویس دیتابیس مدیریت شده RDS جزو خدماتی بود که سال ۲۰۰۹ به لیست سرویس‌های AWS اضافه شد. این سرویس با پشتیبانی از پایگاه داده MySQL و با هدف ساده‌سازی نصب، راه‌اندازی و مدیریت دیتابیس‌های رابطه‌ای معرفی شد. این سرویس که جزو خدمات DBaaS قرار می‌گیرد نوعی SaaS است که علاوه برای میزبانی پایگاه داده در فضای ابری، مدیریت آن در سطح اپلیکیشن را هم انجام می‌دهد. از جمله ویژگی‌های سرویس دیتابیس مدیریت‌شده می‌توان موارد زیر را نام برد:

  • آپدیت خودکار دیتابیس
  • مانیتورینگ هوشمند
  • پشتیبان‌گیری خودکار
  • رپلیکیشن و تحمل خطا
  • دسترسی پذیری بالا

به عبارت دیگر، در صورت استفاده از پایگاه داده مدیریت شده RDS آمازون شما فقط مسئول طراحی اسکیم دیتابیس و بهینه‌سازی کوئری‌های خود هستید؛ بقیه موارد توسط AWS انجام می‌شود. در عکس زیر تفکیک وظایف شما و ارائه دهنده دیتابیس مدیریت شده به تصویر کشیده شده است.

aws rds dbaas

گرچه هزینه ساعتی اینستنس‌های دیتابیس RDS نسبت به EC2 بیشتر است، اما کلیه عملیات پایگاه داده، از نصب و پشتیبانی تا کانفیگ تخصصی دیتابیس از دوش شما برداشته می‌شود. بنابراین، عدم نیاز شما به ادمین دیتابیس (DBA) در کاهش هزینه‌های شما تاثیر زیادی خواهد داشت. اگر هم تاکنون وظایف پایگاه داده به دوش دولوپرهای شما بوده، با خالی شدن زمان‌شان می‌توانند تمرکز بیشتری روی کار تخصصی خودشان، که توسعه محصول شماست، داشته باشند. لازم به ذکر است که تحقیقاتی که در این زمینه انجام شده از افزایش چشمگیر کارایی آن‌ها حکایت دارد.

جدول زیر مقایسه‌ای از قیمت ماهیانه اینستنس‌های EC2 و RDS با منابع مشابه در AWS را نشان می‌دهد.

EC2 – m4.large RDS – db.m4.large

RDS – db.m4.large – Multi-AZ 

هسته پردازشگر ۲ ۲ ۲
رم ۸ گیگابایت ۸ گیگابایت ۸ گیگابایت
فضای ذخیره‌سازی

۵۰ گیگابایت

General SSD

۵۰ گیگابایت

General SSD

۵۰ گیگابایت

General SSD

قیمت ماهانه ۷۷.۳۲ دلار ۱۳۳.۸۵ دلار ۲۶۷.۷۰ دلار

همانطور که مشاهده می‌کنید قیمت دیتابیس ابری مدیریت‌شده AWS تقریبا ۷۵ درصد بیشتر از اینستنس EC2 با منابع مشابه است. همچنین در صورت استفاده از پلن Multi-AZ با نود رپلیکیشن، هزینه شما دو برابر می‌شود.

کدام راهکار را انتخاب کنیم؟

اگر سرویس یا اپلیکیشنی که روی پایگاه داده میزبانی می‌کنید حساسیت بالایی دارد، حتما از دیتابیس مدیریت‌شده Multi-AZ استفاده کنید.

اگر سازمان شما دارای تیم متخصص پایگاه داده است و می‌خواهید روی پایگاه داده خود کنترل صد در صد داشته باشید، می‌توانید از اینستنس EC2 برای میزبانی پایگاه داده استفاده کنید.

در موارد کلی استفاده از سرویس دیتابیس مدیریت‌شده عادی پیشنهاد می‌شود.

دیتابیس مدیریت شده پنکیک

سکوی دیتابیس ابری پنکیک، اولین و تنها ارائه دهنده دیتابیس مدیریت شده در ایران است که پایگاه‌داده‌های MySQL، MongoDB و PostgreSQL را به صورت سرویس (DBaaS) روی بهترین دیتاسنترهای ایران و خارج ارائه می‌دهد. چنانچه سایت یا سرویس شما در ایران میزبانی می‌شود یا پرداخت هزینه بالای دلاری AWS برای شما میسر نیست، می‌توانید در پلتفرم دیتابیس پنکیک از کلیه ویژگی‌های دیتابیس‌های مدیریت شده استفاده کنید. در جدول زیر مقایسه پلن‌های تکی و مولتی نود سرویس دیتابیس آمازون با پلن‌های مشابه آن در پنکیک مقایسه شده است.

RDS – db.m4.large Pancake DBaaS – 4- Instance RDS – db.m4.large – Multi-AZ

Pancake DBaaS – 4-Instance Replication

هسته پردازشگر ۲ ۴ ۲ ۴
رم ۸ گیگابایت ۸ گیگابایت ۸ گیگابایت ۸ گیگابایت
فضای ذخیره‌سازی

۵۰ گیگابایت

General SSD

۴۰ گیگابایت

High iops NVMe

۵۰ گیگابایت

General SSD

۴۰ گیگابایت

High iops NVMe

قیمت ماهانه ۱۳۳.۸۵ دلار ۹۰۰.۰۰۰ تومان ۲۶۷.۷۰ دلار ۱.۸۰۰.۰۰۰ تومان

Online Shopping

نقش دیتابیس در کسب و کارهای آنلاین

با رشد تکنولوژی، تعداد افرادی که به صورت آنلاین به تجارت و خرید و فروش مشغول هستند نیز رشد خواهد کرد. تجارت الکترونیک که تحت عنوان e-commerce نیز شناخته می‌شود، مدلی از خرید و فروش است که به صورت آنلاین انجام می‌شود. هر فروشگاه ، کسب و کار یا شخص حقیقی که نسبت به فروش آنلاین محصولات خود اقدام می‌کند، بخشی از تجارت اکترونیک است. در سال ۲۰۱۸ مبادلات موبایلی افزایشی ۵۵ درصدی را شاهد بود و پیش‌بینی میشود که این رقم به ۱۷۵ میلیارد دلار برسد.

هر تجارت آنلاین موفق در پس‌زمینه از سیستمی بهره می‌برد که در موفقیت هر سیستم فروش آنلاین نقشی کلیدی را بازی می‌کند: این سیستم همان دیتابیس یا پایگاه داده است. با افزایش روز افزون حجم ترافیک وب‌سایت‌های فروش آنلاین، دیتابیس هر سایت بایستی قادر باشد تا این حجم را به خوبی مدیریت کند. با مطمئن شدن از پروسه‌های انجام شده در هر تجارت آنلاین که داشتن دیتابیس کارآمد بخش مهمی از آن است، هر کسب و کار آنلاین قادر خواهد بود که به خوبی شکل گرفته و در مقابل سایرین حرفی برای گفتن داشته باشد.

دیتابیس چیست؟

اگر تا به حال اسم دیتابیس ابری یا عبارات مشابه به گوش‌تان خورده باشد، همه این عبارات به صورت کلی به پایگاه داده هر وبسایت اشاره دارند. وظیفه اصلی یک پایگاه داده، ذخیره اطلاعات دیجیتالی است که میتوان از آن‌ها برای بازیابی در زمان‌ آتی استفاده کرد. از طریق این سیستم، اطلاعاتی نظیر تراکنش‌های سیستم میتوانند بر اساس تنظیمات انتخاب شده سازمان‌دهی شوند. همچنین شرکت‌ها این توانایی را خواهند داشت که اطلاعات مربوط به فروش محصولات، فروش و مشتریان خود را همیشه در اختیار داشته و آن ها را آنالیز کنند.

فراهم‌سازی ساختار

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

جذب مشتری

دیتابیس به تجارت‌های آنلاین کمک می‌کند تا با آنالیز اطلاعات جمع‌آوری شده، مشتریان بیشتری را جذب کند. تیم‌های بازاریابی شما می‌توانند از داده‌های مشتریان استفاده کرده و بر اساس اطلاعات جمع‌آوری شده از مشتریان، به رشد تجارت شما کمک کنند. هر چه اطلاعات بیشتری در اختیار تیم‌ مارکتینگ شما قرار گیرد، به صورت بهینه‌تری خواهند توانست مشتریان آینده را مورد هدف قرار دهند. این روش نه تنها به حفظ مشتریان کمک می‌کند بلکه به کسب مشتریان جدید نیز کمک می‌کند.

ردیابی داده‌ها

پایگاه داده‌ها بخشی جدایی ناپذیر از موفقیت یک سایت و تجارت آنلاین هستند. با توانایی ذخیره‌سازی، سازمان‌دهی و تجزیه و تحلیل مقادیر عظیمی از داده‌ها،‌ جای تعجبی نیست که چرا وجود یک دیتابیس که همواره به صورت موثر کار کند، امری ضروری است. با استفاده از داده‌های سازمان یافته و به روز،‌ شرکت‌ها می‌توانند به سرعت نسبت به تغییراتی که در مارکت به وجود می‌آید، تغییر عملکرد دهند.

موارد زیر انواع مختلفی از داده‌ها هستند که به تجارت‌های آنلاین کمک می‌کند تا مسیر موثری را در پیش گیرند:

اطلاعات محصول

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

اطلاعات مشتریان

در اختیار داشتن اطلاعات مشتری به فروشگاه‌های آنلاین کمک می‌کند تا تجزیه و تحلیل دقیق‌تری در راستای اطلاعات بازاریابی خود انجام دهند. به عنوان مثال، جزئیات دموگرافیک‌های شخصی مشتریان می‌تواند کالاهای با پتانسیل خرید بیشتر را برای شما مشخص‌ کند. مجموع داده‌هایی از این نوع به ایجاد بازار هدف متمایزتری کمک کرده و امکان بهبود اطلاعات مشتریان‌تان را برای شما فراهم می‌کند. هر زمان که بتوانید تشخیص دهید مشتریان‌تان بیشتر خواهان چه کالاهایی هستند، مشکلات و مسائل‌تان آسان‌تر حل خواهد شد.

اطلاعات تراکنش‌ها

پیگیری و مدیریت تراکنش‌ها یکی از مهم‌ترین کارهایی ست که یک پایگاه داده می‌تواند برای یک وب‌سایت انجام دهد. پیگیری سفارشات و تراکنش‌ها به شیوه‌ای سازمان‌یافته و همراه با جزئیات آن، کلید حفظ عملکرد هر کسب و کار است. دیتابیس‌ها بعد از انجام هر تراکنش موجودی هر محصول را به طور خودکار آپدیت می‌کنند.

در پایان بایستی گفت که پایگاه داده‌ها برای وب‌سایت‌‌های فروش آنلاین بسیار کارآمد و حیاتی هستند. چه شما یک شرکت کوچک با داده‌‌های محدود را اداره می‌کنید و یا یک تجارت بزرگ با میلیون‌ها محصول در اختیار دارید؛ در اختیار داشتن یک دیتابیس کارآمد برای سازمان‌دهی داده‌ها برای‌ بقا و پیشرفت کسب و کارتان حیاتی است.

سکوی ابری پنکیک با در اختیار داشتن تیمی حرفه‌ای، انواع دیتابیس‌های SQL و NoSQL کاربردی نظیر پست‌گرس کیو ال، MySQL، مونگو دی بی، اینفلاکس‌دی‌بی و … را به صورت ابری ومدیریت شده (DBaaS) روی دیتابیس انتخابی شما ارائه می‌کند تا اطلاعات و تراکنش های مربوط به تجارت الکترونیک شما به بهترین نحو مدیریت و محافظت شود. دیتابیس های ابری و رپلیکاهای هوش تجاری پنکیک از طرفی به رونق کسب و کارتان کمک کرده و از سوی دیگر با در نظر گرفتن تمام تمهیداتی که رعایت آن‌ها برای یک پایگاه داده ضروری است، خیال شما را بابت مدیریت امور هوش تجاری و آنالیز داده آسوده می‌کند. ویژگی‌های منحصر به فرد دیتابیس پنکیک نظیر بک ‌آپ های لحظه‌ای و امنیت بالا همیشه رضایت خاطر مشتریانش را به همراه داشته و انگیزه این تیم برای حفظ کیفیت خدمات پایگاه داده را بالا می‌برد.

pancake dbaas

دیتابیس ابری رایگان

خبر خوب برای استارتاپ‌ها و شرکت‌های دانش بنیان! با ثبت دیتابیس ابری پنکیک در سامانه ایران نوآفرین، شرکت‌های دانش بنیان هم اکنون می‌توانند تا ۶ ماه از سکوی پایگاه داده ابری پنکیک به صورت رایگان استفاده کنند.

نحوه دریافت اعتبار رایگان دیتابیس ابری

برای بهره‌مندی از خدمات رایگان سکوی ابری پنکیک کافی است در سایت ایران نوآفرین ثبت نام نموده و کد نوآفرین خود را دریافت نمایید. سپس با نام کاربری که از سایت ایران نوآفرین دریافت نموده‌اید وارد پرتال شده و از قسمت شرکت‌های ارائه دهنده خدمات بوم واره، دیتابیس ابری پنکیک را انتحاب کنید. سپس از آدرسی که در سایت بوم واره در اختیار شما قرار داده می‌شود، وارد سامانه پایگاه داده ابری پنکیک شوید.

بعد از ورود به سامانه دیتابیس ابری پنکیک، کد نوآفرین خود را وارد کنید. پس از تایید کد نوآفرین شما توسط سامانه، یک حساب کاربری مخصوص شما در سامانه پایگاه داده پنکیک ایجاد می‌شود. این حساب کاربری به اندازه قیمت دیتابیس ابری دارای شارژ ریالی است، بنابراین خواهید توانست دیتابیس ابری مورد نظر خود را به صورت رایگان ایجاد نمایید.

ایران نوآفرین دیتابیس ابری

محدودیت استفاده از دیتابیس ابری رایگان

میزان شارژ رایگان خدمات دیتابیس ابری پنکیک برای هر شرکت دانش بنیان که از طرف سامانه ایران نوآفرین مورد تایید قرار گرفته، نهایتا ۶ ماه است. پس از اتمام ۶ رایگان، امکان استفاده از پایگاه داده ابری تا ۶ ماه دیگر به صورت نیم بها وجود دارد.

مهلت استفاده از دیتابیس ابری رایگان

برای استفاده از خدمات پایگاه داده ابری پنکیک به صورت رایگان محدودیت زمانی وجود ندارد اما توجه کنید که تعداد خدمات رایگان سکوی ابری پنکیک محدود است و این احتمال وجود دارد که ظرفیت مذکور در زمان اندکی تکمیل شود. بنابراین توصیه می‌کنیم که در اسرع وقت نسبت به دریافت دیتابیس ابری خود اقدام کنید.

آیا اعتبار رایگان دیتابیس ابری شامل پایگاه داده ی خاصی است؟

خیر. امکان استفاده از هر کدام از دیتابیس های ابری MySQL، PostgreSQL،  MongoDB و InfluxDB با اعتبار رایگان وجود دارد.

در ثبت نام سامانه ایران نوآفرین به مشکل خوردم، با شما تماس بگیرم؟

متاسفانه سکوی پایگاه داده ابری پنکیک نمی‌تواند کمکی در ثبت نام شما در سامانه ایران نوآفرین بکند. لطفا در صورت بروز مشکل با شماره تلفن‌های سامانه ایران نوآفرین تماس بگیرید.

 

۷ نکته مهم در بکاپ گیری دیتابیس

اگر به دنبال بهترین استراتژی برای بکاپ‌گیری دیتابیس‌های خود هستید، این مطلب بایدهای یک سیاست خوب برای تهیه و مراقبت بکاپ های دیتابیس را برای شما تشریح می‌کند. همین که در حال خواندن این مقاله هستید به این معنی است که از نقش حیاتی بکاپ در پایگاه داده های با خبر هستید. بک‌آپ‌های زمان بندی شده بهترین راه برای حفاظت از پایگاه داده‌های شما است. در زیر فهرستی از بهترین شیوه‌های بکاپ گیری و بازیابی پایگاه داده آورده شده است که هر ادمین دیتابیسی باید آن‌ها بداند و از آن‌ها پیروی کند.

 

بهترین راهکارهای بک ‌آپ و ریکاوری دیتابیس

 

  • ذخیره داده‌ها و فایل‌های پشتیبان بر روی حافظه‌های مختلف

همانطور که می‌دانید ذخیره کردن بک‌آپ‌های دیتابیس و فایل‌های دیتابیس بر روی درایو لوکال (یا همان درایو محلی) یکسان کار چندان درستی نیست. دلیل این موضوع این است که اگر خرابی برای درایو محلی شما اتفاق بیافتد، هم دیتابیس خود را از دست خواهید داد و هم بک‌آپ‌هایی که از قبل تهیه کرده‌اید. به همین دلیل اولین نکته در تهیه بک‌آپ همین موضوع است. بک‌آپ‌های دیتابیس خود را بر روی مکان‌های مختلف ذخیره کنید. در نگاه اول ممکن است این موضوع بسیار پیش پا افتاده به نظر برسد اما ممکن است حجم عظیمی از داده‌های خود را از دست بدهید.

البته این بدان معنی نیست که در حافظه محلی دیتابیس، بکاپ نداشته باشید. داشتن بکاپ دیتابیس روی همان هارد یا SSD ی پایگاه داده به شما کمک خواهد کرد تا در صورت نیاز به اجرای یکی از بکاپ‌های پیشین، این کار را با سرعت بیشتری انجام دهید.

 

  • بک‌آپ‌های دیتابیس را طبق برنامه تعیین شده تهیه کنید

نکته بعدی در مورد بک‌آپ و ریکاوری، تعیین یک جدول زمان‌بندی شده برای تهیه بک‌آپ‌ها ست. همیشه بایستی یک برنامه برای گرفتن بک‌اپ‌ها داشته باشید و از آن استفاده کنید چرا که بعد از گذشت زمان مشخص، ریسک از دست رفتن داده بالا می‌رود. بنابراین، برنامه شما باید همیشه بکاپ های اخیر را حفظ کردی و نسخه های قدیمی که فقط فضای ذخیره سازی را اشغال می‌کنند، پاک کند.

 

  • از سلامت بک‌آپ‌های خود با بازگردانی آن‌ها در سرور تست مطمئن شوید

احتمالا همیشه باید از این موضوع مطمئن شوید که تهیه نسخه پشتیبان از دیتابیس‌تان با موفقیت انجام شده و بکاپ‌های دیتابیس به خوبی اجرا می‌شوند. برای تست این موضوع بایستی بک‌اپ‌های خود را روی سرور تست ری استور کرده تا از درستی آن‌ها مطمئن شوید. بدون انجام عملیات ریکاوری هرگز مطمئن نخواهید بود که بک‌آپ‌های صحیح در اختیار دارید.

 

  • استراتژی ریکاوری خود را تست کنید

نکته بعدی در مورد انتخاب بهترین روش برای بک‌آپ و ریکاوری، استراتژی‌های ریکاوری یا همان پلن خروج از بحران (Disaster Recovery) است.

فرض کنید که در یک کمپانی بزرگ مشغول به کار هستید. اگر دیتابیس‌تان با خرابی مواجه شود چه می‌کنید؟ چه مقدار زمان احتیاج دارید تا دیتابیس خود را ری‌استور کنید؟ این سوالات دلیلی است برای تست دیتابیس خود بر روی یک سرور تست و بررسی استراتژی‌های متفاوت که هنگام وقوع بحران به آن احتیاج خواهید داشت.

 

  • در طول پروسه بک‌آپ تمام آپشن‌های وریفیکیشن را در نظر بگیرید

نکته مهم دیگری که بایستی برای بک‌آپ و ریکاوری در نظر بگیرید این است که تمام آپشن‌های وریفای کردن را در طول بک‌آپ در نظر بگیرید. استفاده از این آپشن‌ها به شما این اطمینان را می‌دهد که مطمئن شوید که تمام بک‌آپ هایی که درست کردید، به طور صحیح کار می‌کند. به عنوان مثال اگر می‌خواهید فایل‌های بکاپ دیتابیس را به سرور دیگری منتقل کنید، حتما با استفاده از توابع هش (Hash) از انتقال درست فایل‌های بکاپ مطمئن شوید.

 

  • حداقل از دیتابیس خود به صورت روزانه فول بکاپ بگیرید

ما همیشه پیشنهاد می‌کنیم که به صورت روزانه از دیتابیس خود فول بک‌آپ بگیرید. این بهترین راه برای حفاظت از دیتابیس و از دست ندادن داده‌هاست. این زمان با توجه به مدت زمانی که شما برای از دست دادن اطلاعات خود پذیرفته‌اید، متفاوت خواهد بود. به عنوان مثال، اگر فقط از دست دادن اطلاعات یک ساعت گذشته برای شما و بقای کسب و کارتان قابل قبول است، پس بایستی هر یک ساعت از دیتابیس‌های خود فول بکاپ بگیرید. ممکن است فکر کنید فول بکاپ‌های ساعتی دشوار و هزینه بر هستند، اما اگر از سرویس پایگاه داده (سکوی دیتابیس)‌ استفاده کنید، خواهید توانست حتی در بازه‌های زمانی کمتر از یک ساعت از دیتابیس‌های خود فول بکاپ داشته باشید.

 

  • از یک دیتابیس رپلیکیشن (replication) متعدد اجرا کنید

به این مورد اشاره کردیم که تهیه بک‌آپ به صورت کامل در هر روز ضروری است. در کنار داشتن بکاپ های منظم، داشتن نسخه های کلون یا رپلیکا از پایگاه داده‌ها نیز کمک زیادی در زمان بحران یه شما می کنند. داشتن نسخه رپلیکا از دیتابیس،‌ نه تنها یک نسخه کاملا بروز از دیتابیس شما روی یک سرور دیگر فراهم میکند، بلکه با اجرای بخشی از کوئری های خود روی دیتابیس های رپلیکا، بار اضافه از روی پایگاه داده اصلی شما برداشته خواهد شد.

 

سکوی دیتابیس ابری

موارد بالا در بکاپ و بازگردانی دیتابیس، همه از نکات مهمی هستند که باید در پلن خروج از بحران هر سازمانی وجود داشته و ادمین دیتابیس به آن‌ها مشرف باشد. ممکن است در نگاه اول رعایت همه این نکات کمی سخت و غیرعملی به نظر برسد، اما با استفاده ارائه‌دهندگان خدمات ابری دیتابیس، مانند سرویس پایگاه داده پنکیک، همه این موارد را در یک پکیج جامع خواهید داشت.

  • با استفاده از سرویس دیتابیس پنکیک خواهید توانست:
  • دیتابیس خود را تنها با چند کلیک روی دیتاسنتر و کشور انتخابی خود راه اندازی کنید.
  • از دیتابیس‌های خود در بازه‌های زمانی کمتر از یک ساعت فول بکاپ تهیه کنید.
  • فول بکاپ دیتابیس خود را در کمتر از یک دقیقه راه اندازی کنید.
  • از پایگاه داده‌های خود نسخه رپلیکا اجرا کنید.
  • از فضای سخت افزار قوی و ذخیره سازی پرسرعت با iops بالا برای دیتابیس های خود استفاده کنید.
  • بکاپ های روزانه دیتابیس خود را به سرورهای ریموت منتقل کنید.
  • با فایروال اختصاصی، از عدم دسترسی سرورهای غیرمجاز به دیتابیس‌های خود اطمینان حاصل کنید.

با استفاده از سکوی دیتابیس پنکیک، همه ویژگی‌های فوق را در اختیار خواهید داشت.

بکاپ و ریکاوری دیتابیس

توانایی بک آپ یک دیتابیس، در کنار یکپارچگی بک‌آپ و بازگردانی کامل داده‌ها، از جمله مواردی مهمی است که به حیات یک کسب و کار کمک بسیاری می‌کند. در بسیاری از موارد، بازرسان آی‌تی بدون در نظر گرفتن یکپارچگی و یا سلامت بکاپ، تنها تایید می‌کنند که آیا روند بک آپ‌ گیری بر روی دیسک در حال انجام است یا خیر.

این مقاله موضوعات مربوط به از دست دادن داده و انواع بک‌آپ‌های دیتابیس و روش‌های ریکاوری را بررسی می‌کند. هم چنین بهترین روش‌هایی که می‌تواند به ادمین دیتابیس در ارزیابی اثربخشی پشتیبانی از پایگاه داده و بازیابی کمک کند نیز ارائه شده است. این مقاله بیشتر بر روی تکنولوژی و توانایی‌های سیستم دیتابیس اوراکل و SQL Server مایکروسافت تمرکز دارد چرا که این دو سیستم به صورت تخمینی ۴۰ درصد پایگاه داده‌های موجود را تشکیل می‌دهند.

یکی از مسئولیت‌های کلیدی ادمین دیتابیس آمادگی برای خرابی سخت‌افزار، نرم‌افزار و مدیا، و همچنین بازگردانی آن در زمان حادثه (Disaster Recovery) است. با فرض این که هرکدام از این خرابی‌ها اتفاق بیافتد، کاربران باید بتوانند در کمترین زمان به داده‌های قبلی خود و بدون خرابی، دسترسی داشته باشند. در نتیجه یک ادمین دیتابیس بایستی قادر باشد که به سوالات زیر پاسخ دهد.

 

  • ادمین دیتابیس چطور اطمینان حاصل می‌کند که اطلاعاتی که شرکت به آن وابسته است با موفقیت بک‌آپ شده و می‌توان از این بک‌آپ‌ها در محدوده زمانی مجاز SLA و یا زمان بازیابی هدف (که در پلن بازگشت از حادثه سازمان وجود دارد)، استفاده کرد؟
  • آيا ادمین دیتابیس اقداماتی را برای تهیه پیش‌نویس و آزمایش روش‌های حفاظت و بهبود پایگاه داده با استفاده از انواع وقوع خرابی را اتخاذ کرده است؟

 

در زیر یک چک‌لیست برای روش‌های بازیابی اطلاعاتی آورده شده است که در این مقاله توضیح داده می‌شوند:

  • توسعه یک پلن بک‌آپ جامع
  • اجرای مدیریت بک‌آپ موثر
  • ری‌استور دوره‌ای دیتابیس
  • همراه داشتن پلن ریکاوری برای مواقع خرابی
  • آپدیت نگه داشتن دانش خود و ابزار مربوط به بکآپ و ریکاوری دیتابیس

 

پلن جامع بکاپ دیتابیس

ادمین‌های دیتابیس مسئول ایجاد یک طرح پشتیبانی جامع برای پایگاه داده‌ها هستند. طرح پشتیبان باید شامل انواع سیستم‌های مدیریت دیتابیس رابطه‌ای شود و بایستی نواحی زیر را پوشش دهد:

 

  • تصمیم‌گیری برای این‌که چه چیزی را بک‌آپ بگیریم: ضروری است که ادمین دیتابیس از پایگاه داده و اجزای کاربردی مربوطه که بایستی از آن‌ها بکآپ گرفته شود مطلع شود. چه از طریق یک سیستم بکآپ گیری آنلاین و چه آفلاین. در زیر مواردی که بایستی بک آپ گرفته شوند ذکر شده است:

 

  • نرم افزار سیستم عامل: رویدادی مثل خرابی سخت افزاری نیاز به ری‌استور کامل سیستم دارد، که با سیستم عامل شروع میشود. بنابراین نیاز به بکاپ از دیتابیس سرور سیستم عامل در ابتدا و بعد از آن بروزرسانی و تغییرات پیکربندی وجود دارد.
  • نرم‌افزار مدیریت دیتابیس رابطه ای: RDBMS باید در ابتدا و بعد از هر آپگرید و یا پچ بکاپ گرفته شود.
  • پسوردها: همه گذرواژه هایی که ممکن است در طول بازیابی مورد نیاز باشد باید حفظ شوند. ایده‌ای خوب برای اطمنیان از اینکه رمزهای عبوری که به طور پیش فرض همراه با نصب به وجود آمده اند، تغییر کرده است.
  • بکاپ گیری از همه دیتابیس های سیستم و کاربر.

 

 

بک آپ‌های لاجیکال:

در سیستم های مدیریت دیتابیس، می‌توان جدول‌ها و شمای دیتابیس ها را در هریک از فرمت‌های فایل که پشتیبانی میشوند بک آپ گرفت. سپس فایل های بکاپ گرفته شده را با استفاده از ابزارهای import and export  بازیابی کرد. این نوع بکاپ برای بازگردانی های سطح سیستم عامل توصیه نمی شود، چراکه معمولا فقط شامل اطلاعات ساختاری پایگاه داده هستند.

 

بک آپ‌های فیزیکی:

توصیه میشود که همه پایگاه داده های کاربر برای بازیابی کامل به صورت فول بکاپ پشتیبان گیری شوند تا هم دیتابیس‌‌ها و هم فایل‌های لاگ پایگاه داده را تا نقطه خرابی بازیابی کنند. ادمین‌های دیتابیس بایستی به طور کامل خود را با مدل‌های بازیابی دیتابیس آشنا کنند و این اطلاعات را بر اساس آن تنظیم کنند.

 

تعیین یک برنامه زمان بندی مناسب:

یکی از اقداماتی که میتوان انجام داد این است که پنجره پشتیبان گیری را در زمانی تعیین کنیم که کم ترین مقدار فعالیت بر روی پایگاه داده ها در حال انجام است و در نتیجه بک‌آپ‌ها نتوانند سرعت کاربرانی که در حال انجام فعالیت‌های خود هستند را کاهش دهد. ادمین دیتابیس میتواند بکآپ‌ها را با استفاده از موازی‌سازی کانال‌های مختلف تنظیم کند. با این حال هر ادمین دیتابیس بایستی ورژن دیتابیس مورد نظر خود را بررسی کند تا از وجود این آپشن مطمئن شود. در اکثر موارد بهتر است که یک چرخه بک‌آپ به صورت هفتگی راه اندازی کنید. اما بک آپ میتواند به صورتی ساعتی نیز انجام شود.

 

کجا بکاپ پایگاه داده را ذخیره کنیم:

بک آپ های پایگاه داده میتوانند به طور مستقیم بر روی دیسک ذخیره شوند. بک‌آپ‌های دیسکی سریع تر هستند و امکان مانیتورینگ بهتری نیز در اختیار شما خواهند گذاشت، همچنین زمان بازگردانی بهتری (MTTR) خواهند داشت.

 

تهیه پالیسی بکاپ‌ها:

سیاست بک‌آپ‌های بایستی بر اساس SLA‌‌ای باشد که توسط جامعه تجاری هر شرکت درباره آن تصمیم گیری شده است. همواره دارنده دیتا بایستی دوره‌ای که داده را در دست دارد را تعیین کند. این دوره ممکن است بین ماه‌ها تا سال‌ها طول بکشد. در نتیجه هر ادمین دیتابیس بایستی مدیریت این موضوع را به خوبی در دست داشته باشد و یک استراتژی برای پاک کردن داده‌های قدیمی و اضافه کردن داده‌های جدید داشته باشد.

 

 

مدیریت بک آپ پایگاه داده به صورت موثر:

بعد از تهیه یک برنامه پشتیبانی به صورت منسجم و تکمیل اقدامات اولیه، ادمین دیتابیس بایستی به صورت منظم بک‌آپ‌ها را منظم کند و نکات زیر را همیشه در ذهن داشته باشد:

 

  • مانیتور کردن بک‌آپ‌ها:

نظارت بر روی دیتابیس بایستی به صورت منظم انجام بگیرد، این نظارت‌ها بایستی با ابزارهای مختلف تنظیم شود به طوری که ادمین دیتابیس قادر باشد در صورت وقوع هر گونه خرابی، بر روی تلفن همراه خود یا هر بستر دیگری پیام دریافت کند.

 

  • لاگ بک‌اپ‌ها:

لاگ‌های پشتیبان و اطلاعات کاتالوگ بک‌آپ بایستی به صورت دوره‌ای بررسی شوند.

 

  • اعتبارسنجی بک‌آپ‌ها

اعتبارسنجی بک‌آپ‌ها را به صورت دوره‌ای انجام دهید تا در آینده به مشکل خاصی نخورید.

 

 

تست بازگردانی بک‌آپ‌های دیتابیس

سناریو زیر را تصور کنید:

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

بعد از آن، بک‌آپی که به صورت آف‌سایت نگهداری شده بازگردانی و لود می‌شود. ولی یک پیام بر روی صفحه پدیدار می‌شود که می‌گوید بک‌آپ به دلیل مشکلات یکپارچگی (Integrity) قابل خواندن نیست. چه مشکلی می‌تواند پیش آمده باشد؟

اتفاقات زیادی می‌تواند منجر به این موضوع شود. اما واضح است که یکی از اقدامات حیاتی بکاپ گیری پایگاه داده انجام نشده است! بله درست حدس زدید؛ تست بک‌آپ موجود هیچ‌وقت اتفاق نیفتاده است. در واقع در صورتی که تیم آی تی یا ادمین‌های دیتابیس نتوانند بک آپ‌ها را ری‌استور کنند، این بک‌آپ‌ها بلااستفاده خواهند بود. برای بازگردانی نسخه بک‌آپ، هر ادمین دیتابیس بایستی موارد زیر را با جزئیات انجام دهد:

 

  • تست بازگردانی (ریستور) دیتابیس‌ها: این مرحله بایستی همواره یک الزام برای تست پایگاه داده‌ای که از آن بک‌آپ تهیه شده باشد.
  • اعتبارسنجی ریستورها: ادمین دیتابیس بایستی قادر باشد بدون بازگردانی دیتابیس، بک‌آپ‌ها را اعتبارسنجی کند. این بهترین روش برای تعیین این است که آیا نسخه بک‌آپ خوب و قابل استفاده است یا خیر.
  • بازگردانی پایگاه داده در محیط غیرعملیاتی: یکی از روش های مناسب برای تست بکاپ های دیتابیس، بازگردانی و تست آن ها در محیط غیر عملیاتی است.

 

SLA‌ بک آپ و بازیابی دیتابیس

تیم ادمین دیتابیس بایستی داکیومنت SLA را که شامل جزئیات رویه‌های پشتیبان گیری و جدول زمانی برای بازیابی میشوند را تهیه کرده و تایید مدیریت برسانند. توجه داشته باشید که خود SLA‌ در روند بازیابی تاثیر خاصی نداشته و صرفا انتظارات از بازیابی را بیان می‌کند.

 

بازیابی دیتابیس در زمان خرابی

تیم دیتابیس باید اطمینان حاصل کند که پایگاه‌داده‌ها به عنوان یک عنصر کلیدی در شرکت در نظر گرفته می‌شوند. تمام سهام‌داران باید مولفه‌های بهبود برنامه را درک کنند و متوجه باشند که درچه صورتی تیم آی‌تی پایگاه داده را بازیابی می‌کند. شرکت بایستی پیش‌نیازهای این مرحله را فراهم داشته باشد؛ به طوری که اکثر برنامه‌های کاربردی در سریع‌ترین زمان ممکن در دسترس باشند.

 

ابزارهای ریکاوری پایگاه داده

واضح است که ادمین دیتابیس نقش آخر و مهم‌ترین نقش را در این فرآیند ایفا می‌کند. در نتیجه بایستی دانش فنی خود را درباره ابزارهای پشتیبانی و بازیابی همیشه به روز نگه دارد چرا که در طول فرآیند بازیابی وقت کافی برای یافتن ابزارهای لازم را نخواهد داشت.

 

 

نتیجه

وظیفه اصلی و اولیه هر تیم ادمین دیتابیس مرور تمام سیستم‌های موجود مدیریت دیتابیس در درون سازمان است. هدف از این کار برنامه ریزی یک روش پویا و یک نقشه اساسی برای پیاده‌سازی بک‌آپ‌ها و مانیتور کردن آن‌ها است. تمام این عملیات بایستی به گونه‌ای مدیریت شود که کم‌ترین نقص را داشته و زمان از دست رفته را نیز به کوتاه‌ترین کاهش دهد.

هنگامی که یک رویکرد ایجاد شد، لازم است که بازیابی داده‌ها به صورت دوره‌ای و به عنوان بخشی از استراتژی پشتیبانی و بازیابی به صورت واقعی انجام شود. مهم است که همواره ادمین یا تیم دیتابیس ما از آخرین ابزار پشتیبانی برخوردار است و مراحل و فرآیند انجام بازیابی اطلاعات را به وضوع تضمین می‌کند. اگر تیم دیتابیس یا ادمین ما، بک‌آپ مناسب را حفظ کند و آن‌ها را به طور کامل زیر نظر داشته باشد در واقع بخش عمده‌ای از شغل خود که برای آن استخدام شده‌اند را به درستی انجام داده اند.

 

بکاپ گیری و بازگردانی دیتابیس با استفاده از پنکیک

گرفتن نسخه پشتیبان از دیتابیس و بازگردانی سریع آن ها یکی از ویژگی های اصلی سرویس پایگاه داده پنکیک است. با استفاده از سرویس دیتابیس، علاوه بر میزبانی داده های خود روی سرورهای قدرتمند مخصوص پایگاه داده، خواهید توانست:

  • بصورت ساعتی از پایگاه داده فول بکاپ تهیه کنید.
  • بازگردانی هر فول بکاپ را در کمتر از ۱ دقیقه انجام دهید.
  • یک نسخه کلون از بکاپ دیتابیس خود را در محیط غیرعملیاتی بازگردانی نمایید.
a cloud and three databases

حمله به زیرساخت ابرآروان

در هفته های گذشته، تنها چند روز مانده به عید سال ۱۴۰۰ زیرساخت ابرآروان در دیتاسنتر آسیاتک از دسترس خارج شد. گزارش‌های اولیه حاکی از حمله به سرورهای آبر آروان در این دیتاسنتر بود، که با تلاش تیم ابرآروان اطلاعات کاربران به صورت تدریجی دوباره در دسترس قرار گرفت.

هک یا مشكلات زیرساخت، کسب و کارهای بسیاری از قطعی ابر آروان ضرر کردند

شما چه از مشتریان ابرآروان باشید یا نباشید، چه اخبار فناوری اطلاعات را دنبال بکنید یا نکنید، حتما تا اینجای کار را می‌دانید. ابعاد قضیه به اندازه‌ای بزرگ بود شبکه‌های خبری بزرگ داخلی و خارجی به صورت وسیع آن را پوشش دادند. گله اکثر کسب و کارهای بزرگی که روی ابرآروان میزبانی می‌شدند، مانند اپلیکیش مستر تیستر، هم در انتشار مشکلات این سرویس دهنده خدمات ابری تاثیر چشمگیری داشتند.

مشکل اصلی که گریبان‌گیر اکثر کسب و کارهایی که از ابر آروان برای میزبانی سایت یا اپلیکیشن خود استفاده می‌کردند، چیز دیگری بود. داون شدن خدمات این سایت‌ها در زمان پیک، عدم دسترسی به اطلاعات مشتریان و هم‌چنین تاثیرات منفی در سئو و رنک این کسب و کارها، تنها گوشه‌ای از ضرر و زیان این افراد هستند.

بازیابی اطلاعات مشتریان ابرآروان

در زمان نوشتن این مطلب، اطلاعات همه مشتریان  هنوز بصورت کامل بازیابی نشده است. در مورد علت این حادثه و میزان مسئولیت ابر آروان در زیان مشتریان مطالب بسیاری نوشته شده است. ما هم در این مطلب قصد نداریم به این موارد بپردازیم و امیدواریم تیم فنی ابر آروان با موفقیت سرویس مشتریان خود را بازیابی کرده باشد تا این کسب و کارها با حداقل تاخیر دوباره به کار خود ادامه دهند.

بازیابی داده‌ها در زمان قطعی وب سرویس

اما کسب و کارها چطور می‌توانند در آینده از مشکلات این چنینی پیشگیری کنند؟ اپلیکیشن‌ها و سایت‌ها چه اقداماتی باید انجام دهند تا زمان بحران‌های این چنینی کمترین قطعی را داشته باشند؟ کدام کسب و کارها در زمان هک زیرساخت ابر آروان در آسیاک کمترین داون تایم را داشتند و سریع تر سرویس‌های خود را بازیابی کردند؟ چه چیزی این کسب و کارها را از کسب و کارهایی دیگر متمایز می‌کند؟

تفکیک داده‌های حیاتی و غیرحیاتی برای درک بهتر موضوع امری ضروری‌ ست. برای تفیک بهتر این دو نوع داده می‌توان از این تعریف استفاده کرد:

داده‌های غیر حیاتی داده‌هایی هستند که در صورت از بین رفتن یا پاک شدن، امکان تولید مجدد آن ها وجود داشته باشد. یا بتوان در بازه زمانی که مشغول تولید مجدد آن هستیم، از نسخه قدیمی تر این داده ها استفاده کنیم. اکثر فایل ها و کدهای سایت از این دسته داده ها هستند. حتی اگر مخزن کد لوکال شما آپدیت نباشد یا از سیستم کنترل ورژن مثل گیت هم استفاده نکنید، می‌توانید با نسخه‌ای قدیمی‌تر،‌ سرویس خود را بازگردانی کنید.

داده‌های حیاتی داده‌هایی هستند در صورت از بین رفتن، امکان تولید مجدد آن‌ها وجود ندارد. تنها راه بازگردانی این اطلاعات از بکاپ است. اطلاعات کاربران، ثبت نام ها، تراکنش ها مالی و … از این دسته داده‌ها هستند. این داده ها غالبا در پایگاه داده یا همان دیتابیس ذخیره می‌شوند.

در واقع داده‌های اصلی و حیاتی هر کسب و کاری، پایگاه داده آن است. شما در صورت از دست رفتن عکس یا کد سایت خود، در بدترین حالت می‌توانید تا تولید مجدد آن، از نسخه‌ای قدیمی تر استفاده کنید. اما در صورت از دست دادن دیتابیس، تولید مجدد آن مقدور نیست.

خب حالا که به ضرورت داده های دیتابیس پی بردیم، باید دنبال روشی برای ذخیره امن آن باشیم که نه تنها آن را در برابر دسترسی غیرمجاز و هک مصون نگه دارد، امکان بک‌آپ با بازه های زمانی کوتاه مدت و همچنین بازگردانی بکاپ در اسرع وقت را داشته باشد. متاسفانه زیرساخت ابری ابرآروان نه تنها چنین ویژگی‌هایی برای دیتابیس ارائه نمی‌دهد و بلکه اصلا برای میزبانی پایگاه داده مناسب نیست؛ البته خود ابر آروان هم چنین ادعایی ندارد. ابرک‌های ابرآروان از استوریج ها ریموت استفاده می‌کند که پرفرمنس یا کارایی سیستم‌های مدیریت دیتابیس را به شدت کاهش می‌دهد.

استفاده از دیتابیس ابری

اما راهکار چیست؟ در این شرایط استفاده از دیتابیس ابری بهترین گزینه برای کسب و کارهای اینترنتی است. سرویس‌های دیتابیس روی سخت افزارهای بهینه برای پایگاه داده میزبانی می شوند تا کارایی سایت و اپلیکیشن شما را تضمین کنند. همچنین در صورت استفاده از سرویس دیتابیس، منابع سرور وب سرویس شما نیز آزاد می شود تا در کنار افزایش کارایی دیتابیس،‌ شاهد افزایش کارایی وب سرویس و در نهایت ساپورت کاربران آنلاین بیشتری باشید.

اما ویژگی های مذکور، مزیت های ذاتی یک سرویس پایگاه داده هستند. سرویس دیتابیس پنکیک علاوه بر این ویژگی‌ها، امکان پشتیبان گیری کامل (فول بکاپ) از دیتابیس شما به صورت ساعتی را دارا می باشد. همچنین بازگردانی دیتابیس از روی فول بکاپ در کمتر از ۱ دقیقه امکان پذیر است.

در کنار قابلیت منحصر به فرد بکاپ گیری و بازگردانی بکاپ،‌ سرویس پایگاه داده پینکیک دارای فایروال و شبکه اختصاصی برای هر سرویس دیتابیس است. به این صورت ترافیک سرویس های دیتابیس مشتریان از هم تفکیک شده و فایروال سرور نیز فقط امکان دسترسی به سرورهای مجاز را فراهم می‌کند.

با توجه به اینکه پنکیک روی دیتاسنترهای مختلف سرویس پایگاه داده ارائه می‌دهد، شما می‌توانید سرویس خود را در دیتاسنتری که سرور وب سرویس شما قرار دارد انتخاب کنید تا بیشترین کارایی را تجربه کنید. هم‌چنین امکان بکاپ گیری یا بازگردانی روی دیتاسنترهای مختلف به شما این اطمینان را می‌دهد تا حتی در صورت ایجاد بحران در یک دیتاسنتر، داده‌های خود را در اسرع وقت بازیابی کنید.