slon - ক্লাউডে অনলাইন

কার্যক্রম:

NAME এর

slon - Slony-I ডেমন

সাইনোপিসিস

হাতি [পছন্দ]... [ক্লাস্টার নাম] [conninfo]

বর্ণনাঃ

slon হল একটি ডেমন অ্যাপ্লিকেশন যা Slony-I প্রতিলিপিকে 'চালনা করে'। একটি slon উদাহরণ হতে হবে
একটি Slony-I ক্লাস্টারে প্রতিটি নোডের জন্য চালান।

বিকল্প

-d log_level
সার্জারির log_level কখন ডিবাগিং বার্তা slon প্রদর্শন করা উচিত তা নির্দিষ্ট করে
তার কার্যকলাপ লগিং.

লগিং এর নয়টি স্তর হল:

· মারাত্মক

· ত্রুটি

· সতর্ক করুন

· কনফিগারেশন

· তথ্য

· ডিবাগ১

· ডিবাগ১

· ডিবাগ১

· ডিবাগ১

প্রথম পাঁচটি নন-ডিবাগিং লগ লেভেল (মারাত্মক থেকে তথ্য পর্যন্ত) সর্বদা প্রদর্শিত
লগ Slony-I-এর প্রাথমিক সংস্করণে, 'প্রস্তাবিত' log_level মান ছিল 2, যা হবে
ডিবাগিং লেভেল 2 পর্যন্ত সমস্ত স্তরে তালিকা আউটপুট। Slony-I সংস্করণ 2, এটি
সেট করার জন্য সুপারিশ করা হয় log_level থেকে 0; সবচেয়ে ধারাবাহিকভাবে আকর্ষণীয় লগ তথ্য হয়
তার চেয়ে উচ্চ স্তরে উত্পন্ন.

-s সুসংগত চেক অন্তর
সার্জারির sync_interval, মিলিসেকেন্ডে পরিমাপ করা হয়, কত ঘন ঘন slon চেক করা উচিত নির্দেশ করে৷
দেখতে যদি a সুসংগত পরিচয় করিয়ে দিতে হবে। ডিফল্ট হল 2000 ms প্রধান লুপ ইন
সিঙ্ক_থ্রেড_মেইন() বিরতির জন্য ঘুমায় sync_interval মিলিসেকেন্ডের মধ্যে
পুনরাবৃত্তি।

সংক্ষিপ্ত সিঙ্ক চেক ব্যবধানগুলি একটি 'শর্ট লিশ'-এ উৎপত্তি রাখে, এটি আপডেট করে
আরো ঘন ঘন গ্রাহকদের. আপনি ঘন ঘন যে অনুক্রম প্রতিলিপি আছে
আপডেট ছাড়া প্রভাবিত হয় যে টেবিল হচ্ছে, এই হচ্ছে থেকে সেখানে রাখে
বার যখন শুধুমাত্র সিকোয়েন্স আপডেট করা হয়, এবং তাই না। সিঙ্ক সঞ্চালিত হয়

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

-t সুসংগত অন্তর সময় শেষ
প্রতিটি শেষে sync_interval_timeout সময়সীমা, ক সুসংগত উৎপন্ন হবে
'স্থানীয়' নোডে এমনকি যদি কোনও প্রতিলিপিযোগ্য ডেটা আপডেট করা না থাকে
সৃষ্টি করেছে একটি সুসংগত উৎপন্ন করা

অ্যাপ্লিকেশানের কার্যকলাপ বন্ধ হয়ে গেলে, অ্যাপ্লিকেশনটি বন্ধ হওয়ার কারণে, বা
কারণ মানব ব্যবহারকারীরা বাড়িতে চলে গেছে এবং আপডেট প্রবর্তন বন্ধ করেছে, হাতি(1)
দূরে পুনরাবৃত্ত হবে, প্রতি জাগরণ sync_interval মিলিসেকেন্ড, এবং, কোন আপডেট নেই
তৈরি করা হচ্ছে, না সুসংগত ঘটনা উত্পন্ন হবে. এই টাইমআউট প্যারামিটার ছাড়া,
না। সুসংগত ঘটনা উত্পন্ন হবে, এবং এটা প্রতিলিপি পতনশীল প্রদর্শিত হবে
পিছনে।

সার্জারির sync_interval_timeout মান অবশেষে একটি উৎপন্ন হতে হবে সুসংগত, এমন কি
যদিও কোন বাস্তব প্রতিলিপি কাজ করা হবে না. এই পরামিতি যে কম
সেট করা হয়, আরো ঘন ঘন হাতি(1) উৎপন্ন হবে সুসংগত ঘটনা যখন আবেদন
প্রতিলিপিযোগ্য কার্যকলাপ তৈরি করছে না; এর দুটি প্রভাব থাকবে:

সিস্টেম আরো প্রতিলিপি কাজ করবে.

(অবশ্যই, যেহেতু ডাটাবেসে কোনও অ্যাপ্লিকেশন লোড নেই, এবং কোনও ডেটা নেই
প্রতিলিপি, এই লোড হ্যান্ডেল করা খুব সহজ হবে.

· প্রতিলিপি আরও 'আপ টু ডেট' রাখা হবে বলে মনে হবে।

(অবশ্যই, যেহেতু কোনো প্রতিলিপিযোগ্য ক্রিয়াকলাপ চলছে না, তাই 'আরও পর্যন্ত
তারিখ' একটি মরীচিকার কিছু।)

ডিফল্ট হল 10000 ms এবং সর্বোচ্চ হল 120000 ms৷ ডিফল্টরূপে, আপনি প্রতিটি নোড আশা করতে পারেন
একটি সঙ্গে 'প্রতিবেদন' সুসংগত প্রতি 10 সেকেন্ডে

মনে রাখবেন যে সুসংগত ইভেন্টগুলি গ্রাহক নোডগুলিতেও তৈরি হয়। যেহেতু তারা আসলে নয়
অন্যান্য নোডগুলিতে প্রতিলিপি করার জন্য যে কোনও ডেটা তৈরি করা, এইগুলি সুসংগত ঘটনা ভয়ঙ্কর নয়
অনেক মূল্য

-g গ্রুপ আয়তন
এটি সর্বাধিক নিয়ন্ত্রণ করে সুসংগত গ্রুপ আকার, sync_group_maxsize; ডিফল্ট 6. এইভাবে,
যদি একটি নির্দিষ্ট নোড 200 এর পিছনে থাকে সুসংগতs, এটি তাদের একসাথে গ্রুপ করার চেষ্টা করবে
সর্বোচ্চ আকারের গ্রুপে sync_group_maxsize. এটা কমবে বলে আশা করা যায়
কম লেনদেন থাকার কারণে ওভারহেড লেনদেন সমর্পণ করা.

6 এর ডিফল্ট সম্ভবত ছোট সিস্টেমের জন্য উপযুক্ত যা শুধুমাত্র খুব উত্সর্গ করতে পারে
slon মেমরি সীমিত বিট. আপনার যদি প্রচুর স্মৃতি থাকে তবে তা হবে
এটি বৃদ্ধি করা যুক্তিসঙ্গত, কারণ এটি প্রতিটিতে সম্পন্ন কাজের পরিমাণ বৃদ্ধি করবে
লেনদেন, এবং একটি গ্রাহক যে অনেক পিছনে আছে আরো ধরতে অনুমতি দেবে
দ্রুত।

Slon প্রক্রিয়া সাধারণত বেশ ছোট থাকে; এমনকি এই বিকল্পের জন্য বড় মান সহ,
slon আকারে মাত্র কয়েক এমবি পর্যন্ত বৃদ্ধি পাবে বলে আশা করা হচ্ছে।

এই পরামিতি বাড়ানোর বড় সুবিধার উপর কাটা থেকে আসে
লেনদেনের সংখ্যা সমর্পণ করাs; 1 থেকে 2 সরানো যথেষ্ট প্রদান করবে
লাভ, কিন্তু লেনদেন হওয়ার পরে সুবিধাগুলি ধীরে ধীরে বন্ধ হয়ে যাবে
প্রক্রিয়াকৃত যুক্তিসঙ্গতভাবে বড় হতে হবে. একটি উপাদান হতে পারে না
80 এবং 90 এর মধ্যে কর্মক্ষমতা পার্থক্য; সেই সময়ে, 'বড় হয় কিনা
ভালো' নির্ভর করবে বড় সেট কিনা সুসংগতs তৈরি করে লগ ইন কার্সার আচরণ
খারাপভাবে বেশি মেমরি গ্রাস করার কারণে এবং সাজানোর জন্য আরও সময় প্রয়োজন।

Slony-I সংস্করণ 1.0-এ, slon সবসময় গ্রুপ করার চেষ্টা করবে সুসংগতএকসাথে এই
সর্বোচ্চ, যা না করবে না আদর্শ হতে যদি প্রতিলিপি কিছুটা অস্থিতিশীল হয়ে থাকে
খুব বড় আপডেট হচ্ছে (যেমন - একটি একক লেনদেন যা শত শত আপডেট করে
হাজার হাজার সারি) বা দ্বারা সুসংগতs ফলাফলের সাথে একটি মূল নোডে ব্যাহত হচ্ছে
যে কয়েক আছে সুসংগতযেগুলো অনেক বড়। আপনি যে সমস্যার মধ্যে চালানো হতে পারে
কিছু খুব বড় একসাথে গ্রুপিং সুসংগতs একটি slon প্রক্রিয়ার উপর knocks. যখন এটা বাছাই
আবার, এটি একই বড় গোষ্ঠীবদ্ধ সেট প্রক্রিয়া করার চেষ্টা করবে সুসংগতs, এবং মধ্যে চালানো
যতক্ষণ না একজন প্রশাসক এটিকে বাধা দেয় এবং পরিবর্তন না করে ততক্ষণ একই সমস্যা বারবার
দ্য -g এই 'অচলাবস্থা' ভাঙার মূল্য।

Slony-I সংস্করণ 1.1 এবং পরবর্তী সংস্করণগুলিতে, স্লন পরিবর্তে অভিযোজিতভাবে 'র্যাম্প আপ' করে
করা থেকে 1 সুসংগত সর্বোচ্চ গ্রুপ আকারের দিকে এক সময়ে। ফলে, যদি সেখানে
একটি দম্পতি হয় সুসংগতs যে সমস্যা সৃষ্টি করে, slon করবে (যেকোনো প্রাসঙ্গিক সঙ্গে
ওয়াচডগ সহায়তা) সর্বদা বিন্দুতে পৌঁছাতে সক্ষম হবে যেখানে এটি প্রক্রিয়া করে
বিরক্তিজনক সুসংগতএকের পর এক, আশা করি অপারেটর সহায়তাকে অপ্রয়োজনীয় করে তুলছে।

-o আকাঙ্ক্ষিত সিঙ্ক সময়
গ্রুপের জন্য একটি 'সর্বোচ্চ' সময় পরিকল্পিত সুসংগতs.

যদি প্রতিলিপি পিছনে চলছে, slon ধীরে ধীরে এর সংখ্যা বৃদ্ধি করবে সুসংগতs
একসাথে গোষ্ঠীবদ্ধ, লক্ষ্য করে যে (এর জন্য নেওয়া সময়ের উপর ভিত্তি করে গত দলগত
সুসংগতs) তাদের নির্দিষ্ট করা থেকে বেশি নেওয়া উচিত নয় ইচ্ছাকৃত_sync_time মান।

এর জন্য ডিফল্ট মান ইচ্ছাকৃত_sync_time 60000ms, এক মিনিটের সমান।

এইভাবে, আপনি আশা করতে পারেন (বা অন্তত আশা করি!) যে আপনি একটি পাবেন সমর্পণ করা মোটামুটি একবার
প্রতি মিনিটে.

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

সামগ্রিক প্রভাব হল Slony-I এর বৈচিত্র্যের সাথে মানিয়ে নেওয়ার ক্ষমতা উন্নত করা
ট্রাফিক 1 দিয়ে শুরু করে সুসংগত, এবং ধীরে ধীরে আরো চলন্ত, এমনকি যদি সেখানে পালা
PostgreSQL ব্যাকএন্ড ক্র্যাশ করার জন্য যথেষ্ট বড় বৈচিত্র্য হতে পারে, Slony-I
একবারে একটি সিঙ্ক দিয়ে শুরু করার জন্য ব্যাক ডাউন হবে, যদি প্রয়োজন হয়, যাতে এটি হয়
প্রতিলিপি অগ্রগতির জন্য সব সম্ভব, এটা হবে.

-c পরিষ্কার কর চক্র
মূল্য vac_frequency কত ঘন ঘন নির্দেশ করে শূন্যস্থান পরিচ্ছন্নতার চক্রে।

স্লন-ইনিশিয়েটেড ভ্যাকুয়ামিং নিষ্ক্রিয় করতে এটিকে শূন্যে সেট করুন। আপনি যদি কিছু ব্যবহার করেন
ভ্যাকুয়াম শুরু করার জন্য pg_autovacuum এর মতো, আপনার আরম্ভ করার জন্য স্লনের প্রয়োজন নাও হতে পারে
নিজেই ভ্যাকুয়াম যদি আপনি না হন, কিছু টেবিল আছে Slony-I ব্যবহার করে যেগুলো a সংগ্রহ করে
অনেক মৃত টিপল যা ঘন ঘন ভ্যাকুয়াম করা উচিত, উল্লেখযোগ্যভাবে pg_শ্রোতা.

Slony-I সংস্করণ 1.1-এ, এটি একটু পরিবর্তিত হয়; পরিষ্কার থ্রেড ট্র্যাক, থেকে
পুনরাবৃত্তি থেকে পুনরাবৃত্তি, প্রাচীনতম লেনদেন আইডি এখনও সিস্টেমে সক্রিয়। যদি
এটি পরিবর্তন হয় না, একটি পুনরাবৃত্তি থেকে পরবর্তীতে, তারপর একটি পুরানো লেনদেন হয়
এখনও সক্রিয়, এবং তাই একটি শূন্যস্থান ভালো করবে না। পরিবর্তে পরিষ্কার থ্রেড
শুধুমাত্র একটি করে বিশ্লেষণ করা পরিসংখ্যান আপডেট করতে এই টেবিলগুলিতে pg_পরিসংখ্যান.

-p পিআইডি ফাইলের নাম
pid_file ফাইলের নাম রয়েছে যেখানে স্লনের পিআইডি (প্রসেস আইডি) সংরক্ষণ করা হয়।

এটি একাধিক স্লন প্রক্রিয়া নিরীক্ষণের জন্য স্ক্রিপ্ট তৈরি করা সহজ করে তুলতে পারে
একক হোস্টে চলছে।

-f কনফিগ ফাইল
যে ফাইল থেকে স্লন কনফিগারেশন পড়তে হবে।

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

-a সংরক্ষণাগার ডিরেক্টরি
archive_dir একটি ডিরেক্টরি নির্দেশ করে যেখানে একটি ক্রম স্থাপন করতে হবে সুসংগত সংরক্ষণাগার
লগ শিপিং-এ ব্যবহারের জন্য ফাইল [“লগ শিপিং - ফাইল সহ স্লোনি-আই” [উপলভ্য নয়
একটি ম্যান পেজ হিসাবে]] মোড।

-x হুকুম থেকে চালান on লগ ইন করুন সংরক্ষণাগার
কমান্ড_অন_লগারকাইভ প্রতিবার একটি SYNC ফাইল চালানোর জন্য একটি কমান্ড নির্দেশ করে
সফলভাবে উত্পন্ন

"slon_conf_command_on_log_archive" এ আরও বিশদ দেখুন [একজন মানুষ হিসাবে উপলব্ধ নয়
পাতা]।

-q অব্যাহতিপ্রাপ্ত ভিত্তি on সুসংগত প্রদানকারী
quit_sync_provider কোন প্রদানকারীর কর্মী থ্রেডটি দেখা উচিত তা নির্দেশ করে৷
একটি নির্দিষ্ট ঘটনার পরে সমাপ্ত করার আদেশ। এই সঙ্গে একযোগে ব্যবহার করা আবশ্যক
-r নীচের বিকল্প...

এটি আপনাকে একটি নির্দিষ্ট বিন্দুর পরে একটি স্লন স্টপ প্রতিলিপি করার অনুমতি দেয়।

-r অব্যাহতিপ্রাপ্ত at ঘটনা সংখ্যা
quit_sync_finalsync ইভেন্ট নম্বর নির্দেশ করে যার পরে দূরবর্তী কর্মী থ্রেড
উপরের প্রদানকারীর জন্য বন্ধ করা উচিত। এই সঙ্গে একযোগে ব্যবহার করা আবশ্যক
-q উপরের বিকল্প...

-l টীম অন্তর
lag_interval একটি ব্যবধান মান নির্দেশ করে যেমন 3 মিনিট or 4 ঘন্টার or 2 দিন
এটি নির্দেশ করে যে এই নোডটি নির্দিষ্ট ব্যবধান দ্বারা তার প্রদানকারীদের পিছিয়ে দিতে হবে
সময় এর ফলে ঘটনাগুলি উপেক্ষা করা হয় যতক্ষণ না তারা অনুরূপ বয়সে পৌঁছায়
ব্যবধান
সতর্কতা

এই ব্যবধান একটি concommittant downside আছে; সব নোড প্রয়োজন যে ঘটনা
সিঙ্ক্রোনাইজ করুন, যেমনটি সাধারণত হয় স্লোনিক ব্যর্থ(7) এবং স্লোনিক সরান সেট(২০১১),
এই ল্যাগিং নোডের জন্য অপেক্ষা করতে হবে।

এটি ব্যর্থতার সময় বা আপনি যখন চান তখন আদর্শ আচরণ নাও হতে পারে
চালান স্লোনিক এক্সিকিউট স্ক্রিপ্ট(7).

প্রস্থান করুন স্থিতি

slon শেলে 0 ফেরত দেয় যদি এটি স্বাভাবিকভাবে শেষ হয়। এর মাধ্যমে ফেরত আসে প্রস্থান (-1) (যা হবে
সম্ভবত আপনার সিস্টেমের উপর নির্ভর করে 127 বা 255 এর একটি রিটার্ন মান প্রদান করে) যদি এটি
কোনো মারাত্মক ত্রুটির সম্মুখীন হয়।

onworks.net পরিষেবা ব্যবহার করে অনলাইনে স্লন ব্যবহার করুন