🥇የፖስትግሬስ ዳታቤዝ ከተሳካ በኋላ የማገገም የመጀመሪያ ልምዴ (ልክ ያልሆነ ገጽ በብሎክ 4123007 የሬላተን ቤዝ/16490)

የ Postgres ዳታቤዝ ወደ ሙሉ ተግባር የመመለስ የመጀመሪያ የተሳካ ልምዴን ላካፍላችሁ እወዳለሁ። ከግማሽ ዓመት በፊት ከፖስትግሬስ ዲቢኤምኤስ ጋር ተዋወቅሁ፤ ከዚያ በፊት በዳታቤዝ አስተዳደር ላይ ምንም ልምድ አልነበረኝም።

በአንድ ትልቅ የአይቲ ኩባንያ ውስጥ ከፊል-DevOps መሐንዲስ ሆኜ እሰራለሁ። ድርጅታችን ለከፍተኛ ጭነት አገልግሎቶች ሶፍትዌር ያዘጋጃል፣ እና እኔ ለአፈጻጸም፣ ለጥገና እና ለማሰማራት ሀላፊነት አለብኝ። አንድ መደበኛ ተግባር ተሰጠኝ፡ በአንድ አገልጋይ ላይ ያለውን መተግበሪያ ለማዘመን። አፕሊኬሽኑ የተፃፈው በጃንጎ ነው ፣ በዝማኔው ወቅት ፍልሰቶች ይከናወናሉ (በመረጃ ቋቱ መዋቅር ላይ ለውጦች) እና ከዚህ ሂደት በፊት በመደበኛ pg_dump ፕሮግራም በኩል ሙሉ የውሂብ ጎታ እንወስዳለን ፣ ልክ እንደዚያ።

ቆሻሻን በሚወስዱበት ጊዜ ያልተጠበቀ ስህተት ተፈጥሯል (የፖስትግሬስ ስሪት 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 ምትኬን መውሰድዎን ያረጋግጡ። ምናባዊ ማሽን ካለዎት የውሂብ ጎታውን ያቁሙ እና ቅጽበተ-ፎቶ ያንሱ። ቅጽበታዊ ገጽ እይታ ለማንሳት የማይቻል ከሆነ ዳታቤዙን ያቁሙ እና የ Postgres ማውጫን ይዘቶች (የዋል ፋይሎችን ጨምሮ) ወደ ደህና ቦታ ይቅዱ። በእኛ ንግድ ውስጥ ዋናው ነገር ነገሮችን ማባባስ አይደለም. አንብብ ይህም.

ዳታቤዙ በአጠቃላይ ለእኔ ይሠራ ስለነበር፣ ራሴን በመደበኛ የውሂብ ጎታ ማከማቻ ወሰንኩ፣ ነገር ግን በተበላሸ መረጃ ሰንጠረዡን አገለልኩ (አማራጭ) -ቲ፣ --exclude-table=ጠረጴዛ በpg_dump)።

አገልጋዩ አካላዊ ነበር፣ ቅጽበታዊ ገጽ እይታ ለማንሳት አልተቻለም። መጠባበቂያው ተወግዷል፣ እንቀጥል።

የፋይል ስርዓት ፍተሻ

የውሂብ ጎታውን ወደነበረበት ለመመለስ ከመሞከርዎ በፊት, ሁሉም ነገር በፋይል ስርዓቱ በራሱ የተስተካከለ መሆኑን ማረጋገጥ አለብን. እና ስህተቶች በሚኖሩበት ጊዜ ያስተካክሉዋቸው, ምክንያቱም አለበለዚያ ግን ነገሮችን ሊያባብሱ ይችላሉ.

በእኔ ሁኔታ ከመረጃ ቋቱ ጋር ያለው የፋይል ስርዓት ተጭኗል "/srv" እና አይነት ext4 ነበር.

የውሂብ ጎታውን ማቆም; systemctl ማቆም [ኢሜል የተጠበቀ] እና የፋይል ስርዓቱ በማንም ሰው ጥቅም ላይ የማይውል መሆኑን እና ትዕዛዙን በመጠቀም ሊፈታ የሚችል መሆኑን ያረጋግጡ lsof:
lsof +D/srv

የሬዲስ ዳታቤዙንም እየተጠቀመበት ስለነበር ማቆም ነበረብኝ "/srv". ቀጥዬ ወጣሁ / srv (ጥቅል)።

የፋይል ስርዓቱ መገልገያውን በመጠቀም ተረጋግጧል ኢ 2fsck ከመቀየሪያው ጋር -f (የፋይል ስርዓቱ ንጹህ ተብሎ ቢታወቅም ፍተሻን ያስገድዱ):

በመቀጠል መገልገያውን በመጠቀም dumpe2fs (sudo dumpe2fs /dev/mapper/gu2-sys-srv | grep ተረጋግጧል) ቼኩ በትክክል መፈጸሙን ማረጋገጥ ይችላሉ፡-

ኢ 2fsck በ ext4 የፋይል ስርዓት ደረጃ ምንም አይነት ችግር እንዳልተገኘ ተናግሯል፣ይህ ማለት የውሂብ ጎታውን ወደነበረበት ለመመለስ መሞከርዎን መቀጠል ይችላሉ ፣ይልቁንስ ወደነበረበት ይመለሱ። ቫኩም ሙሉ (በእርግጥ የፋይል ስርዓቱን መልሰው መጫን እና የውሂብ ጎታውን መጀመር ያስፈልግዎታል).

አካላዊ አገልጋይ ካለዎት የዲስኮችን ሁኔታ መፈተሽዎን ያረጋግጡ (በ smartctl -a /dev/XXX) ወይም ችግሩ በሃርድዌር ደረጃ ላይ አለመሆኑን ለማረጋገጥ RAID መቆጣጠሪያ። በእኔ ሁኔታ፣ RAID “ሃርድዌር” ሆኖ ተገኘ፣ ስለዚህ የRAIDን ሁኔታ እንዲፈትሽ የአካባቢውን አስተዳዳሪ ጠየቅኩት (አገልጋዩ ከእኔ ብዙ መቶ ኪሎ ሜትሮች ርቆ ነበር።) እሱ ምንም ስህተቶች እንዳልነበሩ ተናግሯል ፣ ይህ ማለት በእርግጠኝነት ተሃድሶ መጀመር እንችላለን ማለት ነው።

ሙከራ 1፡ ዜሮ_የተበላሹ_ገጾች

ከመረጃ ቋቱ ጋር በpsql በኩል የሱፐር ተጠቃሚ መብቶች ባለው መለያ እንገናኛለን። ሱፐር ተጠቃሚ እንፈልጋለን፣ ምክንያቱም... አማራጭ ዜሮ_የተበላሹ_ገጾች እሱ ብቻ ነው መለወጥ የሚችለው. በእኔ ሁኔታ ፖስትግሬስ ነው፡-

psql -h 127.0.0.1 -U postgres -s [የውሂብ ጎታ_ስም]

አማራጭ ዜሮ_የተበላሹ_ገጾች የንባብ ስህተቶችን ችላ ለማለት ያስፈልጋል (ከpostgrespro ድር ጣቢያ)

PostgreSQL የተበላሸ ገጽ ራስጌ ሲያገኝ፣ በተለምዶ ስህተትን ሪፖርት ያደርጋል እና የአሁኑን ግብይት ያስቋርጣል። ዜሮ_የተበላሹ_ገጾች ከነቃ ስርዓቱ በምትኩ ማስጠንቀቂያ ይሰጣል፣ የተበላሸውን ገጽ በማህደረ ትውስታ ውስጥ ያስወግዳል እና መስራቱን ይቀጥላል። ይህ ባህሪ ውሂብ ያጠፋል, ማለትም በተበላሸው ገጽ ውስጥ ያሉትን ሁሉንም ረድፎች.

አማራጩን እናነቃለን እና የጠረጴዛዎቹን ሙሉ ባዶ ለማድረግ እንሞክራለን-

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 - በአንድ ገጽ ላይ የማይመጥን ከሆነ "ረጅም መረጃን" በ Poetgres ውስጥ ለማከማቸት ዘዴ (በነባሪ 8 ኪ.ቢ).

ሙከራ 2፡ እንደገና ኢንዴክስ

የ Google የመጀመሪያ ምክር አልረዳም. ከጥቂት ደቂቃዎች ፍለጋ በኋላ, ሁለተኛውን ጫፍ አገኘሁ - ለመሥራት ሪኢንዴክስ የተበላሸ ጠረጴዛ. ይህንን ምክር በብዙ ቦታዎች አይቻለሁ፣ ግን በራስ መተማመንን አላነሳሳም። እንደገና እንመርምር፡-

reindex table ws_log_smevlog

ሪኢንዴክስ ያለችግር ተጠናቅቋል።

ሆኖም ፣ ይህ አልረዳም ፣ ቫኩም ሙሉ በተመሳሳይ ስህተት ወድቋል። ውድቀቶችን ስለለመድኩ በበይነመረቡ ላይ ምክር መፈለግ ጀመርኩ እና አንድ አስደሳች ነገር አገኘሁ ጽሑፍ.

ሙከራ 3፡ ምረጥ፣ LIMIT፣ OFFSET

ከላይ ያለው መጣጥፍ የሰንጠረዡን ረድፍ በመደዳ ለመመልከት እና ችግር ያለበትን ውሂብ ለማስወገድ ሀሳብ አቅርቧል። በመጀመሪያ ሁሉንም መስመሮች ማየት አለብን-

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 ቀናት መጠበቅ አልፈለኩም። ሌላ ሙሉ ውድቀት.

ግን ተስፋ አልቆረጥኩም። ቅኝቱ ለምን ብዙ ጊዜ እንደወሰደ ገረመኝ። ከሰነዱ (በድጋሚ በpostgrespro ላይ) ይህን አውቄያለሁ፡-

OFFSET ረድፎችን ማውጣት ከመጀመሩ በፊት የተገለጹትን የረድፎች ብዛት መዝለልን ይገልጻል።
ሁለቱም OFFSET እና LIMIT ከተገለጹ፣ሲስተሙ መጀመሪያ የOFFSET ረድፎችን ይዘለላል እና ከዚያ ለLIMIT እገዳ ረድፎችን መቁጠር ይጀምራል።

LIMIT በሚጠቀሙበት ጊዜ የውጤት ረድፎች በተወሰነ ቅደም ተከተል እንዲመለሱ ORDER BY አንቀጽ መጠቀምም አስፈላጊ ነው። አለበለዚያ ያልተጠበቁ የረድፎች ንዑስ ስብስቦች ይመለሳሉ.

በግልጽ ለማየት እንደሚቻለው, ከላይ ያለው ትዕዛዝ ስህተት ነበር: በመጀመሪያ, የለም በቅደም ተከተልውጤቱ የተሳሳተ ሊሆን ይችላል. በሁለተኛ ደረጃ፣ Postgres በመጀመሪያ የOFFSET ረድፎችን መቃኘት እና መዝለል ነበረበት፣ እና እየጨመረ በሄደ ቁጥር OFFSET ምርታማነት የበለጠ ይቀንሳል.

ሙከራ 4፡ በፅሁፍ ቅፅ ቆሻሻ ውሰድ

ከዚያም አንድ የሚያምር የሚመስል ሀሳብ ወደ አእምሮዬ መጣ፡ በፅሁፍ መልክ አንድ ቆሻሻ ውሰድ እና የመጨረሻውን የተቀዳውን መስመር ተንትን።

በመጀመሪያ ግን የጠረጴዛውን መዋቅር እንመልከት. ws_log_smevlog:

በእኛ ሁኔታ አንድ አምድ አለን "መታወቂያ"የረድፉ ልዩ መለያ (መቁጠሪያ) የያዘ። እቅዱ እንደዚህ ነበር፡-

በጽሑፍ መልክ (በ sql ትዕዛዞች መልክ) መጣል እንጀምራለን
በተወሰነ ጊዜ ውስጥ, ቆሻሻው በስህተት ምክንያት ይቋረጣል, ነገር ግን የጽሑፍ ፋይሉ አሁንም በዲስክ ላይ ይቀመጣል.
የጽሑፍ ፋይሉን መጨረሻ እንመለከታለን፣ በዚህም በተሳካ ሁኔታ የተወገደውን የመጨረሻውን መስመር መለያ (መታወቂያ) እናገኛለን።

በፅሁፍ መልክ መጣያ መውሰድ ጀመርኩ፡-

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፡ ምረጥ፣ ከ WHERE id=

ውድቀቶች የበለጠ ጠንካራ ያደርገናል. በጭራሽ ተስፋ መቁረጥ የለብዎትም, ወደ መጨረሻው መሄድ እና በራስዎ እና በችሎታዎ ማመን ያስፈልግዎታል. ስለዚህ ሌላ አማራጭ ለመሞከር ወሰንኩ፡ በመረጃ ቋቱ ውስጥ ያሉትን ሁሉንም መዝገቦች አንድ በአንድ ይመልከቱ። የጠረጴዛዬን አወቃቀር በማወቅ (ከላይ ያለውን ይመልከቱ) ፣ ልዩ የሆነ (ዋና ቁልፍ) የሆነ የመታወቂያ መስክ አለን። በሰንጠረዡ ውስጥ 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 / nullነገር ግን የ SELECT ትዕዛዙ ካልተሳካ የስህተት ጽሁፍ ታትሟል (stderr ወደ ኮንሶል ተልኳል) እና ስህተቱ ያለበት መስመር ታትሟል (ለ || ምስጋና ይግባውና ይህም ማለት መራጩ ችግር ነበረበት (የትእዛዝ መመለሻ ኮድ) አይደለም 0)).

እድለኛ ነበርኩ, በሜዳው ላይ ኢንዴክሶች ተፈጥረዋል id:

ይህ ማለት ከተፈለገው መታወቂያ ጋር መስመር መፈለግ ብዙ ጊዜ ሊወስድ አይገባም. በንድፈ ሀሳብ መስራት አለበት. ደህና ፣ ትዕዛዙን ወደ ውስጥ እናስገባ tmux እና ወደ መኝታ እንሂድ.

ጠዋት ላይ ወደ 90 የሚጠጉ ግቤቶች እንደታዩ ተገነዘብኩ፣ ይህም ከ000% በላይ ነው። ከቀዳሚው ዘዴ (5%) ጋር ሲወዳደር በጣም ጥሩ ውጤት! ግን 2 ቀናት መጠበቅ አልፈለኩም...

ሙከራ 6፡ ምረጥ፣ ከ WHERE id >= እና መታወቂያ

ደንበኛው ለዳታቤዝ ልዩ የሆነ አገልጋይ ነበረው፡ ባለሁለት ፕሮሰሰር ኢንቴል Xeon E5-2697 v2በእኛ ቦታ እስከ 48 ክሮች ነበሩ! በአገልጋዩ ላይ ያለው ሸክም በአማካይ ነበር፤ ያለ ምንም ችግር ወደ 20 የሚደርሱ ክሮች ማውረድ እንችላለን። በተጨማሪም በቂ ራም ነበር: እስከ 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_መጣል. ቆሻሻው ያለ ምንም ስህተት ተወስዷል! ችግሩ የተፈታው እንደዚህ ባለ ሞኝነት ነው። ደስታው ወሰን የለውም፣ ከብዙ ውድቀቶች በኋላ መፍትሄ ለማግኘት ችለናል!

ምስጋናዎች እና መደምደሚያ

እውነተኛ የፖስትግሬስ ዳታቤዝ ወደነበረበት የመመለስ የመጀመሪያ ልምዴ በዚህ መንገድ ነበር። ይህንን ልምድ ለረጅም ጊዜ አስታውሳለሁ.

እና በመጨረሻም ፣ ሰነዶቹን ወደ ሩሲያኛ ስለተረጎሙ እና ለ PostgresPro አመሰግናለሁ ማለት እፈልጋለሁ ሙሉ በሙሉ ነፃ የመስመር ላይ ኮርሶች, ይህም በችግሩ ትንተና ወቅት ብዙ ረድቷል.

ምንጭ: hab.com

የ Postgres ዳታቤዝ ከተሳካ በኋላ የማግኘት የመጀመሪያ ልምዴ (ልክ ያልሆነ ገጽ በብሎክ 4123007 የሬላቶን ቤዝ/16490)