এসকিউএল সার্ভার বিতরণ উপলভ্যতা গ্রুপ ডেটাবেসগুলি সার্ভার পুনরায় বুট করার পরে সিঙ্ক হচ্ছে না


22

আমরা আমাদের এসকিউএল সার্ভারে একটি বৃহত্তর আপগ্রেড করতে প্রস্তুত হয়েছি এবং বিতরণযোগ্য উপলভ্যতা গোষ্ঠীর সাথে কিছু অস্বাভাবিক আচরণ লক্ষ্য করছি যা আমি এগিয়ে যাওয়ার আগে সমাধান করার চেষ্টা করছি।

গত মাসে, আমি SQL সার্ভার 2017. করতে SQL সার্ভার 2016 থেকে একটি দূরবর্তী মাধ্যমিক সার্ভার আপগ্রেড এই সার্ভার একাধিক একটি অংশ বন্টিত সহজলভ্যতা গোষ্ঠীসমূহ (DAGs) এবং একটি পৃথক সহজলভ্যতা গ্রুপ (এজি) । যখন আমরা এই সার্ভারটি আপগ্রেড করেছি, আমরা অজানা ছিলাম যে এটি অপঠনযোগ্য অবস্থায় যাবে , তাই গত মাসে আমরা কেবলমাত্র প্রাথমিক সার্ভারের উপর নির্ভর করি।

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

তবে, প্রাথমিকটি একটি খুব আলাদা গল্প দেখাচ্ছে showing এটা যে রিপোর্ট ছিল

  • পৃথক এজি কোনও সমস্যা ছাড়াই সিঙ্ক করছে
  • কিন্তু DAGs একটি ছিল না Synchronzing / না স্বাস্থ্যকর রাষ্ট্র

প্রাথমিকভাবে আতঙ্কিত হওয়ার পরে, ডিএজিগুলিতে জিনিসগুলি আবার সিঙ্ক্রোনাইজ করার জন্য আমি নিম্নলিখিত জিনিসগুলি চেষ্টা করেছি:

  • প্রাথমিক থেকে, আমি থামিয়ে দিয়ে ডেটা চলাচলটি আবার শুরু করেছি umed এটি ডেটা সিঙ্ক করতে শুরু করে নি।
  • মাধ্যমিকটিতে (আমি কেবল যার প্যাচ করেছি) আমি দৌড়েছি ALTER DATABASE [<database] SET HADR RESUME;- যা ত্রুটি ছাড়াই কার্যকর হয়, তবে কোনও সিঙ্কিং পুনরায় শুরু করেনি

আবার ডেটা সিঙ্ক করার আমার শেষ চেষ্টাটি ছিল সেকেন্ডারিটিতে লগইন করা এবং ম্যানুয়ালি এসকিউএল সার্ভার পরিষেবাটি পুনরায় চালু করা। ম্যানুয়ালি সার্ভিসটি পুনরায় চালু করা কিছুটা চরম মনে হচ্ছে, কারণ আমি আশা করছিলাম যে সার্ভারটি পুনরায় বুট করা যথেষ্ট হবে।

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

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


আমি উত্পাদনে এসকিউএল 2017 ব্যবহার করি নি তবে এটি কি এসকিউএল এর নিম্ন স্তরের মধ্যে এজি সমর্থন করে? প্রতিটি অন্যান্য সংস্করণ আপনি বিভিন্ন সংস্করণের মধ্যে সর্বদা ওন সেট আপ করতে পারেন, তবে একবার আপনি আপনার প্রাথমিকটি পুনরায় চালু করুন এবং এটি এসকিউএল এর উচ্চতর সংস্করণে ব্যর্থ হলে এটি সিঙ্ক প্রক্রিয়াটি বন্ধ করে দেবে।
অ্যালেন

উত্তর:


8

দয়া করে মনে রাখবেন, এই একটি নির্দিষ্ট উত্তর নয় তবে সাথে চ্যাট পর সর্বোত্তম উত্তর নেই Taryn

তবে, প্রাথমিকটি একটি খুব আলাদা গল্প দেখাচ্ছে showing এটি প্রতিবেদন করছিল যে পৃথক এজি কোনও সমস্যা ছাড়াই সিঙ্ক করছে তবে ডিএজিগুলি সুসংগত নয় / স্বাস্থ্যকর নয়

যদি বিতরণ করা এজি এর অন্তর্নিহিত স্বতন্ত্র ডাটাবেসগুলি এবং এজিগুলি সেগুলি স্বাস্থ্যকর এবং সিঙ্ক্রোনাইজ করার কথা বলে, তবে ডিএমভি এবং / অথবা এসএসএমএস ড্যাশবোর্ডগুলিতে এটি কেবল হিচাপ। যেহেতু প্রতিরূপটি সংযোগ স্থাপন করে না বা সংযোগ বিচ্ছিন্ন অবস্থায় রয়েছে তা বোঝানোর জন্য ত্রুটিযুক্ত কোনও কিছুই ছিল না।

দুর্ভাগ্যক্রমে যেহেতু সমস্যাটি সমাধান হয়েছে, ঠিক কী ছিল তা বলা শক্ত ... তবে ভবিষ্যতে যদি কারওর জন্য এটি ঘটে:

  • স্বাস্থ্যকর নয় এমন কোনও সন্ধানের জন্য সমস্ত ক্লাস্টারে sys.dm_hadr_database_replica_states দেখুন । যদি সমস্ত স্বাস্থ্যকর দেখায় তবে সম্ভব হয় ডিএমভি এখনও আপডেট হয়নি
  • যদি এটি অস্বাস্থ্যকর হয় তবে সংযোগ সমস্যাগুলির জন্য ত্রুটিমুক্ত / ডিএমভিগুলি পরীক্ষা করুন (যেমন ফরওয়ার্ডার / গ্লোবাল প্রাথমিকের সাথে সংযোগ রাখতে সক্ষম না হওয়া)
  • ড্যানের উত্তরে এমন সমস্যাগুলির কথা উল্লেখ করা হয়েছে যা ডাটাবেস সূচনার সময় থেকে উদ্ভূত হতে পারে - যদিও এই ক্ষেত্রে উদাহরণটি পড়া যায় না যাতে সম্ভবত সম্ভবত সমস্যা ছিল না তবে এটি আপনার ক্ষেত্রে হতে পারে
  • ডাটাবেসটি যদি পঠনযোগ্য হয় তবে একটি ডামি টেবিল / sertোকানো বা ...
  • ডিইবিইউজি চ্যানেল আইটেমগুলি ব্যবহার করে sqlserver.hadr_dump_log_blockবা sqlserver.hadr_apply_log_blockসেকেন্ডারিটি লগ ব্লকগুলি গ্রহণ করছে / প্রয়োগ করছে কিনা তা দেখার জন্য প্রসারিত ইভেন্ট সেশন বা ...
  • পারফমন বস্তু SQLServer:Database Replica\Log Bytes Received/sec

যদি আপনি সেই মাধ্যমিকের তথ্য পেয়ে থাকেন তবে বিতরণ করা এজি এখনও সিঙ্ক্রোনাইজ হয় না বা স্বাস্থ্যকর না দেখায় তবে আমি ডিএমভি মান পরিবর্তন করে যেহেতু এটি স্পষ্টতই লগ ব্লকগুলি গ্রহণ ও প্রক্রিয়াজাত করছে তা দেখার জন্য আমি এটি কিছুটা যেতে দেব।

তবে, যদি তা না হয় তবে আমাদের আরও তদন্ত করতে হবে যা উত্তরের সুযোগের বাইরে।


4

আমি এই সাবধানতাটি দিয়ে বলব যে আমার প্রযোজনায় কোনও ডিএজি নেই। মৌলিকভাবে যদিও এই পরামর্শটি এজি এবং ডিএজি উভয়ের মধ্যেই প্রয়োগ করা উচিত।

পরিষেবাটি পুনরায় চালু হওয়ার পরে কি সিঙ্ক্রোনাইজেশন পুনরায় শুরু হয়েছিল? যদি তাই হয় তবে আমার সর্বোত্তম অনুমানটি পুনরায় স্পিডে ব্লক করা হবে। যদি এটি পুনরায় চালু হওয়ার পরেও সিঙ্ক্রোনাইজ না হয় তবে আমি প্রথমে যা যাচাই করব তা এখানে:

এজি পুনরায় এসপিআইডি ব্লক করা হচ্ছে

সাধারণত কেবল পাঠযোগ্য মাধ্যমিকের মধ্যে ঘটতে চলেছে। পরীক্ষা করতে, নিম্নলিখিতটি চালান:

select session_id, blocking_session_id, db_name(database_id), wait_type
from sys.dm_exec_requests
where command = 'DB STARTUP'

যদি কোনও ব্লকিং এসপিআইডি উপস্থিত হয়, তবে মাধ্যমিকটি পুনরায় শুরু করার আগে আপনাকে সেগুলি খুন করতে হবে ( DB STARTUPএসপিআইডি হ'ল পুনরায় কাজগুলি পরিচালনা করে) hand আমি কারণটি নির্ধারণ করার জন্য এবং সাধারণত নির্ধারিত করার জন্য ব্লকিং এসপিআইডিটিকে আগে পর্যালোচনা করার পরামর্শ দেব (সাধারণত দীর্ঘকাল চলমান প্রতিবেদন)।

আপনি এই আরো তথ্যের চান, একটি মহান নিবন্ধ (XEs ব্যবহার আচরণ এই ধরনের পর্যবেক্ষণ সহ) এর এখানে

ডিএমভিগুলি পরীক্ষা করুন

যদি ডেটা চলাচল স্থগিত করা হয় তবে আপনি স্থগিতের কারণ সম্পর্কে আরও তথ্য পেতে ডিএমভিগুলিকে উল্লেখ করতে পারেন। নিম্নলিখিত চালান:

select db_name(database_id), synchronization_state_desc, database_state_desc, suspend_reason_desc
from sys.dm_hadr_database_replica_states

BOL নিবন্ধ suspend_reason একটু আরো বর্ণনা করা হয়েছে।


0

আপনার বিতরণযোগ্য প্রাপ্যতা গ্রুপ (ডিএজি) বিভিন্ন অঞ্চলের মধ্যে বিভক্ত? যদি তাই হয় তবে আপনি ডিফল্ট SESSION_TIMEOUT মান (10 সেকেন্ড) থেকে খুব কম হয়ে ভুগতে পারেন। এর অর্থ হ'ল দুটি অঞ্চলের মধ্যে বিলম্বতা নির্ভরযোগ্যভাবে সম্পূর্ণ সিঙ্কিংয়ের চেয়ে বেশি।

সিঙ্কিং সেশনগুলি আরও স্থিতিশীল করতে একটি সাধারণ প্রাপ্যতা গোষ্ঠীর SESSION_TIMEOUT মান বাড়তে পারে। আমি গত বছরের শেষের দিকে লক্ষ্য করেছি যে ড্যাগের SESSION_TIMEOUT পরামিতিটি সম্পাদনা করা যায়নি। এর অর্থ হ'ল ডাগের কম বিলম্বিত পরিস্থিতিগুলির জন্য শুধুমাত্র কার্যকর ছিল। আমরা মাইক্রোসফ্টের সাথে টিকিট লগ করেছি এবং এই বছরের শুরুর দিকে একটি হটফিক্স প্রকাশ হয়েছিল।

উন্নতি: এসকিউএল সার্ভার 2016 এবং 2017 এ বিতরণযোগ্যতা গ্রুপের প্রতিরূপের জন্য SESSION_TIMEOUT মানটি কনফিগার করুন

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