ਇੱਕ ਅਸਫਲਤਾ ਤੋਂ ਬਾਅਦ ਪੋਸਟਗ੍ਰੇਸ ਡੇਟਾਬੇਸ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਮੇਰਾ ਪਹਿਲਾ ਅਨੁਭਵ (ਰਿਲੇਟਨ ਬੇਸ/4123007 ਦੇ ਬਲਾਕ 16490 ਵਿੱਚ ਅਵੈਧ ਪੰਨਾ)

ਮੈਂ ਤੁਹਾਡੇ ਨਾਲ ਪੋਸਟਗ੍ਰੇਸ ਡੇਟਾਬੇਸ ਨੂੰ ਪੂਰੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਵਿੱਚ ਬਹਾਲ ਕਰਨ ਦਾ ਆਪਣਾ ਪਹਿਲਾ ਸਫਲ ਤਜਰਬਾ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹਾਂਗਾ। ਮੈਂ ਅੱਧਾ ਸਾਲ ਪਹਿਲਾਂ Postgres DBMS ਨਾਲ ਜਾਣੂ ਹੋਇਆ ਸੀ; ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਮੇਰੇ ਕੋਲ ਡੇਟਾਬੇਸ ਪ੍ਰਸ਼ਾਸਨ ਦਾ ਕੋਈ ਤਜਰਬਾ ਨਹੀਂ ਸੀ.

ਮੈਂ ਇੱਕ ਵੱਡੀ IT ਕੰਪਨੀ ਵਿੱਚ ਇੱਕ ਅਰਧ-DevOps ਇੰਜੀਨੀਅਰ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹਾਂ। ਸਾਡੀ ਕੰਪਨੀ ਉੱਚ-ਲੋਡ ਸੇਵਾਵਾਂ ਲਈ ਸੌਫਟਵੇਅਰ ਵਿਕਸਿਤ ਕਰਦੀ ਹੈ, ਅਤੇ ਮੈਂ ਪ੍ਰਦਰਸ਼ਨ, ਰੱਖ-ਰਖਾਅ ਅਤੇ ਤੈਨਾਤੀ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਾਂ। ਮੈਨੂੰ ਇੱਕ ਮਿਆਰੀ ਕੰਮ ਦਿੱਤਾ ਗਿਆ ਸੀ: ਇੱਕ ਸਰਵਰ 'ਤੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਲਈ। ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ Django ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਅੱਪਡੇਟ ਦੇ ਦੌਰਾਨ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ (ਡੇਟਾਬੇਸ ਢਾਂਚੇ ਵਿੱਚ ਤਬਦੀਲੀਆਂ), ਅਤੇ ਇਸ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਪਹਿਲਾਂ ਅਸੀਂ ਸਟੈਂਡਰਡ 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

ਗਲਤੀ "ਬਲਾਕ ਵਿੱਚ ਅਵੈਧ ਪੰਨਾ" ਫਾਇਲ ਸਿਸਟਮ ਪੱਧਰ 'ਤੇ ਸਮੱਸਿਆਵਾਂ ਦੀ ਗੱਲ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਬਹੁਤ ਖਰਾਬ ਹੈ। ਵੱਖ-ਵੱਖ ਫੋਰਮਾਂ 'ਤੇ ਇਸ ਨੂੰ ਕਰਨ ਦਾ ਸੁਝਾਅ ਦਿੱਤਾ ਗਿਆ ਸੀ ਪੂਰਾ ਵੈਕਿਊਮ ਵਿਕਲਪ ਦੇ ਨਾਲ ਜ਼ੀਰੋ_ਨੁਕਸਾਨ ਵਾਲੇ_ਪੰਨੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ. ਖੈਰ, ਆਓ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ...

ਰਿਕਵਰੀ ਲਈ ਤਿਆਰੀ

ਧਿਆਨ ਦਿਓ! ਆਪਣੇ ਡੇਟਾਬੇਸ ਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੋਸਟਗ੍ਰੇਸ ਬੈਕਅੱਪ ਲੈਣਾ ਯਕੀਨੀ ਬਣਾਓ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਹੈ, ਤਾਂ ਡੇਟਾਬੇਸ ਨੂੰ ਰੋਕੋ ਅਤੇ ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਲਓ। ਜੇਕਰ ਸਨੈਪਸ਼ਾਟ ਲੈਣਾ ਸੰਭਵ ਨਹੀਂ ਹੈ, ਤਾਂ ਡੇਟਾਬੇਸ ਨੂੰ ਬੰਦ ਕਰੋ ਅਤੇ ਪੋਸਟਗ੍ਰੇਸ ਡਾਇਰੈਕਟਰੀ (ਵਾਲ ਫਾਈਲਾਂ ਸਮੇਤ) ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਥਾਂ 'ਤੇ ਕਾਪੀ ਕਰੋ। ਸਾਡੇ ਕਾਰੋਬਾਰ ਵਿੱਚ ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਚੀਜ਼ਾਂ ਨੂੰ ਵਿਗੜਨਾ ਨਹੀਂ ਹੈ. ਪੜ੍ਹੋ ਇਸ ਨੂੰ.

ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਨੇ ਆਮ ਤੌਰ 'ਤੇ ਮੇਰੇ ਲਈ ਕੰਮ ਕੀਤਾ, ਮੈਂ ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਨਿਯਮਤ ਡੇਟਾਬੇਸ ਡੰਪ ਤੱਕ ਸੀਮਿਤ ਕੀਤਾ, ਪਰ ਖਰਾਬ ਡੇਟਾ (ਵਿਕਲਪ) ਵਾਲੀ ਸਾਰਣੀ ਨੂੰ ਬਾਹਰ ਰੱਖਿਆ -T, --exclude-table=TABLE pg_dump ਵਿੱਚ).

ਸਰਵਰ ਭੌਤਿਕ ਸੀ, ਸਨੈਪਸ਼ਾਟ ਲੈਣਾ ਅਸੰਭਵ ਸੀ। ਬੈਕਅੱਪ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਆਓ ਅੱਗੇ ਵਧੀਏ।

ਫਾਈਲ ਸਿਸਟਮ ਜਾਂਚ

ਡਾਟਾਬੇਸ ਨੂੰ ਰੀਸਟੋਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਸਭ ਕੁਝ ਫਾਈਲ ਸਿਸਟਮ ਨਾਲ ਠੀਕ ਹੈ। ਅਤੇ ਗਲਤੀਆਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਉਹਨਾਂ ਨੂੰ ਠੀਕ ਕਰੋ, ਕਿਉਂਕਿ ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ ਚੀਜ਼ਾਂ ਨੂੰ ਵਿਗੜ ਸਕਦੇ ਹੋ.

ਮੇਰੇ ਕੇਸ ਵਿੱਚ, ਡੇਟਾਬੇਸ ਦੇ ਨਾਲ ਫਾਈਲ ਸਿਸਟਮ ਵਿੱਚ ਮਾਊਂਟ ਕੀਤਾ ਗਿਆ ਸੀ "/srv" ਅਤੇ ਕਿਸਮ ext4 ਸੀ।

ਡਾਟਾਬੇਸ ਨੂੰ ਰੋਕਣਾ: systemctl stop [ਈਮੇਲ ਸੁਰੱਖਿਅਤ] ਅਤੇ ਜਾਂਚ ਕਰੋ ਕਿ ਫਾਈਲ ਸਿਸਟਮ ਕਿਸੇ ਦੁਆਰਾ ਵਰਤੋਂ ਵਿੱਚ ਨਹੀਂ ਹੈ ਅਤੇ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਨਮਾਊਂਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ lsof:
lsof +D /srv

ਮੈਨੂੰ redis ਡੇਟਾਬੇਸ ਨੂੰ ਵੀ ਰੋਕਣਾ ਪਿਆ, ਕਿਉਂਕਿ ਇਹ ਵੀ ਵਰਤ ਰਿਹਾ ਸੀ "/srv". ਅੱਗੇ ਮੈਂ ਅਨਮਾਊਂਟ ਕੀਤਾ / ਐਸਆਰਵੀ (umount)।

ਉਪਯੋਗਤਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਫਾਈਲ ਸਿਸਟਮ ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ ਸੀ e2fsck ਸਵਿੱਚ ਦੇ ਨਾਲ -f (ਜੇਕਰ ਫਾਈਲ ਸਿਸਟਮ ਨੂੰ ਸਾਫ਼ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਤਾਂ ਵੀ ਜਾਂਚ ਕਰਨ ਲਈ ਜ਼ਬਰਦਸਤੀ ਕਰੋ):

ਅੱਗੇ, ਉਪਯੋਗਤਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ dumpe2fs (sudo dumpe2fs /dev/mapper/gu2—sys-srv | grep ਦੀ ਜਾਂਚ ਕੀਤੀ) ਤੁਸੀਂ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਜਾਂਚ ਅਸਲ ਵਿੱਚ ਕੀਤੀ ਗਈ ਸੀ:

e2fsck ਕਹਿੰਦਾ ਹੈ ਕਿ ext4 ਫਾਈਲ ਸਿਸਟਮ ਪੱਧਰ 'ਤੇ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਮਿਲੀ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਨੂੰ ਬਹਾਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹੋ, ਜਾਂ ਇਸ ਦੀ ਬਜਾਏ ਵਾਪਸ ਜਾ ਸਕਦੇ ਹੋ. ਵੈਕਿਊਮ ਭਰਿਆ (ਬੇਸ਼ੱਕ, ਤੁਹਾਨੂੰ ਫਾਈਲ ਸਿਸਟਮ ਨੂੰ ਵਾਪਸ ਮਾਊਂਟ ਕਰਨ ਅਤੇ ਡਾਟਾਬੇਸ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ)।

ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਭੌਤਿਕ ਸਰਵਰ ਹੈ, ਤਾਂ ਡਿਸਕਾਂ ਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰਨਾ ਯਕੀਨੀ ਬਣਾਓ (ਦੁਆਰਾ smartctl -a /dev/XXX) ਜਾਂ RAID ਕੰਟਰੋਲਰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਸਮੱਸਿਆ ਹਾਰਡਵੇਅਰ ਪੱਧਰ 'ਤੇ ਨਹੀਂ ਹੈ। ਮੇਰੇ ਕੇਸ ਵਿੱਚ, RAID "ਹਾਰਡਵੇਅਰ" ਨਿਕਲਿਆ, ਇਸਲਈ ਮੈਂ ਸਥਾਨਕ ਪ੍ਰਸ਼ਾਸਕ ਨੂੰ RAID ਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਕਿਹਾ (ਸਰਵਰ ਮੇਰੇ ਤੋਂ ਕਈ ਸੌ ਕਿਲੋਮੀਟਰ ਦੂਰ ਸੀ)। ਉਸ ਨੇ ਕਿਹਾ ਕਿ ਕੋਈ ਤਰੁੱਟੀਆਂ ਨਹੀਂ ਸਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਬਹਾਲੀ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਾਂ।

ਕੋਸ਼ਿਸ਼ 1: ਜ਼ੀਰੋ_ਨੁਕਸਾਨ ਵਾਲੇ_ਪੰਨੇ

ਅਸੀਂ ਇੱਕ ਖਾਤੇ ਨਾਲ psql ਦੁਆਰਾ ਡੇਟਾਬੇਸ ਨਾਲ ਜੁੜਦੇ ਹਾਂ ਜਿਸ ਕੋਲ ਸੁਪਰ ਉਪਭੋਗਤਾ ਅਧਿਕਾਰ ਹਨ। ਸਾਨੂੰ ਇੱਕ ਸੁਪਰਯੂਜ਼ਰ ਦੀ ਲੋੜ ਹੈ, ਕਿਉਂਕਿ... ਵਿਕਲਪ ਜ਼ੀਰੋ_ਨੁਕਸਾਨ ਵਾਲੇ_ਪੰਨੇ ਕੇਵਲ ਉਹ ਹੀ ਬਦਲ ਸਕਦਾ ਹੈ। ਮੇਰੇ ਕੇਸ ਵਿੱਚ ਇਹ ਪੋਸਟਗ੍ਰੇਸ ਹੈ:

psql -h 127.0.0.1 -U postgres -s [database_name]

ਵਿਕਲਪ ਜ਼ੀਰੋ_ਨੁਕਸਾਨ ਵਾਲੇ_ਪੰਨੇ ਪੜ੍ਹਨ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਲਈ ਲੋੜੀਂਦਾ ਹੈ (ਪੋਸਟਗ੍ਰੇਸਪ੍ਰੋ ਵੈਬਸਾਈਟ ਤੋਂ):

ਜਦੋਂ 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 - Poetgres ਵਿੱਚ "ਲੰਬੇ ਡੇਟਾ" ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਇੱਕ ਵਿਧੀ ਜੇਕਰ ਇਹ ਇੱਕ ਪੰਨੇ 'ਤੇ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦਾ (ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ 8kb)।

ਕੋਸ਼ਿਸ਼ 2: ਰੀਇੰਡੈਕਸ

ਗੂਗਲ ਦੀ ਪਹਿਲੀ ਸਲਾਹ ਨੇ ਮਦਦ ਨਹੀਂ ਕੀਤੀ. ਕੁਝ ਮਿੰਟਾਂ ਦੀ ਖੋਜ ਤੋਂ ਬਾਅਦ, ਮੈਨੂੰ ਦੂਜਾ ਸੁਝਾਅ ਮਿਲਿਆ - ਬਣਾਉਣ ਲਈ ਰੀਇੰਡੈਕਸ ਖਰਾਬ ਟੇਬਲ. ਮੈਂ ਇਸ ਸਲਾਹ ਨੂੰ ਕਈ ਥਾਵਾਂ 'ਤੇ ਦੇਖਿਆ, ਪਰ ਇਸ ਨੇ ਆਤਮ-ਵਿਸ਼ਵਾਸ ਨੂੰ ਪ੍ਰੇਰਿਤ ਨਹੀਂ ਕੀਤਾ। ਆਉ ਮੁੜ ਸੂਚੀਬੱਧ ਕਰੀਏ:

reindex table ws_log_smevlog

ਰੀਇੰਡੈਕਸ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਪੂਰਾ ਕੀਤਾ।

ਹਾਲਾਂਕਿ, ਇਸ ਨੇ ਮਦਦ ਨਹੀਂ ਕੀਤੀ, ਵੈਕਿਊਮ ਫੁਲ ਇੱਕ ਸਮਾਨ ਗਲਤੀ ਨਾਲ ਕਰੈਸ਼ ਹੋ ਗਿਆ। ਕਿਉਂਕਿ ਮੈਂ ਅਸਫਲਤਾਵਾਂ ਦਾ ਆਦੀ ਹਾਂ, ਮੈਂ ਇੰਟਰਨੈਟ 'ਤੇ ਸਲਾਹ ਲਈ ਹੋਰ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਅਤੇ ਇੱਕ ਦਿਲਚਸਪ ਗੱਲ ਸਾਹਮਣੇ ਆਈ ਲੇਖ.

ਕੋਸ਼ਿਸ਼ 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 ਲਾਈਨਾਂ! ਇਸਦੀ ਚੰਗੀ ਦੇਖਭਾਲ ਕਰਨੀ ਜ਼ਰੂਰੀ ਸੀ ਡਾਟਾ ਵਿਭਾਗੀਕਰਨ, ਪਰ ਇਹ ਇੱਕ ਵੱਖਰੀ ਚਰਚਾ ਦਾ ਵਿਸ਼ਾ ਹੈ। ਇਹ ਸ਼ਨੀਵਾਰ ਸੀ, ਮੈਂ ਇਹ ਹੁਕਮ tmux ਵਿੱਚ ਚਲਾਇਆ ਅਤੇ ਸੌਣ ਗਿਆ:

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 ਸੀਮਾ ਲਈ ਕਤਾਰਾਂ ਦੀ ਗਿਣਤੀ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ।

ਸੀਮਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ORDER BY ਧਾਰਾ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ ਤਾਂ ਜੋ ਨਤੀਜਾ ਕਤਾਰਾਂ ਇੱਕ ਖਾਸ ਕ੍ਰਮ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਣ। ਨਹੀਂ ਤਾਂ, ਕਤਾਰਾਂ ਦੇ ਅਣਪਛਾਤੇ ਸਬਸੈੱਟ ਵਾਪਸ ਕੀਤੇ ਜਾਣਗੇ।

ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਉਪਰੋਕਤ ਹੁਕਮ ਗਲਤ ਸੀ: ਪਹਿਲਾਂ, ਕੋਈ ਨਹੀਂ ਸੀ ਦੁਆਰਾ ਆਰਡਰ, ਨਤੀਜਾ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ। ਦੂਜਾ, ਪੋਸਟਗ੍ਰੇਸ ਨੂੰ ਪਹਿਲਾਂ OFFSET ਕਤਾਰਾਂ ਨੂੰ ਸਕੈਨ ਕਰਨਾ ਅਤੇ ਛੱਡਣਾ ਪਿਆ, ਅਤੇ ਵਧਦੇ ਹੋਏ OFFSET ਉਤਪਾਦਕਤਾ ਹੋਰ ਵੀ ਘੱਟ ਜਾਵੇਗੀ।

ਕੋਸ਼ਿਸ਼ 4: ਟੈਕਸਟ ਰੂਪ ਵਿੱਚ ਇੱਕ ਡੰਪ ਲਓ

ਫਿਰ ਮੇਰੇ ਦਿਮਾਗ ਵਿੱਚ ਇੱਕ ਪ੍ਰਤੀਤ ਹੁੰਦਾ ਸ਼ਾਨਦਾਰ ਵਿਚਾਰ ਆਇਆ: ਟੈਕਸਟ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਡੰਪ ਲਓ ਅਤੇ ਆਖਰੀ ਰਿਕਾਰਡ ਕੀਤੀ ਲਾਈਨ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ।

ਪਰ ਪਹਿਲਾਂ, ਆਓ ਸਾਰਣੀ ਦੀ ਬਣਤਰ 'ਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ। ws_log_smevlog:

ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਸਾਡੇ ਕੋਲ ਇੱਕ ਕਾਲਮ ਹੈ "ਆਈਡੀ", ਜਿਸ ਵਿੱਚ ਕਤਾਰ ਦਾ ਵਿਲੱਖਣ ਪਛਾਣਕਰਤਾ (ਕਾਊਂਟਰ) ਹੁੰਦਾ ਹੈ। ਯੋਜਨਾ ਇਸ ਤਰ੍ਹਾਂ ਸੀ:

1. ਅਸੀਂ ਟੈਕਸਟ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਡੰਪ ਲੈਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ (sql ਕਮਾਂਡਾਂ ਦੇ ਰੂਪ ਵਿੱਚ)
2. ਸਮੇਂ ਦੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਬਿੰਦੂ ਤੇ, ਇੱਕ ਗਲਤੀ ਦੇ ਕਾਰਨ ਡੰਪ ਵਿੱਚ ਵਿਘਨ ਪੈ ਜਾਵੇਗਾ, ਪਰ ਟੈਕਸਟ ਫਾਈਲ ਅਜੇ ਵੀ ਡਿਸਕ ਤੇ ਸੁਰੱਖਿਅਤ ਕੀਤੀ ਜਾਵੇਗੀ।
3. ਅਸੀਂ ਟੈਕਸਟ ਫਾਈਲ ਦੇ ਅੰਤ ਨੂੰ ਦੇਖਦੇ ਹਾਂ, ਇਸ ਤਰ੍ਹਾਂ ਸਾਨੂੰ ਆਖਰੀ ਲਾਈਨ ਦਾ ਪਛਾਣਕਰਤਾ (id) ਮਿਲਦਾ ਹੈ ਜੋ ਸਫਲਤਾਪੂਰਵਕ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਸੀ

ਮੈਂ ਟੈਕਸਟ ਰੂਪ ਵਿੱਚ ਇੱਕ ਡੰਪ ਲੈਣਾ ਸ਼ੁਰੂ ਕੀਤਾ:

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

ਦੁਆਰਾ ਅੱਗੇ ਪੂਛ ਮੈਂ ਡੰਪ ਦੇ ਸਿਰੇ ਵੱਲ ਦੇਖਿਆ (tail -5 ./my_dump.dump) ਨੇ ਖੋਜ ਕੀਤੀ ਕਿ ਡੰਪ ਨੂੰ id ਨਾਲ ਲਾਈਨ 'ਤੇ ਰੁਕਾਵਟ ਪਾਈ ਗਈ ਸੀ 186 525. "ਇਸ ਲਈ ਸਮੱਸਿਆ ਆਈਡੀ 186 526 ਦੇ ਨਾਲ ਹੈ, ਇਹ ਟੁੱਟ ਗਈ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਮਿਟਾਉਣ ਦੀ ਲੋੜ ਹੈ!" - ਮੈਂ ਸੋਚਿਆ. ਪਰ, ਡੇਟਾਬੇਸ ਲਈ ਇੱਕ ਪੁੱਛਗਿੱਛ ਕਰਨਾ:
«ws_log_smevlog ਤੋਂ * ਚੁਣੋ ਜਿੱਥੇ id=186529 ਹੈ"ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਇਸ ਲਾਈਨ ਨਾਲ ਸਭ ਕੁਝ ਠੀਕ ਸੀ... 186 - 530 ਸੂਚਕਾਂਕ ਵਾਲੀਆਂ ਕਤਾਰਾਂ ਨੇ ਵੀ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਕੰਮ ਕੀਤਾ। ਇੱਕ ਹੋਰ "ਸ਼ਾਨਦਾਰ ਵਿਚਾਰ" ਅਸਫਲ ਰਿਹਾ। ਬਾਅਦ ਵਿੱਚ ਮੈਂ ਸਮਝ ਗਿਆ ਕਿ ਅਜਿਹਾ ਕਿਉਂ ਹੋਇਆ: ਜਦੋਂ ਕਿਸੇ ਟੇਬਲ ਤੋਂ ਡੇਟਾ ਨੂੰ ਮਿਟਾਉਣਾ ਅਤੇ ਬਦਲਣਾ, ਉਹ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਨਹੀਂ ਮਿਟਾਏ ਜਾਂਦੇ, ਪਰ "ਡੈੱਡ ਟੂਪਲਜ਼" ਵਜੋਂ ਮਾਰਕ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਫਿਰ ਆਉਂਦਾ ਹੈ ਆਟੋਵੈਕਿਊਮ ਅਤੇ ਇਹਨਾਂ ਲਾਈਨਾਂ ਨੂੰ ਮਿਟਾਏ ਗਏ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹਨਾਂ ਲਾਈਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਇਹ ਸਮਝਣ ਲਈ, ਜੇਕਰ ਸਾਰਣੀ ਵਿੱਚ ਡੇਟਾ ਬਦਲਦਾ ਹੈ ਅਤੇ ਆਟੋਵੈਕਿਊਮ ਸਮਰੱਥ ਹੈ, ਤਾਂ ਇਹ ਕ੍ਰਮਵਾਰ ਸਟੋਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਕੋਸ਼ਿਸ਼ 5: ਚੁਣੋ, FROM, 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: ਚੁਣੋ, FROM, WHERE id >= ਅਤੇ id

ਗਾਹਕ ਕੋਲ ਡੇਟਾਬੇਸ ਨੂੰ ਸਮਰਪਿਤ ਇੱਕ ਸ਼ਾਨਦਾਰ ਸਰਵਰ ਸੀ: ਦੋਹਰਾ-ਪ੍ਰੋਸੈਸਰ Intel 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 ਦੇ ਵਿਚਕਾਰ ਸਨ। ਅੱਗੇ, ਸਾਨੂੰ ਸਿਰਫ਼ ਸਮੱਸਿਆ ਦੇ ਰਿਕਾਰਡਾਂ ਦਾ ਸਹੀ id ਮੁੱਲ ਲੱਭਣਾ ਸੀ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ 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