পূর্ণ ব্যাকআপের পরে আমি কীভাবে লেনদেন লগ ব্যাকআপের আকার হ্রাস করব?


38

২০০ S সালে স্কেল সার্ভারে চালনার জন্য আমার তিনটি রক্ষণাবেক্ষণ পরিকল্পনা রয়েছে:

  • একটি পূর্ণ ব্যাকআপের পরে সাপ্তাহিক ডাটাবেস অপ্টিমাইজেশন
  • প্রতিদিনের ডিফারেনশিয়াল ব্যাকআপ
  • প্রতি ঘন্টা লেনদেন লগ ব্যাকআপ

প্রতি ঘণ্টায় লগ ব্যাকআপগুলি কার্যকলাপের স্তরের উপর নির্ভর করে কয়েক শতাধিক কেবি এবং 10 এমবি এর মধ্যে থাকে, প্রতিদিনের পার্থক্যগুলি সাধারণত সপ্তাহের শেষে প্রায় 250Mb এর কাছাকাছি হয় এবং সাপ্তাহিক ব্যাকআপটি প্রায় 3.5 গিগাবাইট হয়।

আমার যে সমস্যাটি রয়েছে তা হ'ল সম্পূর্ণ ব্যাকআপের আগে অপটিমাইজেশনগুলি স্বাভাবিক ব্যাখ্যায় ফিরে আসার আগে এই ক্ষেত্রে 8 জিবি-র পরবর্তী লেনদেনের লগ ব্যাকআপটিকে পুরো ব্যাকআপের আকার 2x এরও বেশি বাড়িয়ে তুলবে।

অন্য চেয়ে BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLYনিশ্চয় তারা সম্পূর্ণ ব্যাকআপ তারা আগে বসে জন্য দায়ী করা হবে, কোনো উপায় আছে যে লগ ব্যাকআপ আকার কমাতে বা এ সব লেনদেন লগ লিপিবদ্ধ হওয়া থেকে optimisations প্রতিরোধ কে?


1
এই প্রশ্নের দ্বারা উত্পাদিত ধারণাগুলির আদান-প্রদানের কারণে +1 এটিকে উত্সাহিত করেছে।
মার্লোনআরবুনাল

উত্তর:


35

এখানে কিছু আকর্ষণীয় পরামর্শ, যা সকলেই লগ ব্যাকআপগুলি কীভাবে কাজ করে সে সম্পর্কে ভুল বোঝাবুঝি দেখায়। কোনও লগ ব্যাকআপে অন্তর্ভুক্তিতে পূর্ণ বা ডিফারেন্সিয়াল ব্যাকআপ নেওয়া যাই হোক না কেন, পূর্ববর্তী লগ ব্যাকআপের পরে থেকে তৈরি সমস্ত লেনদেনের লগ থাকে। লগ ব্যাকআপগুলি বন্ধ করা বা প্রতিদিনের পূর্ণ ব্যাকআপগুলিতে যাওয়া লগ ব্যাকআপ আকারগুলিতে কোনও প্রভাব ফেলবে না। একবার লগ ব্যাকআপ চেইন শুরু হয়ে গেলে লেনদেনের লগকে প্রভাবিত করে কেবল লগ ব্যাকআপ।

এই নিয়মের একমাত্র ব্যতিক্রম হ'ল লগ ব্যাকআপ চেইনটি যদি ভেঙে ফেলা হয় (যেমন সিম্পল পুনরুদ্ধারের মডেলটিতে গিয়ে একটি ডাটাবেস স্ন্যাপশট থেকে ফিরে, NO_LOG / TRUNCATE_ONLY এর সাথে BACKUP LOG ব্যবহার করে লগটি কাটা), সেক্ষেত্রে প্রথম লগ ব্যাকআপ শেষ পূর্ণ ব্যাকআপের পর থেকে সমস্ত লেনদেনের লগ থাকবে - যা লগ ব্যাকআপ চেইন পুনরায় আরম্ভ করে; অথবা যদি লগ ব্যাকআপ চেইনটি শুরু না করা হয় - আপনি যখন প্রথমবারের মতো পুরোপুরি স্যুইচ করেন, প্রথম পূর্ণ ব্যাকআপ না নেওয়া পর্যন্ত আপনি এক ধরণের সিউডো-সিম্পল পুনরুদ্ধারের মডেলটিতে কাজ করেন।

আপনার মূল প্রশ্নের উত্তর দিতে, সিম্পল পুনরুদ্ধারের মডেলটিতে না গিয়ে, আপনাকে সমস্ত লেনদেনের লগ ব্যাক আপ করতে হবে। আপনি যে পদক্ষেপ নিচ্ছেন তার উপর নির্ভর করে আপনি তাদের আকার হ্রাস করতে আরও ঘন ঘন লগ ব্যাকআপ নিতে পারেন, বা আরও লক্ষ্যযুক্ত ডাটাবেস করতে পারেন।

আপনি যদি করছেন যে রক্ষণাবেক্ষণ অপ্স সম্পর্কে কিছু তথ্য পোস্ট করতে পারেন তবে আমি সেগুলি অনুকূল করতে আপনাকে সহায়তা করতে পারি। আপনি কি কোনও সুযোগেই সূচী পুনর্নির্মাণগুলি ব্যবহার করে সূচকগুলি পুনর্নির্মাণের দ্বারা ব্যবহৃত স্থানটি পুনরায় দাবি করতে একটি সঙ্কুচিত ডাটাবেস অনুসরণ করছেন?

রক্ষণাবেক্ষণের সময় ডেটাবেসটিতে আপনার অন্য কোনও ক্রিয়াকলাপ না থাকলে আপনি নিম্নলিখিতটি করতে পারেন:

  • নিশ্চিত করুন যে ব্যবহারকারীর কার্যকলাপ বন্ধ রয়েছে
  • একটি চূড়ান্ত লগ ব্যাকআপ নিন (এটি আপনাকে রক্ষণাবেক্ষণের শুরু পর্যন্ত ঠিক পুনরুদ্ধার করতে দেয়)
    • সিম্পল পুনরুদ্ধারের মডেলটিতে স্যুইচ করুন
    • রক্ষণাবেক্ষণ সম্পাদন করুন - প্রতিটি চেকপয়েন্টে লগটি কেটে যাবে
    • সম্পূর্ণ পুনরুদ্ধারের মডেলটিতে স্যুইচ করুন এবং একটি পুরো ব্যাকআপ নিন
    • স্বাভাবিক হিসাবে চালিয়ে যান

আশা করি এটি সহায়তা করে - আরও তথ্যের প্রত্যাশায়।

ধন্যবাদ

[সম্পাদনা করুন: একটি সম্পূর্ণ ব্যাকআপ পরবর্তী লগ ব্যাকআপের আকার পরিবর্তন করতে পারে কিনা তা নিয়ে সমস্ত আলোচনার পরেও (এটি পারে না) আমি ব্যাকগ্রাউন্ড উপাদান এবং এটি প্রমাণিত একটি স্ক্রিপ্ট সহ একটি বিস্তৃত ব্লগ পোস্ট একসাথে রেখেছি। এটি https://www.sqlskills.com/blogs/paul/misconferences-around-the-log-and-log-backups-how-to-convince-yourself/] এ দেখুন


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

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

এমনকি এটি সূচকের রক্ষণাবেক্ষণের পরে লগ ব্যাকআপের আকার কীভাবে কমিয়ে আনতে ওপির মূল প্রশ্নে সহায়তা করে না - বাস্তবে কী কী অপারেশন করা হচ্ছে তার উপর নির্ভর করে এটি সম্ভাব্যত এটি আরও বড় করে তুলবে।
পল রান্ডাল

5

আপনি এগুলি সঙ্কুচিত করতে পারেন, তবে এগুলি আবার বাড়বে, অবশেষে ডিস্কের খণ্ডন ঘটায়। সূচি পুনর্নির্মাণ এবং ডিফ্র্যাগগুলি খুব বড় লেনদেন লগ করে। আপনার যদি পয়েন্ট-ইন-টাইম পুনরুদ্ধারযোগ্যতার প্রয়োজন না হয়, আপনি সাধারণ পুনরুদ্ধার মোডে পরিবর্তন করতে পারেন এবং লেনদেনের লগ ব্যাকআপগুলি পুরোপুরি সরিয়ে ফেলতে পারেন।

আমি অনুমান করছি আপনি অপ্টিমাইজেশনের জন্য কোনও রক্ষণাবেক্ষণ পরিকল্পনা ব্যবহার করছেন, আপনি কোনও স্ক্রিপ্ট ব্যবহার করতে এটি পরিবর্তন করতে পারেন যা কোনও নির্দিষ্ট খণ্ড স্তরের মাত্রায় পৌঁছে গেলে আপনি সম্ভবত কোনও কর্মক্ষমতা হিট না করতে পারেন। এটি অনেক ছোট লগ তৈরি করতে পারে।

আমি প্রতিদিনের সম্পূর্ণ ব্যাকআপ বিটিডাব্লুয়ের পক্ষে প্রতিদিনের পার্থক্যগুলি এড়িয়ে যাব।


আমি মনে করি পুরো ব্যাকআপের শেষে আমি কেবল একটি সরাসরি ট্রানসেট লগ করতে পারি, তবে এটি সর্বোত্তম পদ্ধতির মতো বলে মনে হচ্ছে না, আমি কিছু বিকল্পের জন্য আশা করছিলাম ... বরং প্রতিদিনের পুরো ব্যাকআপগুলি করলে কী কী উপকার হবে? ডিফএসের চেয়ে? এটি তুলনামূলকভাবে সামান্য উপকারের জন্য আরও জায়গা ব্যবহার করে বলে মনে হচ্ছে। আমি সাধারণ পুনরুদ্ধারের দিকেও যেতে পারি না কারণ আমার প্রতি ঘণ্টায় লগ ব্যাকআপগুলি দেয় এমন গ্রানুলারিটির স্তরের প্রয়োজন। পরিশেষে, আমি নিশ্চিত নই যে কীভাবে কোনও স্ক্রিপ্টে অপ্টিমাইজেশন স্থানান্তরিত করতে সহায়তা করবে, অবশ্যই আমার এখনও একই সমস্যাটি খুব কম ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘন ঘুরে ঘুরে ঘুরে ঘুরে ঘুরে ঘুরে ঘুরে ঘুরেফিরে কেটে যায়?
ডেভ

ভিন্নতা এড়াতে এবং প্রতিদিনের পূর্ণতায় যাওয়ার পরামর্শের কারণে আমি এটিকে অগ্রাহ্য করেছি। কেন? একটি 3.5 গিগাবাইট পূর্ণ যদিও ডিফারগুলি কেবল 250MB। ব্যাকআপ কৌশলটি আমার কাছে একেবারে সূক্ষ্ম দেখাচ্ছে। বিচ্ছিন্নতা অপসারণের অর্থ পুনরুদ্ধারের সময়ের মধ্যে কেবল একটি ক্ষুদ্র, ক্ষুদ্র গতির জন্য আরও অনেক জিবি বেশি স্টোরেজ।
পল রান্ডাল

2
প্রত্যেকের পরিস্থিতি আলাদা, ডিফ্সগুলির সাথে কোনও ভুল নেই, তবে স্থানটি যদি একটি প্রিমিয়াম না হয়, আপনার যদি দ্রুত পুনরুদ্ধার প্রয়োজন হয়, তবে দু'জনের চেয়ে এক ধাপ ভাল।
স্ক্ল্যাসিড ২

1
@ ডেভ জেরেমির প্রতিক্রিয়া দেখুন, নির্দিষ্ট ফাইলগুলিকে ডিফ্র্যাগ করার জন্য একটি সঞ্চিত পদ্ধতি তৈরি করুন, এটিকে ছোট ছোট ভাণ্ডারে ভাগ করুন।
SqlACID

3

আপনার চূড়ান্ত প্রশ্নটি ছিল: "ব্যাকআপ লগ ব্যতীত TRUNCATE_ONLY ছাড়া, লগ ব্যাকআপের আকার হ্রাস করার কোনও উপায় বা লেনদেনের লগগুলিতে রেকর্ডিং হওয়া থেকে আশাবাদগুলি প্রতিরোধ করার কোনও উপায় আছে, অবশ্যই তারা পুরো হিসাবে গণ্য হবে ব্যাকআপ তারা আগে? "

না, তবে এখানে একটি কার্যনির্বাহী। আপনি যদি জানেন যে সেই সময়ের মধ্যে কেবলমাত্র সেই ডাটাবেসের ক্রিয়াকলাপগুলি সূচক রক্ষণাবেক্ষণ কাজ করবে, তবে আপনি সূচী রক্ষণাবেক্ষণ শুরুর আগে লেনদেন লগ ব্যাকআপগুলি বন্ধ করতে পারবেন। উদাহরণস্বরূপ, শনিবার রাতে আমার কিছু সার্ভার, কাজের সময়সূচীটি এ জাতীয় দেখাচ্ছে:

  • 9:30 পূর্বাহ্নে - লেনদেন লগ ব্যাকআপ রান।
  • 9:45 অপরাহ্ন - লেনদেন লগ ব্যাকআপ শেষবারের জন্য চালিত হয়। শিডিউল 9:59 এ থামবে।
  • 10:00 অপরাহ্ন - সূচকের রক্ষণাবেক্ষণ কাজ শুরু হয় এবং 11:30 টার আগে বিল্ট-ইন স্টপগুলি শেষ হবে।
  • 11:30 অপরাহ্ন - পুরো ব্যাকআপ কাজটি 30 মিনিটের মধ্যেই শুরু হয়ে শেষ হয়।
  • 12:00 এএম - লেনদেনের লগ ব্যাকআপগুলি প্রতি 15 মিনিটে আবার শুরু হয়।

তার মানে আমার 9 -45 টা থেকে 11:30 টার মধ্যে পয়েন্ট-ইন-টাইম পুনরুদ্ধারযোগ্যতা নেই তবে পেওফটি দ্রুত পারফরম্যান্স।


এবং আপনাকে অবশ্যই 10PM এর ঠিক আগে সিমপ্লেতে স্যুইচ করতে হবে, তাই না? অন্যথায় 12am লগ ব্যাকআপে 10PM এবং 12AM এর মধ্যে উত্পন্ন সমস্ত লগ থাকবে।
পল রান্ডাল

উফ উল্লেখ করতে ভুলে গিয়েছিলাম আমি এটিকেও হ্রাস করেছিলাম কারণ আপনি সিম্পলটিতে থাকার কথা উল্লেখ করেন নি। এমনকি BULK_LOGGED এ থাকাও পরবর্তী লগ ব্যাকআপের আকার পরিবর্তন করবে না কারণ এটি ন্যূনতম-লগ-ইন করা ক্রিয়াকলাপগুলির দ্বারা পরিবর্তিত সমস্ত ডেটা এক্সটেন্টগুলি তুলবে। বাহ - এখন পর্যন্ত এর প্রতিটি উত্তরকে কমিয়ে দেওয়া হয়েছে।
পল রান্ডাল

না , অবশ্যই সহজটিতে স্যুইচ করবেন না। তিনি তার লেনদেনের লগ ব্যাকআপগুলির আকার সম্পর্কে জিজ্ঞাসা করেছিলেন, তার সম্পূর্ণ ব্যাকআপ বা তার লেনদেন লগ ফাইলের আকার নয়।
ব্রেন্ট ওজার

সুতরাং আপনি কীভাবে লেনদেনের লগ ব্যাকআপের আকার হ্রাস করবেন? আপনি লগ ব্যাকআপ চেইনটি ভেঙে না ফেলে এবং সম্পূর্ণ ব্যাকআপ নিয়ে পুনরায় আরম্ভ না করা হলে এগুলি পূর্ববর্তী লগ ব্যাকআপের পর থেকে সমস্ত কিছু ধারণ করবে।
পল রান্ডাল

আপনার সূচকের রক্ষণাবেক্ষণের কাজটি যদি না কিছু করে ...
পল রান্ডাল 27:09

3

সহজ উত্তর: একটি রাতের ভিত্তিতে আরও সুষম পদ্ধতিতে চালনার জন্য আপনার সাপ্তাহিক অপ্টিমাইজেশনের কাজটি পরিবর্তন করুন। যেমন রবিবার রাতে রি-ইনডেক্স টেবিলগুলি, সোমবার রাতে চ - ল ইত্যাদি ... একটি ভাল ভারসাম্য সন্ধান করুন, আপনার লগটি গড় আকারের প্রায় 1/6 তম হবে। অবশ্যই যদি আপনি অন্তর্নির্মিত এসসিস সূচক রক্ষণাবেক্ষণ কাজটি ব্যবহার না করেন তবে এটি সর্বোত্তম কাজ করে।

এর খারাপ দিক এবং এটি আপনার ডিবি অভিজ্ঞতার বোঝার উপর নির্ভর করে এটি অপটিমাইজার এবং ক্যোয়ারী প্ল্যানগুলির পুনরায় ব্যবহারের সাথে সর্বনাশ করেছে।

তবে আপনি যে সমস্ত বিষয় যত্নবান তা হ'ল সাপ্তাহিক ভিত্তিতে আপনার টি-লগের আকার, এটিকে দিন থেকে দিন বা ঘন্টা সময় ধরে বিভক্ত করুন এবং এর মধ্যে টি-লগ ব্যাকআপগুলি চালান।


2

ব্যাকআপ এবং লগগুলির মাপ কমাতে আপনি কোনও তৃতীয় পক্ষের সরঞ্জাম (কোয়েস্ট থেকে লাইটস্পিড, রেড গেট থেকে এসকিউএল ব্যাকআপ, হাইপারব্যাক) দেখতে পারেন। তারা টেপ সাশ্রয়ে দ্রুত তাদের জন্য অর্থ প্রদান করতে পারে।


2

এটি সম্ভবত ধরে নেওয়া যেতে পারে যে আপনার "অপ্টিমাইজেশানগুলি" ইনডেক্স পুনর্নির্মাণগুলি অন্তর্ভুক্ত করে। শুধুমাত্র সাপ্তাহিক ভিত্তিতে এই কাজগুলি সম্পাদন করা এমন ডেটাবেজে গ্রহণযোগ্য হতে পারে যা প্রচুর আপডেট এবং সন্নিবেশের মুখোমুখি হয় না, তবে যদি আপনার ডেটা উচ্চতর তরল হয় তবে আপনি কয়েকটি জিনিস করতে চাইতে পারেন:

  1. আপনার সময়সূচী যদি অনুমতি দেয় এবং যদি প্রভাবটি গ্রহণযোগ্য হয় তবে আপনার সূচিগুলি রাতের বেলা পুনর্নির্মাণ বা পুনর্গঠন করুন। এই রাতের সূচক রক্ষণাবেক্ষণের কাজগুলি সম্পাদন করার সময় কেবল সেই সূচকগুলিকেই টার্গেট করা হয় যা পুনর্গঠনের জন্য 30% এবং পুনর্গঠনের জন্য 15-30% এর পরিসরে বিভক্ত থাকে।

  2. এই কাজগুলি লগইন লেনদেন হয়, সুতরাং আপনি যদি লগ বৃদ্ধির বিষয়ে উদ্বিগ্ন হন তবে আমি পলের প্রস্তাবিত পরামর্শের পক্ষে সমর্থন করব। সূচি রক্ষণাবেক্ষণের আগে চূড়ান্ত লেনদেন লগ ব্যাকআপ, রক্ষণাবেক্ষণ প্রক্রিয়া অনুসরণ করে সরল পুনরুদ্ধারের দিকে স্যুইচ করুন এবং তারপরে সম্পূর্ণ ডেটা ব্যাকআপের পরে সম্পূর্ণ পুনরুদ্ধারে ফিরে যেতে কৌতুকটি করা উচিত।

আমি আমার লগ ফাইলগুলিতে একটি জেনের মতো পদ্ধতির গ্রহণ করি: সেগুলি তাদের আকার হতে চায়। এতক্ষণ যতক্ষণ তারা বেঁচে থাকা অভ্যাসের কারণে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে।

স্ক্রিপ্টগুলি যা বিবেচনামূলক সূচক রক্ষণাবেক্ষণ সম্পাদন করে অনলাইনে চেহারা: সেখানে একটি টন আছে out অ্যান্ড্রু কেলি প্রায় এক বছর আগে এসকিউএল ম্যাগাজিনে একটি শালীন প্রকাশ করেছিলেন। এসকিউএল সার্ভারপিডিয়ায় মিশেল উফোর্ডের কিছু স্ক্রিপ্ট রয়েছে এবং এসকিউএল ম্যাগাজিনের সর্বশেষ সংখ্যা (জুলাই ২০০৯ আমি বিশ্বাস করি) বিষয়টি নিয়েও একটি সম্পূর্ণ নিবন্ধ রয়েছে। পয়েন্টটি হ'ল এমন একটি সন্ধান করুন যা আপনার পক্ষে ভাল কাজ করে এবং এটি ন্যূনতম কাস্টমাইজেশনের মাধ্যমে নিজের করে তোলে।


2

আপনি আপনার ডাটাবেস অপ্টিমাইজেশনের সময় বিভিন্ন পয়েন্টে লেনদেন লগকে বিশেষভাবে ব্যাকআপ করতে পারেন? টি-লগগুলির মোট আকার একই হবে তবে প্রতিটি এককভাবে ছোট হবে, সম্ভবত আপনাকে কোনও উপায়ে সহায়তা করবে।

আপনি কি আরও লক্ষ্যবস্তু ডাটাবেস অপ্টিমাইজেশন করতে পারেন যাতে খুব কম লেনদেন তৈরি হয় (কেউ এটি উল্লেখ করেছেন তবে আমি নিশ্চিত নই যে এর অর্থগুলি বানানটি বানানো হয়েছিল)। যেমন একটি নির্দিষ্ট পরিমাণে টুকরো টুকরো সহ্য করা বা কিছু সময়ের জন্য স্থান নষ্ট করা। যদি আপনার 40% টেবিলগুলি কেবল 5% খণ্ডিত হয় তবে তাদের স্পর্শ না করলে ক্রিয়াকলাপের বেশ কিছুটা সঞ্চয় হতে পারে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.