Patroni ਅਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ ਜਾਂ ਤੁਹਾਡੇ PostgreSQL ਕਲੱਸਟਰ ਨੂੰ ਕਿਵੇਂ ਕ੍ਰੈਸ਼ ਕਰਨਾ ਹੈ। ਅਲੈਕਸੀ ਲੇਸੋਵਸਕੀ

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

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

ਅਤੇ 2018 ਦੇ ਅੰਤ ਵਿੱਚ, ਅਸੀਂ ਹੌਲੀ ਹੌਲੀ Patroni ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ। ਅਤੇ ਕੁਝ ਤਜਰਬਾ ਇਕੱਠਾ ਕੀਤਾ ਗਿਆ ਹੈ. ਅਸੀਂ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਸਦਾ ਨਿਦਾਨ ਕੀਤਾ, ਇਸ ਨੂੰ ਟਿਊਨ ਕੀਤਾ, ਸਾਡੇ ਵਧੀਆ ਅਭਿਆਸਾਂ 'ਤੇ ਆਏ। ਅਤੇ ਇਸ ਰਿਪੋਰਟ ਵਿੱਚ ਮੈਂ ਉਨ੍ਹਾਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ।

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

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

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

ਅਤੇ ਸਾਡੀ ਰਿਪੋਰਟ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਬੇਦਾਅਵਾ।

ਇਹ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਜਿਨ੍ਹਾਂ ਦਾ ਸਾਨੂੰ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ, ਅਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਓਪਰੇਸ਼ਨ ਦੇ ਪਹਿਲੇ 6-7-8 ਮਹੀਨਿਆਂ ਵਿੱਚ ਕੀਤਾ। ਸਮੇਂ ਦੇ ਨਾਲ, ਅਸੀਂ ਆਪਣੇ ਅੰਦਰੂਨੀ ਵਧੀਆ ਅਭਿਆਸਾਂ 'ਤੇ ਆ ਗਏ. ਅਤੇ ਸਾਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੂਰ ਹੋ ਗਈਆਂ। ਇਸ ਲਈ, ਰਿਪੋਰਟ ਦੀ ਘੋਸ਼ਣਾ ਲਗਭਗ ਛੇ ਮਹੀਨੇ ਪਹਿਲਾਂ ਕੀਤੀ ਗਈ ਸੀ, ਜਦੋਂ ਇਹ ਸਭ ਮੇਰੇ ਦਿਮਾਗ ਵਿੱਚ ਤਾਜ਼ਾ ਸੀ ਅਤੇ ਮੈਨੂੰ ਇਹ ਸਭ ਚੰਗੀ ਤਰ੍ਹਾਂ ਯਾਦ ਸੀ।

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

Patroni ਕੀ ਹੈ?

• ਇਹ HA ਬਣਾਉਣ ਲਈ ਇੱਕ ਟੈਪਲੇਟ ਹੈ। ਇਹ ਉਹੀ ਹੈ ਜੋ ਇਹ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਕਹਿੰਦਾ ਹੈ. ਅਤੇ ਮੇਰੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਸਹੀ ਸਪਸ਼ਟੀਕਰਨ ਹੈ. ਪੈਟਰੋਨੀ ਕੋਈ ਚਾਂਦੀ ਦੀ ਗੋਲੀ ਨਹੀਂ ਹੈ ਜੋ ਤੁਹਾਡੀਆਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰ ਦੇਵੇਗੀ, ਯਾਨੀ ਤੁਹਾਨੂੰ ਇਸ ਨੂੰ ਕੰਮ ਕਰਨ ਅਤੇ ਲਾਭ ਲਿਆਉਣ ਲਈ ਯਤਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
• ਇਹ ਇੱਕ ਏਜੰਟ ਸੇਵਾ ਹੈ ਜੋ ਹਰੇਕ ਡਾਟਾਬੇਸ ਸੇਵਾ 'ਤੇ ਸਥਾਪਿਤ ਹੁੰਦੀ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਪੋਸਟਗ੍ਰੇਸ ਲਈ ਇੱਕ ਕਿਸਮ ਦਾ init ਸਿਸਟਮ ਹੈ। ਇਹ ਪੋਸਟਗ੍ਰੇਸ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਰੁਕਦਾ ਹੈ, ਮੁੜ ਚਾਲੂ ਕਰਦਾ ਹੈ, ਮੁੜ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਕਲੱਸਟਰ ਦੀ ਟੌਪੋਲੋਜੀ ਨੂੰ ਬਦਲਦਾ ਹੈ।
• ਇਸ ਅਨੁਸਾਰ, ਕਲੱਸਟਰ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ, ਇਸਦੀ ਮੌਜੂਦਾ ਪ੍ਰਤੀਨਿਧਤਾ, ਜਿਵੇਂ ਕਿ ਇਹ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਕਿਸੇ ਕਿਸਮ ਦੀ ਸਟੋਰੇਜ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ. ਅਤੇ ਇਸ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਪਟਰੋਨੀ ਨੇ ਰਾਜ ਨੂੰ ਇੱਕ ਬਾਹਰੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਸਟੋਰ ਕਰਨ ਦਾ ਰਾਹ ਅਪਣਾਇਆ। ਇਹ ਇੱਕ ਵੰਡਿਆ ਸੰਰਚਨਾ ਸਟੋਰੇਜ਼ ਸਿਸਟਮ ਹੈ. ਇਹ Etcd, Consul, ZooKeeper, ਜਾਂ kubernetes Etcd ਹੋ ਸਕਦਾ ਹੈ, ਭਾਵ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿਕਲਪ।
• ਅਤੇ ਪੈਟਰੋਨੀ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਆਟੋਫਾਈਲਰ ਨੂੰ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ, ਸਿਰਫ ਇਸਨੂੰ ਸੈਟ ਅਪ ਕਰਕੇ. ਜੇਕਰ ਅਸੀਂ ਤੁਲਨਾ ਲਈ Repmgr ਲੈਂਦੇ ਹਾਂ, ਤਾਂ ਫਾਈਲਰ ਉੱਥੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। Repmgr ਦੇ ਨਾਲ, ਸਾਨੂੰ ਇੱਕ ਸਵਿੱਚਓਵਰ ਮਿਲਦਾ ਹੈ, ਪਰ ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਆਟੋਫਾਈਲਰ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਇਸ ਨੂੰ ਵਾਧੂ ਸੰਰਚਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। Patroni ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਇੱਕ ਆਟੋਫਾਈਲਰ ਆਊਟ ਆਫ਼ ਬਾਕਸ ਹੈ।
• ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਹਨ. ਉਦਾਹਰਨ ਲਈ, ਸੰਰਚਨਾ ਦਾ ਰੱਖ-ਰਖਾਅ, ਨਵੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ, ਬੈਕਅੱਪ, ਆਦਿ, ਪਰ ਇਹ ਰਿਪੋਰਟ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹੈ, ਮੈਂ ਇਸ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰਾਂਗਾ।

ਅਤੇ ਇੱਕ ਛੋਟਾ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਪੈਟਰੋਨੀ ਦਾ ਮੁੱਖ ਕੰਮ ਇੱਕ ਆਟੋਫਾਈਲ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਤੇ ਭਰੋਸੇਮੰਦ ਢੰਗ ਨਾਲ ਕਰਨਾ ਹੈ ਤਾਂ ਜੋ ਸਾਡਾ ਕਲੱਸਟਰ ਚਾਲੂ ਰਹੇ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਕਲੱਸਟਰ ਟੋਪੋਲੋਜੀ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਵੱਲ ਧਿਆਨ ਨਾ ਦੇਵੇ।

ਪਰ ਜਦੋਂ ਅਸੀਂ Patroni ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਾਡਾ ਸਿਸਟਮ ਥੋੜਾ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਪਹਿਲਾਂ ਸਾਡੇ ਕੋਲ Postgres ਸੀ, ਤਾਂ Patroni ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਸਾਨੂੰ Patroni ਹੀ ਮਿਲਦਾ ਹੈ, ਸਾਨੂੰ DCS ਮਿਲਦਾ ਹੈ ਜਿੱਥੇ ਸਟੇਟ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਅਤੇ ਇਹ ਸਭ ਕੁਝ ਕਿਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨਾ ਹੈ. ਇਸ ਲਈ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ?

ਟੁੱਟ ਸਕਦਾ ਹੈ:

• ਪੋਸਟਗ੍ਰੇਸ ਟੁੱਟ ਸਕਦਾ ਹੈ। ਇਹ ਇੱਕ ਮਾਸਟਰ ਜਾਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹੋ ਸਕਦਾ ਹੈ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ.
• ਪਟਰੋਨੀ ਆਪ ਹੀ ਟੁੱਟ ਸਕਦੀ ਹੈ।
• DCS ਜਿੱਥੇ ਸਟੇਟ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਟੁੱਟ ਸਕਦੀ ਹੈ।
• ਅਤੇ ਨੈੱਟਵਰਕ ਟੁੱਟ ਸਕਦਾ ਹੈ।

ਇਹ ਸਾਰੇ ਨੁਕਤੇ ਮੈਂ ਰਿਪੋਰਟ ਵਿੱਚ ਵਿਚਾਰਾਂਗਾ।

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

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

ਇਸ ਲਈ, ਇੱਕ ਫਾਈਲਰ ਸੀ, ਆਓ ਇਸ ਨਾਲ ਨਜਿੱਠਣ ਲਈ ਚੱਲੀਏ.

ਅਤੇ ਇੱਥੇ ਅਸੀਂ ਇਸ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਾਂ ਕਿ ਫਾਈਲਰ ਕਦੋਂ ਹੋਇਆ. ਭਾਵ, ਅਸੀਂ ਸਮੇਂ ਦੇ ਇਸ ਪਲ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਾਂ ਜਦੋਂ ਕਲੱਸਟਰ ਸਥਿਤੀ ਬਦਲ ਗਈ ਸੀ।

ਪਰ ਫਾਈਲਰ ਹਮੇਸ਼ਾ ਤਤਕਾਲ ਨਹੀਂ ਹੁੰਦਾ, ਯਾਨੀ ਇਹ ਸਮੇਂ ਦੀ ਕੋਈ ਇਕਾਈ ਨਹੀਂ ਲੈਂਦਾ, ਇਸ ਵਿੱਚ ਦੇਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲਾ ਹੋ ਸਕਦਾ ਹੈ।

ਇਸ ਲਈ, ਇਸਦਾ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਸਮਾਂ ਅਤੇ ਇੱਕ ਅੰਤ ਸਮਾਂ ਹੈ, ਭਾਵ ਇਹ ਇੱਕ ਨਿਰੰਤਰ ਘਟਨਾ ਹੈ। ਅਤੇ ਅਸੀਂ ਸਾਰੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਤਿੰਨ ਅੰਤਰਾਲਾਂ ਵਿੱਚ ਵੰਡਦੇ ਹਾਂ: ਸਾਡੇ ਕੋਲ ਫਾਈਲਰ ਤੋਂ ਪਹਿਲਾਂ, ਫਾਈਲਰ ਦੇ ਦੌਰਾਨ ਅਤੇ ਫਾਈਲਰ ਤੋਂ ਬਾਅਦ ਸਮਾਂ ਹੁੰਦਾ ਹੈ. ਭਾਵ, ਅਸੀਂ ਇਸ ਟਾਈਮਲਾਈਨ ਵਿੱਚ ਸਾਰੀਆਂ ਘਟਨਾਵਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਦੇ ਹਾਂ।

ਅਤੇ ਪਹਿਲੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਕੋਈ ਫਾਈਲਰ ਵਾਪਰਿਆ, ਅਸੀਂ ਇਸ ਦੇ ਕਾਰਨ ਦੀ ਖੋਜ ਕਰਦੇ ਹਾਂ ਕਿ ਕੀ ਹੋਇਆ, ਫਾਈਲਰ ਦੀ ਅਗਵਾਈ ਕਰਨ ਦਾ ਕਾਰਨ ਕੀ ਸੀ।

ਜੇਕਰ ਅਸੀਂ ਲੌਗਸ ਨੂੰ ਦੇਖਦੇ ਹਾਂ, ਤਾਂ ਉਹ ਕਲਾਸਿਕ ਪੈਟਰੋਨੀ ਲੌਗ ਹੋਣਗੇ। ਉਹ ਸਾਨੂੰ ਉਹਨਾਂ ਵਿੱਚ ਦੱਸਦਾ ਹੈ ਕਿ ਸਰਵਰ ਮਾਸਟਰ ਬਣ ਗਿਆ ਹੈ, ਅਤੇ ਮਾਸਟਰ ਦੀ ਭੂਮਿਕਾ ਇਸ ਨੋਡ ਵਿੱਚ ਲੰਘ ਗਈ ਹੈ. ਇੱਥੇ ਇਸ ਨੂੰ ਉਜਾਗਰ ਕੀਤਾ ਗਿਆ ਹੈ.

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

ਜੇ ਅਸੀਂ ਫਾਈਲਰ ਤੋਂ ਪਹਿਲਾਂ ਦੀਆਂ ਘਟਨਾਵਾਂ 'ਤੇ ਨਜ਼ਰ ਮਾਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਉੱਥੇ ਉਹੀ ਕਾਰਨ ਦੇਖ ਸਕਦੇ ਹਾਂ ਜੋ ਵਿਜ਼ਾਰਡ ਨੂੰ ਜਾਰੀ ਰੱਖਣ ਲਈ ਸਮੱਸਿਆ ਸਨ।

ਜੇਕਰ ਅਸੀਂ ਪੈਟਰੋਨੀ ਲੌਗਸ ਨੂੰ ਦੇਖਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੀਆਂ ਤਰੁੱਟੀਆਂ ਹਨ, ਸਮਾਂ ਸਮਾਪਤ ਹੋ ਗਿਆ ਹੈ, ਯਾਨੀ ਕਿ ਪੈਟਰੋਨੀ ਏਜੰਟ DCS ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਕੇਸ ਵਿੱਚ, ਇਹ ਕੌਂਸਲ ਏਜੰਟ ਹੈ, ਜੋ ਪੋਰਟ 8500 'ਤੇ ਸੰਚਾਰ ਕਰ ਰਿਹਾ ਹੈ।

ਅਤੇ ਇੱਥੇ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਪੈਟਰੋਨੀ ਅਤੇ ਡੇਟਾਬੇਸ ਇੱਕੋ ਹੋਸਟ 'ਤੇ ਚੱਲ ਰਹੇ ਹਨ। ਅਤੇ ਕੌਂਸਲ ਸਰਵਰ ਉਸੇ ਨੋਡ 'ਤੇ ਲਾਂਚ ਕੀਤੇ ਗਏ ਸਨ। ਸਰਵਰ 'ਤੇ ਲੋਡ ਬਣਾ ਕੇ, ਅਸੀਂ ਕੌਂਸਲ ਸਰਵਰਾਂ ਲਈ ਵੀ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕੀਤੀਆਂ ਹਨ। ਉਹ ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਚਾਰ ਨਹੀਂ ਕਰ ਸਕਦੇ ਸਨ।

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

ਅਤੇ ਇਸ ਨੂੰ ਇੱਕ ਗਲਤ ਅਲਾਰਮ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਾਂ ਇਹ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਪੈਟਰੋਨੀ ਨੇ ਸਭ ਕੁਝ ਸਹੀ ਕੀਤਾ. ਭਾਵ, ਉਸਨੇ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਉਹ ਕਲੱਸਟਰ ਦੀ ਸਥਿਤੀ ਨੂੰ ਕਾਇਮ ਨਹੀਂ ਰੱਖ ਸਕਦਾ ਸੀ ਅਤੇ ਉਸਨੇ ਆਪਣਾ ਅਧਿਕਾਰ ਹਟਾ ਦਿੱਤਾ ਸੀ।

ਅਤੇ ਇੱਥੇ ਸਮੱਸਿਆ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਪੈਦਾ ਹੋਈ ਕਿ ਕੌਂਸਲ ਸਰਵਰ ਉਸੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਹਨ ਜਿਵੇਂ ਕਿ ਬੇਸ. ਇਸ ਅਨੁਸਾਰ, ਕੋਈ ਵੀ ਲੋਡ: ਭਾਵੇਂ ਇਹ ਡਿਸਕ ਜਾਂ ਪ੍ਰੋਸੈਸਰਾਂ 'ਤੇ ਲੋਡ ਹੋਵੇ, ਇਹ ਕੌਂਸਿਲ ਕਲੱਸਟਰ ਨਾਲ ਗੱਲਬਾਤ ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

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

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

ਪਹਿਲੀ ਸਮੱਸਿਆ, ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ, ਸਧਾਰਨ ਹੈ. ਅਸੀਂ DCS ਨੂੰ ਅਧਾਰ ਦੇ ਨਾਲ ਲਿਆ ਅਤੇ ਪਾ ਦਿੱਤਾ, ਸਾਨੂੰ ਇੱਕ ਸਮੱਸਿਆ ਆਈ.

ਦੂਜੀ ਸਮੱਸਿਆ ਪਹਿਲੀ ਦੇ ਸਮਾਨ ਹੈ. ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੈ ਕਿ ਸਾਨੂੰ ਦੁਬਾਰਾ DCS ਸਿਸਟਮ ਨਾਲ ਅੰਤਰ-ਕਾਰਜਸ਼ੀਲਤਾ ਸਮੱਸਿਆਵਾਂ ਹਨ।

ਜੇਕਰ ਅਸੀਂ ਲੌਗਸ 'ਤੇ ਨਜ਼ਰ ਮਾਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਸਾਡੇ ਕੋਲ ਫਿਰ ਤੋਂ ਇੱਕ ਸੰਚਾਰ ਗਲਤੀ ਹੈ। ਅਤੇ Patroni ਕਹਿੰਦਾ ਹੈ ਕਿ ਮੈਂ DCS ਨਾਲ ਇੰਟਰੈਕਟ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹਾਂ ਇਸਲਈ ਮੌਜੂਦਾ ਮਾਸਟਰ ਰੀਪਲੀਕਾ ਮੋਡ ਵਿੱਚ ਚਲਾ ਜਾਂਦਾ ਹੈ।

ਪੁਰਾਣਾ ਮਾਸਟਰ ਇੱਕ ਪ੍ਰਤੀਰੂਪ ਬਣ ਜਾਂਦਾ ਹੈ, ਇੱਥੇ ਪਟਰੋਨੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਹ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਨੂੰ ਰੀਵਾਇੰਡ ਕਰਨ ਲਈ pg_rewind ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਫਿਰ ਨਵੇਂ ਮਾਸਟਰ ਨਾਲ ਜੁੜਨ ਲਈ ਨਵੇਂ ਮਾਸਟਰ ਨਾਲ ਜੁੜਦਾ ਹੈ। ਇੱਥੇ Patroni ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਉਸਨੂੰ ਚਾਹੀਦਾ ਹੈ।

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

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

ਅਤੇ ਉਸ ਬਿੰਦੂ ਤੱਕ ਸਕ੍ਰੋਲ ਕਰਨ ਤੋਂ ਬਾਅਦ ਜਿੱਥੇ ਗਲਤੀਆਂ ਦਿਖਾਈ ਦੇਣੀਆਂ ਸ਼ੁਰੂ ਹੋਈਆਂ, ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ ਆਟੋ-ਫਾਈਲਓਵਰ ਹੈ। ਅਤੇ ਕਿਉਂਕਿ ਸਾਡੀਆਂ ਗਲਤੀਆਂ DCS ਨਾਲ ਗੱਲਬਾਤ ਨਾਲ ਸਬੰਧਤ ਸਨ ਅਤੇ ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਅਸੀਂ ਕੌਂਸਲ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਅਸੀਂ ਕੌਂਸਲ ਲੌਗਸ ਨੂੰ ਵੀ ਦੇਖਦੇ ਹਾਂ, ਉੱਥੇ ਕੀ ਹੋਇਆ ਸੀ।

ਮੋਟੇ ਤੌਰ 'ਤੇ ਫਾਈਲਰ ਦੇ ਸਮੇਂ ਅਤੇ ਕੌਂਸਲ ਲੌਗਸ ਵਿੱਚ ਸਮੇਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਕੌਂਸਲ ਕਲੱਸਟਰ ਵਿੱਚ ਸਾਡੇ ਗੁਆਂਢੀਆਂ ਨੇ ਕੌਂਸਲ ਕਲੱਸਟਰ ਦੇ ਦੂਜੇ ਮੈਂਬਰਾਂ ਦੀ ਮੌਜੂਦਗੀ 'ਤੇ ਸ਼ੱਕ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ।

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

ਜੇ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਇਹਨਾਂ ਤਰੁਟੀਆਂ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਹੋਇਆ ਸੀ, ਤਾਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਇੱਥੇ ਹਰ ਤਰ੍ਹਾਂ ਦੀਆਂ ਤਰੁੱਟੀਆਂ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਡੈੱਡਲਾਈਨ, ਆਰਪੀਸੀ ਡਿੱਗ ਗਈ, ਯਾਨੀ ਕਿ ਕੌਂਸਲ ਕਲੱਸਟਰ ਦੇ ਮੈਂਬਰਾਂ ਦੇ ਆਪਸ ਵਿੱਚ ਗੱਲਬਾਤ ਕਰਨ ਵਿੱਚ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕਿਸੇ ਕਿਸਮ ਦੀ ਸਮੱਸਿਆ ਹੈ। .

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

ਇੱਥੇ ਵਿਕਲਪ ਹਨ:

• ਸਭ ਤੋਂ ਸਰਲ ਵਿਕਲਪ, ਜੋ ਕਿ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਵੀ, ਕਾਉਂਸਲ ਜਾਂਚਾਂ ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਉਣਾ ਹੈ, ਭਾਵ, ਇੱਕ ਖਾਲੀ ਐਰੇ ਪਾਸ ਕਰਨਾ ਹੈ। ਅਤੇ ਅਸੀਂ ਕੌਂਸਲ ਏਜੰਟ ਨੂੰ ਕਿਸੇ ਵੀ ਚੈਕ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹਾਂ। ਇਹਨਾਂ ਜਾਂਚਾਂ ਦੇ ਨਾਲ, ਅਸੀਂ ਇਹਨਾਂ ਨੈਟਵਰਕ ਤੂਫਾਨਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਇੱਕ ਫਾਈਲਰ ਦੀ ਸ਼ੁਰੂਆਤ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਾਂ.
• ਇੱਕ ਹੋਰ ਵਿਕਲਪ ਹੈ raft_multiplier ਨੂੰ ਡਬਲ ਚੈੱਕ ਕਰਨਾ। ਇਹ ਕੌਂਸਲ ਸਰਵਰ ਦਾ ਇੱਕ ਪੈਰਾਮੀਟਰ ਹੈ। ਮੂਲ ਰੂਪ ਵਿੱਚ, ਇਹ 5 'ਤੇ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਹ ਮੁੱਲ ਸਟੇਜਿੰਗ ਵਾਤਾਵਰਨ ਲਈ ਦਸਤਾਵੇਜ਼ਾਂ ਦੁਆਰਾ ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਕੌਂਸਲ ਨੈਟਵਰਕ ਦੇ ਮੈਂਬਰਾਂ ਵਿਚਕਾਰ ਮੈਸੇਜਿੰਗ ਦੀ ਬਾਰੰਬਾਰਤਾ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ. ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਪੈਰਾਮੀਟਰ ਕੌਂਸਲ ਕਲੱਸਟਰ ਦੇ ਮੈਂਬਰਾਂ ਵਿਚਕਾਰ ਸੇਵਾ ਸੰਚਾਰ ਦੀ ਗਤੀ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਅਤੇ ਉਤਪਾਦਨ ਲਈ, ਪਹਿਲਾਂ ਹੀ ਇਸ ਨੂੰ ਘਟਾਉਣ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਜੋ ਨੋਡਸ ਸੁਨੇਹਿਆਂ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਅਕਸਰ ਕਰਦੇ ਹਨ.
• ਇੱਕ ਹੋਰ ਵਿਕਲਪ ਜੋ ਅਸੀਂ ਲੈ ਕੇ ਆਏ ਹਾਂ ਉਹ ਹੈ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਪ੍ਰਕਿਰਿਆ ਸ਼ਡਿਊਲਰ ਲਈ ਹੋਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਵਿਚਕਾਰ ਕੌਂਸਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਤਰਜੀਹ ਨੂੰ ਵਧਾਉਣਾ। ਅਜਿਹਾ ਇੱਕ "ਚੰਗਾ" ਪੈਰਾਮੀਟਰ ਹੈ, ਇਹ ਕੇਵਲ ਉਹਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਤਰਜੀਹ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਜੋ OS ਸ਼ਡਿਊਲਰ ਦੁਆਰਾ ਸਮਾਂ-ਤਹਿ ਕਰਨ ਵੇਲੇ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ. ਅਸੀਂ ਕੌਂਸਲ ਏਜੰਟਾਂ ਲਈ ਚੰਗੇ ਮੁੱਲ ਨੂੰ ਵੀ ਘਟਾ ਦਿੱਤਾ ਹੈ, ਯਾਨੀ. ਪਹਿਲ ਨੂੰ ਵਧਾ ਦਿੱਤਾ ਹੈ ਤਾਂ ਜੋ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਕੌਂਸਲ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਕੰਮ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਦੇ ਕੋਡ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਵਧੇਰੇ ਸਮਾਂ ਦੇਵੇ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇਸ ਨੇ ਸਾਡੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ।
• ਇਕ ਹੋਰ ਵਿਕਲਪ ਕੌਂਸਲ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨਾ ਹੈ। ਮੇਰਾ ਇੱਕ ਦੋਸਤ ਹੈ ਜੋ Etcd ਦਾ ਇੱਕ ਵੱਡਾ ਸਮਰਥਕ ਹੈ। ਅਤੇ ਅਸੀਂ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਉਸ ਨਾਲ ਬਹਿਸ ਕਰਦੇ ਹਾਂ ਕਿ ਕਿਹੜਾ ਬਿਹਤਰ ਹੈ Etcd ਜਾਂ Consul. ਪਰ ਜਿਸ ਦੇ ਰੂਪ ਵਿੱਚ ਬਿਹਤਰ ਹੈ, ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਨਾਲ ਸਹਿਮਤ ਹੁੰਦੇ ਹਾਂ ਕਿ ਕੌਂਸਲ ਕੋਲ ਇੱਕ ਏਜੰਟ ਹੈ ਜੋ ਇੱਕ ਡੇਟਾਬੇਸ ਦੇ ਨਾਲ ਹਰੇਕ ਨੋਡ 'ਤੇ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਯਾਨੀ, ਕੌਂਸਲਰ ਕਲੱਸਟਰ ਦੇ ਨਾਲ ਪੈਟ੍ਰੋਨੀ ਦੀ ਗੱਲਬਾਤ ਇਸ ਏਜੰਟ ਰਾਹੀਂ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਇਹ ਏਜੰਟ ਇੱਕ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦਾ ਹੈ. ਜੇ ਏਜੰਟ ਨੂੰ ਕੁਝ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਪੈਟਰੋਨੀ ਹੁਣ ਕੌਂਸਲ ਕਲਸਟਰ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਅਤੇ ਇਹ ਸਮੱਸਿਆ ਹੈ. Etcd ਯੋਜਨਾ ਵਿੱਚ ਕੋਈ ਏਜੰਟ ਨਹੀਂ ਹੈ। Patroni Etcd ਸਰਵਰਾਂ ਦੀ ਸੂਚੀ ਦੇ ਨਾਲ ਸਿੱਧਾ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਪਹਿਲਾਂ ਹੀ ਸੰਚਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਸਬੰਧ ਵਿੱਚ, ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੀ ਕੰਪਨੀ ਵਿੱਚ Etcd ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ Etcd ਸ਼ਾਇਦ ਕੌਂਸਲ ਨਾਲੋਂ ਬਿਹਤਰ ਵਿਕਲਪ ਹੋਵੇਗਾ। ਪਰ ਅਸੀਂ ਆਪਣੇ ਗਾਹਕਾਂ 'ਤੇ ਹਮੇਸ਼ਾ ਇਸ ਗੱਲ ਤੋਂ ਸੀਮਤ ਹੁੰਦੇ ਹਾਂ ਕਿ ਗਾਹਕ ਦੁਆਰਾ ਕੀ ਚੁਣਿਆ ਅਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਸਾਡੇ ਕੋਲ ਜ਼ਿਆਦਾਤਰ ਗਾਹਕਾਂ ਲਈ ਕੌਂਸਲ ਹੈ।
• ਅਤੇ ਆਖਰੀ ਬਿੰਦੂ ਪੈਰਾਮੀਟਰ ਮੁੱਲਾਂ ਨੂੰ ਸੋਧਣਾ ਹੈ. ਅਸੀਂ ਇਹਨਾਂ ਮਾਪਦੰਡਾਂ ਨੂੰ ਇਸ ਉਮੀਦ ਵਿੱਚ ਵਧਾ ਸਕਦੇ ਹਾਂ ਕਿ ਸਾਡੀਆਂ ਛੋਟੀਆਂ-ਮਿਆਦ ਦੀਆਂ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆਵਾਂ ਛੋਟੀਆਂ ਹੋਣਗੀਆਂ ਅਤੇ ਇਹਨਾਂ ਮਾਪਦੰਡਾਂ ਦੀ ਸੀਮਾ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਆਉਣਗੀਆਂ। ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਪੈਟਰੋਨੀ ਦੀ ਆਟੋਫਾਈਲ ਲਈ ਹਮਲਾਵਰਤਾ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਾਂ ਜੇਕਰ ਕੁਝ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆਵਾਂ ਆਉਂਦੀਆਂ ਹਨ।

ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਪੈਟਰੋਨੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਬਹੁਤ ਸਾਰੇ ਇਸ ਹੁਕਮ ਤੋਂ ਜਾਣੂ ਹਨ।

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

ਇਸ ਅਨੁਸਾਰ, ਇੱਕ ਆਟੋਫਾਈਲ ਸੀ. ਅਤੇ ਇਸ ਆਟੋਫਾਈਲ ਤੋਂ ਬਾਅਦ, ਸਾਡੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਗਾਇਬ ਹੋ ਗਈ. ਸਾਨੂੰ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਉਹ ਕਿਉਂ ਗਾਇਬ ਹੋ ਗਈ ਅਤੇ ਉਸਨੂੰ ਵਾਪਸ ਲਿਆਓ, ਉਸਨੂੰ ਬਹਾਲ ਕਰੋ। ਅਤੇ ਅਸੀਂ ਦੁਬਾਰਾ ਲੌਗਸ 'ਤੇ ਜਾਂਦੇ ਹਾਂ ਅਤੇ ਦੇਖਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ ਆਟੋ-ਫਾਈਲਓਵਰ ਕਿਉਂ ਸੀ।

ਇਸ ਕੇਸ ਵਿੱਚ, ਦੂਜੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਮਾਸਟਰ ਬਣ ਗਈ. ਇੱਥੇ ਸਭ ਠੀਕ ਹੈ।

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

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਾਡੇ ਕੋਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਨਹੀਂ ਹੈ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋ ਸਕਦੀ ਹੈ। ਇਸ ਅਨੁਸਾਰ, ਅਸੀਂ ਇੱਕ ਗਲਤੀ ਨਾਲ ਪੋਸਟਗ੍ਰੇਸ ਨੂੰ ਰੋਕਦੇ ਹਾਂ. ਅਤੇ ਇਸ ਲਈ ਇਹ ਕਲੱਸਟਰ ਵਿੱਚ ਨਹੀਂ ਹੈ.

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

ਮੈਂ ਟਾਈਮਸਟੈਂਪਾਂ ਦੀ ਤੁਲਨਾ ਕੀਤੀ ਜਦੋਂ ਇਹ ਘਟਨਾਵਾਂ ਵਾਪਰੀਆਂ। ਅਤੇ ਉੱਥੇ ਅੰਤਰ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ 150 ਮਿਲੀਸਕਿੰਟ ਹੈ, ਯਾਨੀ ਕਿ, 369 ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਪੂਰਾ ਕੀਤਾ ਗਿਆ ਚੈਕਪੁਆਇੰਟ, WAL ਹਿੱਸਿਆਂ ਦਾ ਨਾਮ ਬਦਲਿਆ ਗਿਆ ਸੀ। ਅਤੇ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ 517 ਵਿੱਚ, 150 ਮਿਲੀਸਕਿੰਟ ਦੇ ਬਾਅਦ, ਪੁਰਾਣੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ 'ਤੇ ਰੀਵਾਈਂਡ ਸ਼ੁਰੂ ਹੋਇਆ। ਭਾਵ, ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਸਾਡੇ ਲਈ 150 ਮਿਲੀਸਕਿੰਟ ਕਾਫ਼ੀ ਸਨ ਤਾਂ ਜੋ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਨੈਕਟ ਅਤੇ ਕਮਾਈ ਨਾ ਕਰ ਸਕੇ।

ਵਿਕਲਪ ਕੀ ਹਨ?

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

ਪਰ ਇੱਥੇ ਇੱਕ ਸਮੱਸਿਆ ਹੈ, ਕਿ ਜਦੋਂ ਮਾਸਟਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਿੱਚ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਲਾਟਾਂ ਨੂੰ ਮਿਟਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸਲਾਟਾਂ ਦੇ ਨਾਲ WAL ਖੰਡਾਂ ਨੂੰ ਵੀ ਮਿਟਾਉਂਦਾ ਹੈ। ਅਤੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ, ਅਸੀਂ wal_keep_segments ਪੈਰਾਮੀਟਰ ਨੂੰ ਵਧਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ। ਇਹ 8 ਭਾਗਾਂ ਲਈ ਡਿਫਾਲਟ ਹੈ। ਅਸੀਂ ਇਸਨੂੰ 1 ਤੱਕ ਵਧਾ ਦਿੱਤਾ ਅਤੇ ਦੇਖਿਆ ਕਿ ਸਾਡੇ ਕੋਲ ਕਿੰਨੀ ਖਾਲੀ ਥਾਂ ਹੈ। ਅਤੇ ਅਸੀਂ wal_keep_segments ਲਈ 000 ਗੀਗਾਬਾਈਟ ਦਾਨ ਕੀਤੇ ਹਨ। ਯਾਨੀ, ਸਵਿਚ ਕਰਨ ਵੇਲੇ, ਸਾਡੇ ਕੋਲ ਹਮੇਸ਼ਾ ਸਾਰੇ ਨੋਡਾਂ 'ਤੇ 16 ਗੀਗਾਬਾਈਟ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗਸ ਦਾ ਰਿਜ਼ਰਵ ਹੁੰਦਾ ਹੈ।

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

ਸਾਡੇ ਕੋਲ ਉਤਪਾਦਨ ਦਾ ਅਧਾਰ ਹੈ। ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਗਤੀ ਅਧੀਨ ਪ੍ਰੋਜੈਕਟ ਹਨ।

ਇੱਕ ਫਾਈਲਰ ਸੀ। ਅਸੀਂ ਅੰਦਰ ਗਏ ਅਤੇ ਦੇਖਿਆ - ਸਭ ਕੁਝ ਕ੍ਰਮਵਾਰ ਹੈ, ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਆਪਣੀ ਥਾਂ 'ਤੇ ਹਨ, ਕੋਈ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪਛੜ ਨਹੀਂ ਹੈ. ਲੌਗਸ ਵਿੱਚ ਕੋਈ ਗਲਤੀ ਨਹੀਂ ਹੈ, ਸਭ ਕੁਝ ਕ੍ਰਮ ਵਿੱਚ ਹੈ.

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

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

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

ਸਾਡੇ ਪੁਰਾਣੇ ਮਾਸਟਰ ਨੇ ਰੀਬੂਟ ਕੀਤਾ ਹੈ। ਅਤੇ ਪਟਰੋਨੀ ਆਟੋਰਨ ਵਿੱਚ ਦਰਜ ਕੀਤਾ ਗਿਆ ਸੀ। Patroni ਦੀ ਸ਼ੁਰੂਆਤ ਕੀਤੀ। ਫਿਰ ਉਸਨੇ ਪੋਸਟਗ੍ਰੇਸ ਸ਼ੁਰੂ ਕੀਤਾ। ਵਧੇਰੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਪੋਸਟਗ੍ਰੇਸ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਇਸ ਨੂੰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਪੈਟਰੋਨੀ ਨੇ pg_rewind ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕੀਤੀ। ਇਸ ਅਨੁਸਾਰ, ਉਸਨੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗਸ ਦਾ ਕੁਝ ਹਿੱਸਾ ਮਿਟਾ ਦਿੱਤਾ, ਨਵੇਂ ਡਾਊਨਲੋਡ ਕੀਤੇ ਅਤੇ ਕਨੈਕਟ ਕੀਤੇ। ਇੱਥੇ ਪਟਰੋਨੀ ਨੇ ਚੁਸਤੀ ਨਾਲ ਕੰਮ ਕੀਤਾ, ਯਾਨੀ ਉਮੀਦ ਅਨੁਸਾਰ. ਕਲੱਸਟਰ ਨੂੰ ਬਹਾਲ ਕੀਤਾ ਗਿਆ ਹੈ। ਸਾਡੇ ਕੋਲ 3 ਨੋਡ ਸਨ, ਫਾਈਲਰ 3 ਨੋਡਾਂ ਤੋਂ ਬਾਅਦ - ਸਭ ਕੁਝ ਠੰਡਾ ਹੈ.

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

ਸਾਨੂੰ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਵਿੱਚ ਉਹ ਸਥਿਤੀ ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ ਜਿੱਥੇ ਪੁਰਾਣੇ ਮਾਸਟਰ ਨੇ ਛੱਡ ਦਿੱਤਾ ਸੀ। ਇਸ ਕੇਸ ਵਿੱਚ, ਇਹ ਨਿਸ਼ਾਨ ਹੈ. ਅਤੇ ਸਾਨੂੰ ਇੱਕ ਦੂਜੇ ਨਿਸ਼ਾਨ ਦੀ ਲੋੜ ਹੈ, ਇਹ ਹੈ, ਉਹ ਦੂਰੀ ਜਿਸ ਦੁਆਰਾ ਪੁਰਾਣਾ ਮਾਸਟਰ ਨਵੇਂ ਤੋਂ ਵੱਖਰਾ ਹੈ.

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

ਪਰ ਅਸੀਂ ਆਪਣੇ ਲਈ ਕੀ ਪਾਇਆ ਹੈ?

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

ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਸਾਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਅਸੀਂ ਇਸ ਡੇਟਾ ਨੂੰ ਰੱਦ ਕਰ ਸਕਦੇ ਹਾਂ ਜਾਂ ਅਸੀਂ ਇਸਨੂੰ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹਾਂ, ਇਸ ਨੋਡ ਨੂੰ ਸਾਡੇ ਕਲੱਸਟਰ ਨਾਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਜੋਂ ਜੋੜ ਸਕਦੇ ਹਾਂ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, "ਅਧਿਕਤਮ_ਲੈਗ_ਆਨ_ਫੇਲਓਵਰ" ਪੈਰਾਮੀਟਰ ਹੈ। ਮੂਲ ਰੂਪ ਵਿੱਚ, ਜੇਕਰ ਮੇਰੀ ਮੈਮੋਰੀ ਮੇਰੀ ਸੇਵਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਇਸ ਪੈਰਾਮੀਟਰ ਦਾ ਮੁੱਲ 1 ਮੈਗਾਬਾਈਟ ਹੈ।

ਉਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ? ਜੇਕਰ ਰਿਪਲੀਕੇਸ਼ਨ ਲੈਗ ਵਿੱਚ ਸਾਡੀ ਰੀਪਲੀਕਾ 1 ਮੈਗਾਬਾਈਟ ਡੇਟਾ ਪਿੱਛੇ ਹੈ, ਤਾਂ ਇਹ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਚੋਣਾਂ ਵਿੱਚ ਹਿੱਸਾ ਨਹੀਂ ਲੈਂਦੀ। ਅਤੇ ਜੇ ਅਚਾਨਕ ਕੋਈ ਫਾਈਲਓਵਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਪੈਟਰੋਨੀ ਦੇਖਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਪਿੱਛੇ ਰਹਿ ਗਈਆਂ ਹਨ. ਜੇਕਰ ਉਹ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਦੁਆਰਾ ਪਿੱਛੇ ਹਨ, ਤਾਂ ਉਹ ਇੱਕ ਮਾਸਟਰ ਨਹੀਂ ਬਣ ਸਕਦੇ। ਇਹ ਇੱਕ ਬਹੁਤ ਵਧੀਆ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰਾ ਡਾਟਾ ਗੁਆਉਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।

ਪਰ ਇਸ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਹੈ ਕਿ ਪੈਟਰੋਨੀ ਕਲੱਸਟਰ ਅਤੇ ਡੀਸੀਐਸ ਵਿੱਚ ਰੀਪਲੀਕੇਸ਼ਨ ਲੈਗ ਨੂੰ ਇੱਕ ਨਿਸ਼ਚਿਤ ਅੰਤਰਾਲ 'ਤੇ ਅਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ 30 ਸਕਿੰਟ ਡਿਫੌਲਟ ttl ਮੁੱਲ ਹੈ।

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

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

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

ਅਤੇ ਲੌਗ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ ਜੇਕਰ ਅਧਿਕਤਮ_ਲੈਗ_ਆਨ_ਫੇਲਓਵਰ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇੱਕ ਫਾਈਲਰ ਆਇਆ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਨਵਾਂ ਮਾਸਟਰ ਚੁਣਨ ਦੀ ਲੋੜ ਹੈ। ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਆਪਣੇ ਆਪ ਨੂੰ ਚੋਣਾਂ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਦੇ ਅਯੋਗ ਮੰਨਦੀ ਹੈ। ਅਤੇ ਉਸਨੇ ਨੇਤਾ ਦੀ ਦੌੜ ਵਿੱਚ ਹਿੱਸਾ ਲੈਣ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੱਤਾ। ਅਤੇ ਉਹ ਇੱਕ ਨਵੇਂ ਮਾਸਟਰ ਦੇ ਚੁਣੇ ਜਾਣ ਦੀ ਉਡੀਕ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਉਹ ਫਿਰ ਇਸ ਨਾਲ ਜੁੜ ਸਕੇ। ਇਹ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਦੇ ਵਿਰੁੱਧ ਇੱਕ ਵਾਧੂ ਉਪਾਅ ਹੈ।

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

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

ਇਸ ਦੇ ਨਾਲ ਹੀ, ਸਾਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪਤਾ ਸੀ ਕਿ ਸਾਨੂੰ ਡਿਸਕਾਂ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਸਨ, ਯਾਨੀ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਨਿਗਰਾਨੀ ਤੋਂ ਜਾਣਦੇ ਸੀ ਕਿ ਕਿੱਥੇ ਖੋਦਣਾ ਹੈ ਅਤੇ ਕੀ ਲੱਭਣਾ ਹੈ.

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

ਅਸੀਂ ਸਿਸਟਮ dmesg (ਕਰਨਲ ਲੌਗ) ਵਿੱਚ ਦੇਖਿਆ. ਅਤੇ ਅਸੀਂ ਦੇਖਿਆ ਕਿ ਸਾਨੂੰ ਇੱਕ ਡਿਸਕ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਹਨ. ਡਿਸਕ ਸਬ-ਸਿਸਟਮ ਸਾਫਟਵੇਅਰ ਰੇਡ ਸੀ। ਅਸੀਂ /proc/mdstat ਨੂੰ ਦੇਖਿਆ ਅਤੇ ਦੇਖਿਆ ਕਿ ਅਸੀਂ ਇੱਕ ਡਰਾਈਵ ਗੁਆ ਰਹੇ ਸੀ। ਭਾਵ, 8 ਡਿਸਕਾਂ ਦਾ ਇੱਕ ਰੇਡ ਹੈ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਗੁੰਮ ਹੈ. ਜੇਕਰ ਤੁਸੀਂ ਸਲਾਈਡ ਨੂੰ ਧਿਆਨ ਨਾਲ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਆਉਟਪੁੱਟ ਵਿੱਚ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਸਾਡੇ ਕੋਲ ਉੱਥੇ sde ਨਹੀਂ ਹੈ। ਸਾਡੇ 'ਤੇ, ਸ਼ਰਤ ਅਨੁਸਾਰ, ਡਿਸਕ ਬਾਹਰ ਆ ਗਈ ਹੈ. ਇਸ ਨਾਲ ਡਿਸਕ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋਈਆਂ, ਅਤੇ ਪੋਸਟਗ੍ਰੇਸ ਕਲੱਸਟਰ ਨਾਲ ਕੰਮ ਕਰਨ ਵੇਲੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਵੀ ਸਮੱਸਿਆਵਾਂ ਆਈਆਂ।

ਅਤੇ ਇਸ ਸਥਿਤੀ ਵਿੱਚ, Patroni ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਸਾਡੀ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ, ਕਿਉਂਕਿ Patroni ਕੋਲ ਸਰਵਰ ਦੀ ਸਥਿਤੀ, ਡਿਸਕ ਦੀ ਸਥਿਤੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦਾ ਕੰਮ ਨਹੀਂ ਹੈ। ਅਤੇ ਸਾਨੂੰ ਬਾਹਰੀ ਨਿਗਰਾਨੀ ਦੁਆਰਾ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ. ਅਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਡਿਸਕ ਨਿਗਰਾਨੀ ਨੂੰ ਬਾਹਰੀ ਨਿਗਰਾਨੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ।

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

ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਇਹ ਸਭ ਤੋਂ ਅਜੀਬ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜਿਸਦੀ ਮੈਂ ਬਹੁਤ ਲੰਬੇ ਸਮੇਂ ਲਈ ਖੋਜ ਕੀਤੀ ਹੈ, ਮੈਂ ਬਹੁਤ ਸਾਰੇ ਲੌਗ ਪੜ੍ਹੇ ਹਨ, ਦੁਬਾਰਾ ਚੁਣੇ ਹਨ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਕਲੱਸਟਰ ਸਿਮੂਲੇਟਰ ਕਿਹਾ ਹੈ.

ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ ਪੁਰਾਣਾ ਮਾਸਟਰ ਇੱਕ ਆਮ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨਹੀਂ ਬਣ ਸਕਦਾ ਸੀ, ਯਾਨੀ ਕਿ ਪੈਟਰੋਨੀ ਨੇ ਇਸਨੂੰ ਸ਼ੁਰੂ ਕੀਤਾ, ਪੈਟਰੋਨੀ ਨੇ ਦਿਖਾਇਆ ਕਿ ਇਹ ਨੋਡ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਰੂਪ ਵਿੱਚ ਮੌਜੂਦ ਸੀ, ਪਰ ਉਸੇ ਸਮੇਂ ਇਹ ਇੱਕ ਆਮ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨਹੀਂ ਸੀ. ਹੁਣ ਤੁਸੀਂ ਦੇਖੋਗੇ ਕਿ ਕਿਉਂ. ਇਹ ਉਹ ਹੈ ਜੋ ਮੈਂ ਉਸ ਸਮੱਸਿਆ ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਤੋਂ ਰੱਖਿਆ ਹੈ.

ਅਤੇ ਇਹ ਸਭ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੋਇਆ? ਇਹ ਪਿਛਲੀ ਸਮੱਸਿਆ ਵਾਂਗ, ਡਿਸਕ ਬ੍ਰੇਕਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ। ਸਾਡੇ ਕੋਲ ਇੱਕ ਸਕਿੰਟ, ਦੋ ਲਈ ਵਚਨਬੱਧ ਸਨ।

ਕੁਨੈਕਸ਼ਨ ਟੁੱਟ ਗਏ ਸਨ, ਯਾਨੀ ਕਿ ਗਾਹਕਾਂ ਨੂੰ ਤੋੜ ਦਿੱਤਾ ਗਿਆ ਸੀ।

ਵੱਖ-ਵੱਖ ਤੀਬਰਤਾ ਦੀਆਂ ਰੁਕਾਵਟਾਂ ਸਨ.

ਅਤੇ, ਇਸ ਅਨੁਸਾਰ, ਡਿਸਕ ਸਬ-ਸਿਸਟਮ ਬਹੁਤ ਜਵਾਬਦੇਹ ਨਹੀਂ ਹੈ.

ਅਤੇ ਮੇਰੇ ਲਈ ਸਭ ਤੋਂ ਰਹੱਸਮਈ ਚੀਜ਼ ਤੁਰੰਤ ਬੰਦ ਕਰਨ ਦੀ ਬੇਨਤੀ ਹੈ ਜੋ ਆਈ. ਪੋਸਟਗ੍ਰੇਸ ਦੇ ਤਿੰਨ ਬੰਦ ਮੋਡ ਹਨ:

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

ਇਹ ਸੰਕੇਤ ਕਿਸਨੇ ਭੇਜਿਆ? ਪੋਸਟਗ੍ਰੇਸ ਬੈਕਗਰਾਊਂਡ ਪ੍ਰਕਿਰਿਆਵਾਂ ਇੱਕ ਦੂਜੇ ਨੂੰ ਅਜਿਹੇ ਸਿਗਨਲ ਨਹੀਂ ਭੇਜਦੀਆਂ ਹਨ, ਯਾਨੀ ਕਿ ਇਹ ਕਿਲ-9 ਹੈ। ਉਹ ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਨੂੰ ਨਹੀਂ ਭੇਜਦੇ, ਉਹ ਸਿਰਫ ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦੇ ਹਨ, ਯਾਨੀ ਇਹ ਪੋਸਟਗ੍ਰੇਸ ਦੀ ਇੱਕ ਐਮਰਜੈਂਸੀ ਰੀਸਟਾਰਟ ਹੈ। ਕਿਸਨੇ ਭੇਜਿਆ, ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ।

ਮੈਂ "ਆਖਰੀ" ਕਮਾਂਡ ਨੂੰ ਦੇਖਿਆ ਅਤੇ ਮੈਂ ਇੱਕ ਵਿਅਕਤੀ ਨੂੰ ਦੇਖਿਆ ਜਿਸ ਨੇ ਸਾਡੇ ਨਾਲ ਇਸ ਸਰਵਰ ਵਿੱਚ ਵੀ ਲੌਗਇਨ ਕੀਤਾ ਸੀ, ਪਰ ਮੈਂ ਇੱਕ ਸਵਾਲ ਪੁੱਛਣ ਲਈ ਬਹੁਤ ਸ਼ਰਮਿੰਦਾ ਸੀ। ਸ਼ਾਇਦ ਇਹ ਕਤਲ-9 ਸੀ। ਮੈਂ ਲੌਗਸ ਵਿੱਚ kill -9 ਦੇਖਾਂਗਾ, ਕਿਉਂਕਿ ਪੋਸਟਗ੍ਰੇਸ ਕਹਿੰਦਾ ਹੈ ਕਿ ਇਸਨੇ ਕਿਲ -9 ਲਿਆ, ਪਰ ਮੈਂ ਇਸਨੂੰ ਲੌਗਸ ਵਿੱਚ ਨਹੀਂ ਦੇਖਿਆ।

ਅੱਗੇ ਦੇਖ ਕੇ, ਮੈਂ ਦੇਖਿਆ ਕਿ ਪੈਟਰੋਨੀ ਨੇ ਬਹੁਤ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਲੌਗ ਨੂੰ ਨਹੀਂ ਲਿਖਿਆ - 54 ਸਕਿੰਟ. ਅਤੇ ਜੇ ਅਸੀਂ ਦੋ ਟਾਈਮਸਟੈਂਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰੀਏ, ਤਾਂ ਲਗਭਗ 54 ਸਕਿੰਟਾਂ ਲਈ ਕੋਈ ਸੰਦੇਸ਼ ਨਹੀਂ ਸਨ.

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

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

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

ਕਿਸੇ ਸਮੇਂ, ਇਸ ਨੇ ਕੰਮ ਕੀਤਾ, ਪਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਈ.

ਮੇਰਾ ਸਿਰਫ ਅੰਦਾਜ਼ਾ ਹੈ ਕਿ recovery.conf ਵਿੱਚ ਇੱਕ ਪੁਰਾਣਾ ਮਾਸਟਰ ਐਡਰੈੱਸ ਸੀ। ਅਤੇ ਜਦੋਂ ਇੱਕ ਨਵਾਂ ਮਾਸਟਰ ਪ੍ਰਗਟ ਹੋਇਆ, ਦੂਜੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੇ ਅਜੇ ਵੀ ਪੁਰਾਣੇ ਮਾਸਟਰ ਨਾਲ ਜੁੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ.

ਜਦੋਂ ਪੈਟਰੋਨੀ ਨੇ ਦੂਜੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ 'ਤੇ ਸ਼ੁਰੂਆਤ ਕੀਤੀ, ਤਾਂ ਨੋਡ ਸ਼ੁਰੂ ਹੋਇਆ ਪਰ ਨਕਲ ਨਹੀਂ ਕਰ ਸਕਿਆ। ਅਤੇ ਇੱਕ ਰੀਪਲੀਕੇਸ਼ਨ ਲੈਗ ਬਣਾਈ ਗਈ ਸੀ, ਜੋ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਸੀ। ਯਾਨੀ ਕਿ ਤਿੰਨੋਂ ਨੋਡ ਆਪਣੀ ਥਾਂ 'ਤੇ ਸਨ, ਪਰ ਦੂਜਾ ਨੋਡ ਪਿੱਛੇ ਰਹਿ ਗਿਆ।

ਉਸੇ ਸਮੇਂ, ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਲੌਗਸ ਨੂੰ ਦੇਖਦੇ ਹੋ ਜੋ ਲਿਖੇ ਗਏ ਸਨ, ਤਾਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋ ਸਕਦੀ ਕਿਉਂਕਿ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਵੱਖਰੇ ਸਨ। ਅਤੇ ਉਹ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਜੋ ਮਾਸਟਰ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ recovery.conf ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਹਨ, ਸਾਡੇ ਮੌਜੂਦਾ ਨੋਡ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ ਹਨ।

ਅਤੇ ਇੱਥੇ ਮੈਂ ਇੱਕ ਗਲਤੀ ਕੀਤੀ. ਮੈਨੂੰ ਮੇਰੀ ਪਰਿਕਲਪਨਾ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਕਿ ਅਸੀਂ ਗਲਤ ਮਾਸਟਰ ਨਾਲ ਕਨੈਕਟ ਕਰ ਰਹੇ ਸੀ, ਮੈਨੂੰ ਆ ਕੇ ਦੇਖਣਾ ਪਿਆ ਕਿ recovery.conf ਵਿੱਚ ਕੀ ਸੀ। ਪਰ ਉਦੋਂ ਮੈਂ ਸਿਰਫ ਇਸ ਨਾਲ ਨਜਿੱਠ ਰਿਹਾ ਸੀ ਅਤੇ ਇਹ ਮੇਰੇ ਨਾਲ ਨਹੀਂ ਹੋਇਆ, ਜਾਂ ਮੈਂ ਦੇਖਿਆ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪਿੱਛੇ ਰਹਿ ਗਈ ਸੀ ਅਤੇ ਇਸਨੂੰ ਦੁਬਾਰਾ ਭਰਨਾ ਪਏਗਾ, ਭਾਵ, ਮੈਂ ਕਿਸੇ ਤਰ੍ਹਾਂ ਲਾਪਰਵਾਹੀ ਨਾਲ ਕੰਮ ਕੀਤਾ. ਇਹ ਮੇਰਾ ਸਾਂਝਾ ਸੀ।

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

ਨਕਲ ਸ਼ੁਰੂ ਹੋ ਗਈ ਹੈ। ਪਰ ਇੱਕ ਮਿੰਟ ਬਾਅਦ ਉਹ ਇੱਕ ਗਲਤੀ ਨਾਲ ਡਿੱਗ ਗਈ ਕਿ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਉਸਦੇ ਲਈ ਢੁਕਵੇਂ ਨਹੀਂ ਹਨ।

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

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

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

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

ਮੇਰੇ ਲਈ ਅਜਿਹੀ ਸਮੱਸਿਆ ਇਕ ਹੋਰ ਰਹੱਸਮਈ ਹੈ, ਜਿਸ ਬਾਰੇ ਮੈਂ ਅਜੇ ਵੀ ਇਸ ਗੱਲ 'ਤੇ ਬੁਝਾਰਤ ਰੱਖਦਾ ਹਾਂ ਕਿ ਅਸਲ ਵਿਚ ਉਥੇ ਕੀ ਹੋਇਆ ਸੀ.

ਇੱਥੇ ਕੀ ਪ੍ਰਭਾਵ ਹਨ? Patroni ਇਰਾਦੇ ਅਨੁਸਾਰ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਤਰੁੱਟੀ ਦੇ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। ਪਰ ਉਸੇ ਸਮੇਂ, ਇਹ 100% ਗਾਰੰਟੀ ਨਹੀਂ ਹੈ ਕਿ ਸਾਡੇ ਨਾਲ ਸਭ ਕੁਝ ਠੀਕ ਹੈ. ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸ਼ੁਰੂ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਅਰਧ-ਕਾਰਜ ਅਵਸਥਾ ਵਿੱਚ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਅਜਿਹੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਕਿਉਂਕਿ ਪੁਰਾਣਾ ਡੇਟਾ ਹੋਵੇਗਾ।

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

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

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

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

ਆਟੋਮੇਸ਼ਨ ਸਫਲਤਾਪੂਰਵਕ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ, ਪੈਟਰੋਨੀ ਇੱਕ ਬਹੁਤ ਵਧੀਆ ਸਾਧਨ ਹੈ. ਇਹ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਕਲੱਸਟਰ ਨੂੰ ਲੋੜੀਂਦੀ ਸਥਿਤੀ ਵਿੱਚ ਨਹੀਂ ਲਿਆਏਗਾ। ਅਤੇ ਜੇਕਰ ਸਾਨੂੰ ਇਸ ਬਾਰੇ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ, ਤਾਂ ਅਸੀਂ ਮੁਸੀਬਤ ਵਿੱਚ ਹੋਵਾਂਗੇ।

ਅਤੇ Patroni ਇੱਕ ਚਾਂਦੀ ਦੀ ਗੋਲੀ ਨਹੀਂ ਹੈ. ਸਾਨੂੰ ਅਜੇ ਵੀ ਇਹ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਪੋਸਟਗ੍ਰੇਸ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ ਪੈਟਰੋਨੀ ਪੋਸਟਗ੍ਰੇਸ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਅਤੇ ਨੋਡਾਂ ਵਿਚਕਾਰ ਸੰਚਾਰ ਕਿਵੇਂ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਆਪਣੇ ਹੱਥਾਂ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਲਈ ਇਹ ਜ਼ਰੂਰੀ ਹੈ.

ਮੈਂ ਨਿਦਾਨ ਦੇ ਮੁੱਦੇ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚ ਸਕਦਾ ਹਾਂ? ਅਜਿਹਾ ਹੋਇਆ ਕਿ ਅਸੀਂ ਵੱਖ-ਵੱਖ ਗਾਹਕਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਾਂ ਅਤੇ ਕਿਸੇ ਕੋਲ ELK ਸਟੈਕ ਨਹੀਂ ਹੈ, ਅਤੇ ਸਾਨੂੰ 6 ਕੰਸੋਲ ਅਤੇ 2 ਟੈਬਾਂ ਖੋਲ੍ਹ ਕੇ ਲੌਗਸ ਨੂੰ ਛਾਂਟਣਾ ਪੈਂਦਾ ਹੈ। ਇੱਕ ਟੈਬ ਵਿੱਚ, ਇਹ ਹਰੇਕ ਨੋਡ ਲਈ ਪੈਟਰੋਨੀ ਲੌਗ ਹਨ, ਦੂਜੀ ਟੈਬ ਵਿੱਚ, ਇਹ ਕੌਂਸਲ ਲੌਗ ਹਨ, ਜਾਂ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਪੋਸਟਗ੍ਰੇਸ। ਇਸ ਦਾ ਨਿਦਾਨ ਕਰਨਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ।

ਮੈਂ ਕਿਹੜੇ ਤਰੀਕੇ ਵਿਕਸਿਤ ਕੀਤੇ ਹਨ? ਪਹਿਲਾਂ, ਮੈਂ ਹਮੇਸ਼ਾ ਦੇਖਦਾ ਹਾਂ ਕਿ ਫਾਈਲਰ ਕਦੋਂ ਆਇਆ ਹੈ। ਅਤੇ ਮੇਰੇ ਲਈ ਇਹ ਇੱਕ ਵਾਟਰਸ਼ੈੱਡ ਹੈ. ਮੈਂ ਦੇਖਦਾ ਹਾਂ ਕਿ ਫਾਈਲਰ ਤੋਂ ਪਹਿਲਾਂ, ਫਾਈਲਰ ਦੌਰਾਨ ਅਤੇ ਫਾਈਲਰ ਤੋਂ ਬਾਅਦ ਕੀ ਹੋਇਆ ਸੀ. ਫਾਈਲਓਵਰ ਦੇ ਦੋ ਨਿਸ਼ਾਨ ਹਨ: ਇਹ ਸ਼ੁਰੂਆਤੀ ਅਤੇ ਸਮਾਪਤੀ ਸਮਾਂ ਹੈ।

ਅੱਗੇ, ਮੈਂ ਫਾਈਲਰ ਤੋਂ ਪਹਿਲਾਂ ਦੀਆਂ ਘਟਨਾਵਾਂ ਲਈ ਲੌਗਸ ਵਿੱਚ ਦੇਖਦਾ ਹਾਂ, ਜੋ ਕਿ ਫਾਈਲਰ ਤੋਂ ਪਹਿਲਾਂ ਸੀ, ਭਾਵ ਮੈਂ ਉਹਨਾਂ ਕਾਰਨਾਂ ਦੀ ਖੋਜ ਕਰਦਾ ਹਾਂ ਕਿ ਫਾਈਲਰ ਕਿਉਂ ਹੋਇਆ।

ਅਤੇ ਇਹ ਇਹ ਸਮਝਣ ਦੀ ਇੱਕ ਤਸਵੀਰ ਦਿੰਦਾ ਹੈ ਕਿ ਕੀ ਹੋਇਆ ਹੈ ਅਤੇ ਭਵਿੱਖ ਵਿੱਚ ਕੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ ਅਜਿਹੇ ਹਾਲਾਤ ਨਾ ਹੋਣ (ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ, ਕੋਈ ਫਾਈਲਰ ਨਹੀਂ ਹੈ).

ਅਤੇ ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਕਿੱਥੇ ਦੇਖਦੇ ਹਾਂ? ਮੈਂ ਦੇਖਦਾ ਹਾਂ:

• ਪਹਿਲਾਂ, ਪੈਟਰੋਨੀ ਲੌਗਸ ਨੂੰ.
• ਅੱਗੇ, ਮੈਂ ਪੋਸਟਗ੍ਰੇਸ ਲੌਗਸ, ਜਾਂ ਡੀਸੀਐਸ ਲੌਗਸ ਨੂੰ ਦੇਖਦਾ ਹਾਂ, ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਪੈਟਰੋਨੀ ਲੌਗਸ ਵਿੱਚ ਕੀ ਪਾਇਆ ਗਿਆ ਸੀ।
• ਅਤੇ ਸਿਸਟਮ ਲੌਗ ਵੀ ਕਈ ਵਾਰ ਇਹ ਸਮਝ ਦਿੰਦੇ ਹਨ ਕਿ ਫਾਈਲਰ ਦਾ ਕਾਰਨ ਕੀ ਹੈ।

ਮੈਂ ਪੈਟਰੋਨੀ ਬਾਰੇ ਕਿਵੇਂ ਮਹਿਸੂਸ ਕਰਦਾ ਹਾਂ? ਪਟਰੋਨੀ ਨਾਲ ਮੇਰੇ ਬਹੁਤ ਚੰਗੇ ਸਬੰਧ ਹਨ। ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਇਹ ਅੱਜ ਸਭ ਤੋਂ ਉੱਤਮ ਹੈ। ਮੈਂ ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਉਤਪਾਦਾਂ ਨੂੰ ਜਾਣਦਾ ਹਾਂ. ਇਹ Stolon, Repmgr, Pg_auto_failover, PAF ਹਨ। 4 ਔਜ਼ਾਰ। ਮੈਂ ਉਨ੍ਹਾਂ ਸਾਰਿਆਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ. Patroni ਮੇਰੇ ਪਸੰਦੀਦਾ ਹੈ.

ਜੇ ਉਹ ਮੈਨੂੰ ਪੁੱਛਦੇ ਹਨ: "ਕੀ ਮੈਂ ਪੈਟਰੋਨੀ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ?". ਮੈਂ ਹਾਂ ਕਹਾਂਗਾ, ਕਿਉਂਕਿ ਮੈਨੂੰ ਪਟਰੋਨੀ ਪਸੰਦ ਹੈ। ਅਤੇ ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਮੈਂ ਇਸਨੂੰ ਪਕਾਉਣਾ ਸਿੱਖ ਲਿਆ ਹੈ.

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

ਲੋਕਾਂ ਦੇ ਪੈਰਾਂ ਵਿੱਚ ਗੋਲੀ ਮਾਰਨ ਦੀਆਂ ਕੁਝ ਦਿਲਚਸਪ ਕਹਾਣੀਆਂ ਹਨ। ਬਹੁਤ ਜਾਣਕਾਰੀ ਭਰਪੂਰ। ਤੁਸੀਂ ਪੜ੍ਹ ਕੇ ਸਮਝਦੇ ਹੋ ਕਿ ਅਜਿਹਾ ਕਰਨਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ। ਮੈਂ ਆਪਣੇ ਆਪ ਨੂੰ ਟਿੱਕ ਕੀਤਾ।

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

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

ਇਹ ਸਭ ਹੈ. ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਈ ਸਵਾਲ ਹਨ, ਤਾਂ ਪੁੱਛੋ।

ਤੁਹਾਡੇ ਸਵਾਲ

ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਜੇਕਰ ਇੱਕ ਫਾਈਲਰ ਤੋਂ ਬਾਅਦ ਵੀ ਤੁਹਾਨੂੰ ਉੱਥੇ ਬਹੁਤ ਧਿਆਨ ਨਾਲ ਦੇਖਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਇੱਕ ਆਟੋਮੈਟਿਕ ਫਾਈਲਰ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

ਕਿਉਂਕਿ ਇਹ ਨਵੀਂ ਚੀਜ਼ ਹੈ। ਅਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਸਾਲ ਲਈ ਉਸਦੇ ਨਾਲ ਰਹੇ ਹਾਂ। ਸੁਰੱਖਿਅਤ ਹੋਣਾ ਬਿਹਤਰ ਹੈ। ਅਸੀਂ ਅੰਦਰ ਆਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਅਤੇ ਇਹ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਹਰ ਚੀਜ਼ ਅਸਲ ਵਿੱਚ ਉਸ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ ਜਿਸ ਤਰ੍ਹਾਂ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਬਾਲਗ ਅਵਿਸ਼ਵਾਸ ਦਾ ਪੱਧਰ ਹੈ - ਦੋ ਵਾਰ ਜਾਂਚ ਕਰਨਾ ਅਤੇ ਦੇਖਣਾ ਬਿਹਤਰ ਹੈ.

ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਸਵੇਰੇ ਗਏ ਅਤੇ ਦੇਖਿਆ, ਠੀਕ ਹੈ?

ਸਵੇਰ ਨੂੰ ਨਹੀਂ, ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਆਟੋਫਾਈਲ ਬਾਰੇ ਲਗਭਗ ਤੁਰੰਤ ਸਿੱਖਦੇ ਹਾਂ। ਸਾਨੂੰ ਸੂਚਨਾਵਾਂ ਮਿਲਦੀਆਂ ਹਨ, ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਇੱਕ ਆਟੋਫਾਈਲ ਆਈ ਹੈ। ਅਸੀਂ ਲਗਭਗ ਤੁਰੰਤ ਜਾਂਦੇ ਹਾਂ ਅਤੇ ਦੇਖਦੇ ਹਾਂ. ਪਰ ਇਨ੍ਹਾਂ ਸਾਰੀਆਂ ਜਾਂਚਾਂ ਨੂੰ ਨਿਗਰਾਨੀ ਪੱਧਰ 'ਤੇ ਲਿਆਂਦਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ REST API ਰਾਹੀਂ Patroni ਤੱਕ ਪਹੁੰਚ ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਇਤਿਹਾਸ ਹੈ। ਇਤਿਹਾਸ ਦੁਆਰਾ ਤੁਸੀਂ ਟਾਈਮਸਟੈਂਪ ਦੇਖ ਸਕਦੇ ਹੋ ਜਦੋਂ ਫਾਈਲਰ ਹੋਇਆ ਸੀ। ਇਸ ਦੇ ਆਧਾਰ 'ਤੇ ਨਿਗਰਾਨੀ ਰੱਖੀ ਜਾ ਸਕਦੀ ਹੈ। ਤੁਸੀਂ ਇਤਿਹਾਸ ਦੇਖ ਸਕਦੇ ਹੋ, ਕਿੰਨੀਆਂ ਘਟਨਾਵਾਂ ਸਨ। ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਹੋਰ ਇਵੈਂਟ ਹਨ, ਤਾਂ ਇੱਕ ਆਟੋਫਾਈਲ ਆਈ ਹੈ। ਤੁਸੀਂ ਜਾ ਕੇ ਦੇਖ ਸਕਦੇ ਹੋ। ਜਾਂ ਸਾਡੀ ਨਿਗਰਾਨੀ ਆਟੋਮੇਸ਼ਨ ਨੇ ਜਾਂਚ ਕੀਤੀ ਕਿ ਸਾਡੇ ਕੋਲ ਸਾਰੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਹਨ, ਕੋਈ ਪਛੜ ਨਹੀਂ ਹੈ ਅਤੇ ਸਭ ਕੁਝ ਠੀਕ ਹੈ।

ਤੁਹਾਡਾ ਧੰਨਵਾਦ!

ਮਹਾਨ ਕਹਾਣੀ ਲਈ ਬਹੁਤ ਧੰਨਵਾਦ! ਜੇਕਰ ਅਸੀਂ DCS ਕਲੱਸਟਰ ਨੂੰ ਪੋਸਟਗ੍ਰੇਸ ਕਲੱਸਟਰ ਤੋਂ ਕਿਤੇ ਦੂਰ ਲੈ ਗਏ ਹਾਂ, ਤਾਂ ਇਸ ਕਲੱਸਟਰ ਨੂੰ ਵੀ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਸਰਵਿਸ ਕਰਨ ਦੀ ਲੋੜ ਹੈ? DCS ਕਲੱਸਟਰ ਦੇ ਕੁਝ ਟੁਕੜਿਆਂ ਨੂੰ ਬੰਦ ਕਰਨ, ਉਹਨਾਂ ਨਾਲ ਕੁਝ ਕਰਨ ਦੀ ਲੋੜ ਆਦਿ ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸ ਕੀ ਹਨ? ਇਹ ਸਾਰਾ ਢਾਂਚਾ ਕਿਵੇਂ ਬਚਦਾ ਹੈ? ਅਤੇ ਤੁਸੀਂ ਇਹ ਚੀਜ਼ਾਂ ਕਿਵੇਂ ਕਰਦੇ ਹੋ?

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

ਭਾਵ, ਕੀ ਮੈਂ ਸਹੀ ਢੰਗ ਨਾਲ ਸਮਝਿਆ ਹੈ ਕਿ ਮੇਜ਼ਬਾਨਾਂ ਨਾਲ ਕੁਝ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੈਨੂੰ ਪੈਟਰੋਨੀ ਨੂੰ ਅਯੋਗ ਕਰਨ, ਫਾਈਲਰ ਨੂੰ ਅਯੋਗ ਕਰਨ, ਹਰ ਚੀਜ਼ ਨੂੰ ਅਯੋਗ ਕਰਨ ਦੀ ਲੋੜ ਹੈ?

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

ਤੁਹਾਡਾ ਬਹੁਤ ਧੰਨਵਾਦ!

ਤੁਹਾਡੀ ਰਿਪੋਰਟ ਲਈ ਤੁਹਾਡਾ ਬਹੁਤ ਧੰਨਵਾਦ! ਉਤਪਾਦ ਟੀਮ ਡੇਟਾ ਦੇ ਗੁੰਮ ਹੋਣ ਬਾਰੇ ਕਿਵੇਂ ਮਹਿਸੂਸ ਕਰਦੀ ਹੈ?

ਉਤਪਾਦ ਟੀਮਾਂ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦੀਆਂ, ਅਤੇ ਟੀਮ ਲੀਡ ਚਿੰਤਤ ਹਨ।

ਕੀ ਗਾਰੰਟੀ ਹਨ?

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

ਅਲੈਕਸੀ, ਮਹਾਨ ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਜ਼ੀਰੋ ਪੱਧਰ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਪੈਟਰੋਨੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਕੋਈ ਅਨੁਭਵ? ਇਹ ਹੈ, ਸਮਕਾਲੀ ਸਟੈਂਡਬਾਏ ਦੇ ਨਾਲ ਜੋੜ ਕੇ? ਇਹ ਪਹਿਲਾ ਸਵਾਲ ਹੈ। ਅਤੇ ਦੂਜਾ ਸਵਾਲ. ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ। ਅਸੀਂ Repmgr ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਪਰ ਆਟੋਫਾਈਲਰ ਤੋਂ ਬਿਨਾਂ, ਅਤੇ ਹੁਣ ਅਸੀਂ ਆਟੋਫਾਈਲਰ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ। ਅਤੇ ਅਸੀਂ ਪੈਟਰੋਨੀ ਨੂੰ ਇੱਕ ਵਿਕਲਪਿਕ ਹੱਲ ਮੰਨਦੇ ਹਾਂ। ਤੁਸੀਂ Repmgr ਦੇ ਮੁਕਾਬਲੇ ਫਾਇਦਿਆਂ ਵਜੋਂ ਕੀ ਕਹਿ ਸਕਦੇ ਹੋ?

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

ਦੂਜੇ ਸਵਾਲ ਦੇ ਸੰਬੰਧ ਵਿੱਚ, ਅਸੀਂ Repmgr ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ ਅਤੇ ਅਜੇ ਵੀ ਇਤਿਹਾਸਕ ਕਾਰਨਾਂ ਕਰਕੇ ਕੁਝ ਗਾਹਕਾਂ ਨਾਲ ਕਰਦੇ ਹਾਂ। ਕੀ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ? Patroni ਬਾਕਸ ਦੇ ਬਾਹਰ ਇੱਕ ਆਟੋਫਾਈਲਰ ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ, Repmgr ਇੱਕ ਵਾਧੂ ਵਿਸ਼ੇਸ਼ਤਾ ਦੇ ਰੂਪ ਵਿੱਚ ਆਟੋਫਾਈਲਰ ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ ਜਿਸਨੂੰ ਸਮਰੱਥ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸਾਨੂੰ ਹਰੇਕ ਨੋਡ 'ਤੇ Repmgr ਡੈਮਨ ਨੂੰ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਫਿਰ ਅਸੀਂ ਆਟੋਫਾਈਲਰ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰ ਸਕਦੇ ਹਾਂ।

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

ਅਲੈਕਸੀ, ਮੇਰੇ ਕੋਲ ਇੱਕ ਸਵਾਲ ਹੈ, ਸ਼ਾਇਦ ਇੱਕ ਲੇਮਰ. ਪਹਿਲੀ ਉਦਾਹਰਣਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ, ਤੁਸੀਂ DCS ਨੂੰ ਸਥਾਨਕ ਮਸ਼ੀਨ ਤੋਂ ਇੱਕ ਰਿਮੋਟ ਹੋਸਟ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ ਹੈ। ਅਸੀਂ ਸਮਝਦੇ ਹਾਂ ਕਿ ਨੈੱਟਵਰਕ ਇੱਕ ਅਜਿਹੀ ਚੀਜ਼ ਹੈ ਜਿਸ ਦੀਆਂ ਆਪਣੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ, ਇਹ ਆਪਣੇ ਆਪ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। ਅਤੇ ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ DCS ਕਲੱਸਟਰ ਅਣਉਪਲਬਧ ਹੋ ਜਾਂਦਾ ਹੈ? ਮੈਂ ਕਾਰਨ ਨਹੀਂ ਕਹਾਂਗਾ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਹੋ ਸਕਦੇ ਹਨ: ਨੈਟਵਰਕਰਾਂ ਦੇ ਟੇਢੇ ਹੱਥਾਂ ਤੋਂ ਅਸਲ ਸਮੱਸਿਆਵਾਂ ਤੱਕ.

ਮੈਂ ਇਸਨੂੰ ਉੱਚੀ ਆਵਾਜ਼ ਵਿੱਚ ਨਹੀਂ ਕਿਹਾ, ਪਰ DCS ਕਲੱਸਟਰ ਨੂੰ ਵੀ ਫੇਲਓਵਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਰਥਾਤ ਇਹ ਨੋਡਾਂ ਦੀ ਇੱਕ ਅਜੀਬ ਸੰਖਿਆ ਹੈ, ਇੱਕ ਕੋਰਮ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ। ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ DCS ਕਲੱਸਟਰ ਅਣਉਪਲਬਧ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਕੋਰਮ ਪੂਰਾ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਕਿਸੇ ਕਿਸਮ ਦਾ ਨੈਟਵਰਕ ਸਪਲਿਟ ਜਾਂ ਨੋਡ ਅਸਫਲਤਾ? ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਪੈਟਰੋਨੀ ਕਲੱਸਟਰ ਸਿਰਫ਼ ਰੀਡ ਮੋਡ ਵਿੱਚ ਚਲਾ ਜਾਂਦਾ ਹੈ। ਪੈਟਰੋਨੀ ਕਲੱਸਟਰ ਕਲੱਸਟਰ ਦੀ ਸਥਿਤੀ ਅਤੇ ਕੀ ਕਰਨਾ ਹੈ ਇਹ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ DCS ਨਾਲ ਸੰਪਰਕ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਉੱਥੇ ਨਵੀਂ ਕਲੱਸਟਰ ਸਥਿਤੀ ਨੂੰ ਸਟੋਰ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ, ਇਸਲਈ ਪੂਰਾ ਕਲੱਸਟਰ ਸਿਰਫ਼ ਪੜ੍ਹਨ ਵਿੱਚ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਜਾਂ ਤਾਂ ਆਪਰੇਟਰ ਤੋਂ ਦਸਤੀ ਦਖਲ ਦੀ ਜਾਂ DCS ਦੇ ਠੀਕ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ।

ਮੋਟੇ ਤੌਰ 'ਤੇ, ਡੀਸੀਐਸ ਸਾਡੇ ਲਈ ਓਨੀ ਹੀ ਮਹੱਤਵਪੂਰਨ ਸੇਵਾ ਬਣ ਜਾਂਦੀ ਹੈ ਜਿੰਨਾ ਕਿ ਅਧਾਰ ਆਪਣੇ ਆਪ ਵਿੱਚ?

ਹਾ ਹਾ. ਬਹੁਤ ਸਾਰੀਆਂ ਆਧੁਨਿਕ ਕੰਪਨੀਆਂ ਵਿੱਚ, ਸਰਵਿਸ ਡਿਸਕਵਰੀ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਇੱਕ ਅਨਿੱਖੜਵਾਂ ਅੰਗ ਹੈ। ਇਸ ਨੂੰ ਉਦੋਂ ਵੀ ਲਾਗੂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ ਜਦੋਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਇੱਕ ਡੇਟਾਬੇਸ ਵੀ ਸੀ. ਤੁਲਨਾਤਮਕ ਤੌਰ 'ਤੇ, ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ, ਡੀਸੀ ਵਿੱਚ ਤੈਨਾਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਸਾਡੇ ਕੋਲ ਤੁਰੰਤ ਸਰਵਿਸ ਡਿਸਕਵਰੀ ਹੈ। ਜੇ ਇਹ ਕੌਂਸਲ ਹੈ, ਤਾਂ ਇਸ 'ਤੇ DNS ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ. ਜੇਕਰ ਇਹ Etcd ਹੈ, ਤਾਂ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਦਾ ਇੱਕ ਹਿੱਸਾ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਬਾਕੀ ਸਭ ਕੁਝ ਤੈਨਾਤ ਕੀਤਾ ਜਾਵੇਗਾ। ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਹੈ ਕਿ ਸਰਵਿਸ ਡਿਸਕਵਰੀ ਪਹਿਲਾਂ ਹੀ ਆਧੁਨਿਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਇੱਕ ਅਨਿੱਖੜਵਾਂ ਅੰਗ ਹੈ। ਅਤੇ ਉਹ ਇਸ ਬਾਰੇ ਡੇਟਾਬੇਸ ਨਾਲੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਸੋਚਦੇ ਹਨ.

ਤੁਹਾਡਾ ਧੰਨਵਾਦ!

ਸਰੋਤ: www.habr.com