একটি ব্যর্থতার পরে পোস্টগ্রেস ডাটাবেস পুনরুদ্ধার করার আমার প্রথম অভিজ্ঞতা (রিল্যাটন বেস/4123007 ব্লক 16490-এ অবৈধ পৃষ্ঠা)

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

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

ডাম্প নেওয়ার সময় একটি অপ্রত্যাশিত ত্রুটি ঘটেছে (Postgres সংস্করণ 9.5):

pg_dump: Oumping the contents of table “ws_log_smevlog” failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989
pg_dump: The command was: COPY public.ws_log_smevlog [...]
pg_dunp: [parallel archtver] a worker process dled unexpectedly

ভুল "অবৈধ পৃষ্ঠা ব্লকে" ফাইল সিস্টেম স্তরে সমস্যার কথা বলে, যা খুবই খারাপ। বিভিন্ন ফোরামে এটি করার পরামর্শ দেওয়া হয়েছিল সম্পূর্ণ ভ্যাকুয়াম বিকল্প সহ শূন্য_ক্ষতিগ্রস্ত_পৃষ্ঠা সমস্যাটি সমাধান করতে. আচ্ছা, চেষ্টা করা যাক...

পুনরুদ্ধারের জন্য প্রস্তুতি নিচ্ছেন

সতর্কবার্তা! আপনার ডাটাবেস পুনরুদ্ধার করার কোনো প্রচেষ্টার আগে একটি Postgres ব্যাকআপ নিতে ভুলবেন না। আপনার যদি ভার্চুয়াল মেশিন থাকে তবে ডাটাবেস বন্ধ করুন এবং একটি স্ন্যাপশট নিন। একটি স্ন্যাপশট নেওয়া সম্ভব না হলে, ডাটাবেস বন্ধ করুন এবং পোস্টগ্রেস ডিরেক্টরির বিষয়বস্তু (ওয়াল ফাইল সহ) একটি নিরাপদ স্থানে কপি করুন। আমাদের ব্যবসার প্রধান জিনিস জিনিস খারাপ করা হয় না. পড়ুন এটা.

যেহেতু ডাটাবেস সাধারণত আমার জন্য কাজ করে, তাই আমি নিজেকে একটি নিয়মিত ডাটাবেস ডাম্পে সীমাবদ্ধ রেখেছিলাম, কিন্তু ক্ষতিগ্রস্ত ডেটা সহ টেবিলটি বাদ দিয়েছিলাম (বিকল্প -T, --exclude-table=TABLE pg_dump এ)।

সার্ভারটি শারীরিক ছিল, স্ন্যাপশট নেওয়া অসম্ভব। ব্যাকআপ মুছে ফেলা হয়েছে, চলুন এগিয়ে চলুন.

ফাইল সিস্টেম চেক

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

আমার ক্ষেত্রে, ডাটাবেসের সাথে ফাইল সিস্টেমটি মাউন্ট করা হয়েছিল "/srv" এবং টাইপ ছিল ext4.

ডাটাবেস বন্ধ করা: systemctl স্টপ [ইমেল সুরক্ষিত] এবং পরীক্ষা করুন যে ফাইল সিস্টেমটি কেউ ব্যবহার করছে না এবং কমান্ড ব্যবহার করে আনমাউন্ট করা যেতে পারে lsof:
lsof +D /srv

আমাকে রেডিস ডাটাবেসটিও বন্ধ করতে হয়েছিল, যেহেতু এটিও ব্যবহার করছে "/srv". পরবর্তী আমি আনমাউন্ট / এসআরভি (উমাউন্ট)।

ইউটিলিটি ব্যবহার করে ফাইল সিস্টেম চেক করা হয়েছে e2fsck সুইচ দিয়ে -f (ফাইল সিস্টেম পরিষ্কার চিহ্নিত করা হলেও জোর করে চেক করুন):

পরবর্তী, ইউটিলিটি ব্যবহার করে dumpe2fs (sudo dumpe2fs /dev/mapper/gu2—sys-srv | grep চেক করা হয়েছে) আপনি যাচাই করতে পারেন যে চেকটি আসলে সম্পাদিত হয়েছিল:

e2fsck বলে যে ext4 ফাইল সিস্টেম স্তরে কোন সমস্যা পাওয়া যায়নি, যার মানে হল যে আপনি ডাটাবেস পুনরুদ্ধার করার চেষ্টা চালিয়ে যেতে পারেন, অথবা বরং ফিরে যেতে পারেন ভ্যাকুয়াম পূর্ণ (অবশ্যই, আপনাকে ফাইল সিস্টেমটি আবার মাউন্ট করতে হবে এবং ডাটাবেস শুরু করতে হবে)।

আপনার যদি একটি শারীরিক সার্ভার থাকে তবে ডিস্কগুলির স্থিতি পরীক্ষা করতে ভুলবেন না (এর মাধ্যমে smartctl -a /dev/XXX) বা RAID কন্ট্রোলার নিশ্চিত করুন যে সমস্যাটি হার্ডওয়্যার স্তরে নেই। আমার ক্ষেত্রে, RAID "হার্ডওয়্যার" হিসাবে পরিণত হয়েছিল, তাই আমি স্থানীয় প্রশাসককে RAID এর স্থিতি পরীক্ষা করতে বলেছিলাম (সার্ভারটি আমার থেকে কয়েকশ কিলোমিটার দূরে ছিল)। তিনি বলেছিলেন যে কোনও ত্রুটি ছিল না, যার অর্থ আমরা অবশ্যই পুনরুদ্ধার শুরু করতে পারি।

প্রচেষ্টা 1: শূন্য_ক্ষতিগ্রস্ত_পৃষ্ঠা

আমরা psql-এর মাধ্যমে ডাটাবেসের সাথে একটি অ্যাকাউন্টের সাথে সংযোগ করি যার সুপার ব্যবহারকারীর অধিকার রয়েছে। আমাদের একজন সুপার ইউজার দরকার, কারণ... বিকল্প শূন্য_ক্ষতিগ্রস্ত_পৃষ্ঠা শুধুমাত্র তিনি পরিবর্তন করতে পারেন। আমার ক্ষেত্রে এটি postgres:

psql -h 127.0.0.1 -U postgres -s [ডেটাবেস_নাম]

বিকল্প শূন্য_ক্ষতিগ্রস্ত_পৃষ্ঠা পড়ার ত্রুটিগুলি উপেক্ষা করার জন্য প্রয়োজন (postgrespro ওয়েবসাইট থেকে):

যখন PostgreSQL একটি দূষিত পৃষ্ঠা শিরোনাম সনাক্ত করে, এটি সাধারণত একটি ত্রুটি রিপোর্ট করে এবং বর্তমান লেনদেন বাতিল করে। যদি zero_damaged_pages সক্রিয় করা হয়, সিস্টেম পরিবর্তে একটি সতর্কতা জারি করে, মেমরিতে ক্ষতিগ্রস্ত পৃষ্ঠাটি শূন্য করে এবং প্রক্রিয়াকরণ চালিয়ে যায়। এই আচরণ ডেটা ধ্বংস করে, যথা ক্ষতিগ্রস্ত পৃষ্ঠার সমস্ত সারি।

আমরা বিকল্পটি সক্ষম করি এবং টেবিলগুলির একটি সম্পূর্ণ ভ্যাকুয়াম করার চেষ্টা করি:

VACUUM FULL VERBOSE

দুর্ভাগ্যবশত, দুর্ভাগ্য।

আমরা একই ধরনের ত্রুটির সম্মুখীন হয়েছি:

INFO: vacuuming "“public.ws_log_smevlog”
WARNING: invalid page in block 4123007 of relation base/16400/21396989; zeroing out page
ERROR: unexpected chunk number 573 (expected 565) for toast value 21648541 in pg_toast_106070

pg_toast - পোয়েটগ্রেসে "লং ডেটা" সংরক্ষণ করার একটি পদ্ধতি যদি এটি এক পৃষ্ঠায় ফিট না হয় (ডিফল্টরূপে 8kb)।

প্রচেষ্টা 2: পুনঃসূচীকরণ

Google থেকে প্রথম পরামর্শ সাহায্য করেনি. কয়েক মিনিট অনুসন্ধান করার পরে, আমি দ্বিতীয় টিপ খুঁজে পেয়েছি - তৈরি করতে reindex ক্ষতিগ্রস্ত টেবিল। আমি অনেক জায়গায় এই পরামর্শ দেখেছি, কিন্তু এটি আত্মবিশ্বাসকে অনুপ্রাণিত করেনি। চলুন পুনঃসূচীকরণ করা যাক:

reindex table ws_log_smevlog

reindex সমস্যা ছাড়াই সম্পন্ন।

যাইহোক, এটি সাহায্য করেনি, ভ্যাকুয়াম পূর্ণ একটি অনুরূপ ত্রুটি সঙ্গে ক্র্যাশ. যেহেতু আমি ব্যর্থতায় অভ্যস্ত, তাই আমি ইন্টারনেটে পরামর্শের জন্য আরও সন্ধান করতে শুরু করেছি এবং একটি বরং আকর্ষণীয় জুড়ে এসেছি প্রবন্ধ.

প্রচেষ্টা 3: নির্বাচন করুন, সীমাবদ্ধ করুন, অফসেট করুন

উপরের নিবন্ধটি সারি দ্বারা সারি সারি দেখার এবং সমস্যাযুক্ত ডেটা অপসারণের পরামর্শ দিয়েছে। প্রথমে আমাদের সমস্ত লাইনগুলি দেখতে হবে:

for ((i=0; i<"Number_of_rows_in_nodes"; i++ )); do psql -U "Username" "Database Name" -c "SELECT * FROM nodes LIMIT 1 offset $i" >/dev/null || echo $i; done

আমার ক্ষেত্রে, টেবিল অন্তর্ভুক্ত 1 628 991 লাইন এটা ভাল যত্ন নেওয়া প্রয়োজন ছিল ডেটা পার্টিশনিং, কিন্তু এটি একটি পৃথক আলোচনার জন্য একটি বিষয়. এটি শনিবার ছিল, আমি এই কমান্ডটি টিমুক্সে চালিয়েছিলাম এবং বিছানায় গিয়েছিলাম:

for ((i=0; i<1628991; i++ )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog LIMIT 1 offset $i" >/dev/null || echo $i; done

সকালের মধ্যে আমি সবকিছু কেমন চলছে তা পরীক্ষা করার সিদ্ধান্ত নিয়েছি। আমার বিস্ময়ের সাথে, আমি আবিষ্কার করেছি যে 20 ঘন্টা পরে, মাত্র 2% ডেটা স্ক্যান করা হয়েছে! আমি 50 দিন অপেক্ষা করতে চাইনি। আরেকটি সম্পূর্ণ ব্যর্থতা।

কিন্তু আমি হাল ছাড়িনি। আমি ভাবছিলাম কেন স্ক্যানিং এত সময় নেয়। ডকুমেন্টেশন থেকে (আবার পোস্টগ্রেসপ্রোতে) আমি খুঁজে পেয়েছি:

OFFSET আউটপুট সারি শুরু করার আগে একটি নির্দিষ্ট সংখ্যক সারি এড়িয়ে যাওয়ার জন্য নির্দিষ্ট করে।
যদি OFFSET এবং LIMIT উভয়ই নির্দিষ্ট করা থাকে, সিস্টেমটি প্রথমে OFFSET সারিগুলি এড়িয়ে যায় এবং তারপর LIMIT সীমাবদ্ধতার জন্য সারিগুলি গণনা শুরু করে৷

LIMIT ব্যবহার করার সময়, একটি ORDER BY ক্লজ ব্যবহার করাও গুরুত্বপূর্ণ যাতে ফলাফলের সারিগুলি একটি নির্দিষ্ট ক্রমে ফেরত দেওয়া হয়। অন্যথায়, সারিগুলির অপ্রত্যাশিত উপসেটগুলি ফেরত দেওয়া হবে৷

স্পষ্টতই, উপরের কমান্ডটি ভুল ছিল: প্রথমত, কোন ছিল না দ্বারা অর্ডার, ফলাফল ভুল হতে পারে. দ্বিতীয়ত, পোস্টগ্রেসকে প্রথমে অফসেট সারিগুলি স্ক্যান করতে হয়েছিল এবং এড়িয়ে যেতে হয়েছিল এবং বৃদ্ধির সাথে OFFSET উৎপাদনশীলতা আরও কমে যাবে।

প্রচেষ্টা 4: পাঠ্য আকারে একটি ডাম্প নিন

তারপরে একটি আপাতদৃষ্টিতে উজ্জ্বল ধারণা আমার মাথায় এসেছিল: পাঠ্য আকারে একটি ডাম্প নিন এবং শেষ রেকর্ড করা লাইনটি বিশ্লেষণ করুন।

তবে প্রথমে টেবিলের গঠন দেখে নেওয়া যাক। ws_log_smevlog:

আমাদের ক্ষেত্রে আমরা একটি কলাম আছে "আইডি", যা সারির অনন্য শনাক্তকারী (কাউন্টার) ধারণ করে। পরিকল্পনাটি ছিল এরকম:

1. আমরা পাঠ্য আকারে একটি ডাম্প নিতে শুরু করি (sql কমান্ডের আকারে)
2. একটি নির্দিষ্ট সময়ে, একটি ত্রুটির কারণে ডাম্পটি বাধাগ্রস্ত হবে, তবে পাঠ্য ফাইলটি ডিস্কে সংরক্ষণ করা হবে।
3. আমরা টেক্সট ফাইলের শেষের দিকে তাকাই, এর ফলে আমরা শেষ লাইনের শনাক্তকারী (আইডি) খুঁজে পাই যা সফলভাবে সরানো হয়েছে

আমি পাঠ্য আকারে একটি ডাম্প নেওয়া শুরু করেছি:

pg_dump -U my_user -d my_database -F p -t ws_log_smevlog -f ./my_dump.dump

ডাম্প, যেমন প্রত্যাশিত, একই ত্রুটির সাথে বাধাপ্রাপ্ত হয়েছিল:

pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989

আরও মাধ্যমে লেজ আমি ডাম্পের শেষ দিকে তাকালাম (লেজ -5 ./my_dump.dump) আবিষ্কার করেছে যে ডাম্পটি আইডি সহ লাইনে বাধাগ্রস্ত হয়েছে 186 525. "সুতরাং সমস্যাটি আইডি 186 526 এর সাথে রয়েছে, এটি ভেঙে গেছে এবং মুছে ফেলা দরকার!" - আমি ভাবি. কিন্তু, ডাটাবেসে একটি প্রশ্ন তৈরি করা:
«ws_log_smevlog থেকে * নির্বাচন করুন যেখানে id=186529"এটা দেখা গেল যে এই লাইনের সাথে সবকিছু ঠিক ছিল... 186 - 530 সূচক সহ সারিগুলিও সমস্যা ছাড়াই কাজ করেছে৷ আরেকটি "উজ্জ্বল ধারণা" ব্যর্থ হয়েছে। পরে আমি বুঝতে পেরেছিলাম কেন এটি ঘটেছে: একটি টেবিল থেকে ডেটা মুছে ফেলা এবং পরিবর্তন করার সময়, সেগুলি শারীরিকভাবে মুছে ফেলা হয় না, তবে "মৃত টুপল" হিসাবে চিহ্নিত করা হয়, তারপর আসে অটোভ্যাকুয়াম এবং এই লাইনগুলিকে মুছে ফেলা হিসাবে চিহ্নিত করে এবং এই লাইনগুলিকে পুনরায় ব্যবহার করার অনুমতি দেয়। বোঝার জন্য, যদি টেবিলের ডেটা পরিবর্তিত হয় এবং অটোভ্যাকুয়াম সক্ষম করা হয়, তবে এটি ক্রমানুসারে সংরক্ষণ করা হয় না।

প্রচেষ্টা 5: সিলেক্ট করুন, ফ্রম, কোথায় আইডি=

ব্যর্থতা আমাদের শক্তিশালী করে। আপনার কখনই হাল ছেড়ে দেওয়া উচিত নয়, আপনাকে শেষ পর্যন্ত যেতে হবে এবং নিজের এবং আপনার ক্ষমতার উপর বিশ্বাস রাখতে হবে। তাই আমি অন্য বিকল্প চেষ্টা করার সিদ্ধান্ত নিয়েছি: ডাটাবেসের সমস্ত রেকর্ড একে একে দেখুন। আমার টেবিলের গঠন জেনে (উপরে দেখুন), আমাদের একটি আইডি ক্ষেত্র রয়েছে যা অনন্য (প্রাথমিক কী)। আমাদের টেবিলে 1 সারি আছে এবং id ক্রমানুসারে আছে, যার মানে আমরা একে একে একে একে যেতে পারি:

for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

যদি কেউ বুঝতে না পারে, কমান্ডটি নিম্নরূপ কাজ করে: এটি সারি দ্বারা সারি সারি স্ক্যান করে এবং stdout পাঠায় আপনার / dev / নাল, কিন্তু যদি SELECT কমান্ড ব্যর্থ হয়, তাহলে ত্রুটির পাঠ্যটি মুদ্রিত হয় (stderr কনসোলে পাঠানো হয়) এবং ত্রুটিযুক্ত একটি লাইন মুদ্রিত হয় (ধন্যবাদ ||, যার মানে নির্বাচনটিতে সমস্যা ছিল (কমান্ডের রিটার্ন কোড) 0 নয়))।

আমি ভাগ্যবান, আমি মাঠে সূচী তৈরি করেছি id:

এর মানে হল যে পছন্দসই আইডি সহ একটি লাইন খুঁজে পেতে বেশি সময় নেওয়া উচিত নয়। তাত্ত্বিকভাবে এটি কাজ করা উচিত। ওয়েল, এর কমান্ড রান করা যাক tmux এবং আসুন বিছানায় যাই।

সকালের মধ্যে আমি দেখতে পেলাম যে প্রায় 90 এন্ট্রি দেখা হয়েছে, যা মাত্র 000% এর বেশি। আগের পদ্ধতির সাথে তুলনা করলে একটি চমৎকার ফলাফল (5%)! কিন্তু আমি 2 দিন অপেক্ষা করতে চাইনি...

প্রচেষ্টা 6: SELECT, FROM, WHERE id >= এবং id

গ্রাহকের ডাটাবেসের জন্য নিবেদিত একটি চমৎকার সার্ভার ছিল: ডুয়াল-প্রসেসর Intel Xeon E5-2697 v2, আমাদের অবস্থানে 48টি থ্রেড ছিল! সার্ভারে লোড গড় ছিল; আমরা কোন সমস্যা ছাড়াই প্রায় 20টি থ্রেড ডাউনলোড করতে পারি। পর্যাপ্ত RAMও ছিল: যতটা 384 গিগাবাইট!

অতএব, কমান্ডটি সমান্তরাল করা দরকার:

for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

এখানে একটি সুন্দর এবং মার্জিত স্ক্রিপ্ট লেখা সম্ভব ছিল, কিন্তু আমি দ্রুততম সমান্তরালকরণ পদ্ধতি বেছে নিয়েছি: ম্যানুয়ালি 0-1628991 পরিসরটিকে 100 রেকর্ডের ব্যবধানে বিভক্ত করুন এবং ফর্মের 000টি কমান্ড আলাদাভাবে চালান:

for ((i=N; i<M; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

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

for ((i=N; i<M; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

একটি tmux সেশনে 16টি উইন্ডো খুলুন এবং কমান্ডগুলি চালান:

1) for ((i=0; i<100000; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
2) for ((i=100000; i<200000; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
…
15) for ((i=1400000; i<1500000; i=$((i+1000)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
16) for ((i=1500000; i<1628991; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

একদিন পর প্রথম ফলাফল পেলাম! যথা (XXX এবং ZZZ মানগুলি আর সংরক্ষিত নেই):

ERROR:  missing chunk number 0 for toast value 37837571 in pg_toast_106070
829000
ERROR:  missing chunk number 0 for toast value XXX in pg_toast_106070
829000
ERROR:  missing chunk number 0 for toast value ZZZ in pg_toast_106070
146000

এর মানে হল যে তিনটি লাইনে একটি ত্রুটি রয়েছে। প্রথম এবং দ্বিতীয় সমস্যা রেকর্ডের আইডিগুলি ছিল 829 এবং 000 এর মধ্যে, তৃতীয়টির আইডিগুলি ছিল 830 এবং 000 এর মধ্যে৷ পরবর্তী, আমাদের কেবল সমস্যা রেকর্ডগুলির সঠিক আইডি মান খুঁজে বের করতে হবে৷ এটি করার জন্য, আমরা 146 ধাপের সাথে সমস্যাযুক্ত রেকর্ডগুলির সাথে আমাদের পরিসরটি দেখি এবং আইডি সনাক্ত করি:

for ((i=829000; i<830000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done
829417
ERROR:  unexpected chunk number 2 (expected 0) for toast value 37837843 in pg_toast_106070
829449
for ((i=146000; i<147000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done
829417
ERROR:  unexpected chunk number ZZZ (expected 0) for toast value XXX in pg_toast_106070
146911

শুভ সমাপ্তি

আমরা সমস্যাযুক্ত লাইন খুঁজে পেয়েছি. আমরা psql এর মাধ্যমে ডাটাবেসে যাই এবং সেগুলি মুছে ফেলার চেষ্টা করি:

my_database=# delete from ws_log_smevlog where id=829417;
DELETE 1
my_database=# delete from ws_log_smevlog where id=829449;
DELETE 1
my_database=# delete from ws_log_smevlog where id=146911;
DELETE 1

আমার আশ্চর্যের জন্য, এন্ট্রিগুলি কোনও সমস্যা ছাড়াই এমনকি বিকল্প ছাড়াই মুছে ফেলা হয়েছিল শূন্য_ক্ষতিগ্রস্ত_পৃষ্ঠা.

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

স্বীকৃতি এবং উপসংহার

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

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

উত্স: www.habr.com