ਫੇਲਓਵਰ ਕਲੱਸਟਰ PostgreSQL + Patroni. ਲਾਗੂ ਕਰਨ ਦਾ ਤਜਰਬਾ

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

ਸਾਡੇ ਕੋਲ ਇੱਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਕੀਤੀ ਸੇਵਾ ਹੈ: ਦੁਨੀਆ ਭਰ ਵਿੱਚ 2,5 ਮਿਲੀਅਨ ਉਪਭੋਗਤਾ, ਹਰ ਦਿਨ 50K+ ਸਰਗਰਮ ਉਪਭੋਗਤਾ। ਸਰਵਰ ਆਇਰਲੈਂਡ ਦੇ ਇੱਕ ਖੇਤਰ ਵਿੱਚ ਐਮਾਜ਼ੋਨ ਵਿੱਚ ਸਥਿਤ ਹਨ: 100+ ਵੱਖ-ਵੱਖ ਸਰਵਰ ਲਗਾਤਾਰ ਕੰਮ ਕਰ ਰਹੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਲਗਭਗ 50 ਡੇਟਾਬੇਸ ਦੇ ਨਾਲ ਹਨ।

ਪੂਰਾ ਬੈਕਐਂਡ ਇੱਕ ਵਿਸ਼ਾਲ ਮੋਨੋਲੀਥਿਕ ਸਟੇਟਫੁੱਲ ਜਾਵਾ ਐਪਲੀਕੇਸ਼ਨ ਹੈ ਜੋ ਕਲਾਇੰਟ ਨਾਲ ਇੱਕ ਨਿਰੰਤਰ ਵੈਬਸਾਕੇਟ ਕਨੈਕਸ਼ਨ ਰੱਖਦਾ ਹੈ। ਜਦੋਂ ਕਈ ਉਪਭੋਗਤਾ ਇੱਕੋ ਸਮੇਂ ਇੱਕੋ ਬੋਰਡ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਤਾਂ ਉਹ ਸਾਰੇ ਅਸਲ ਸਮੇਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੇਖਦੇ ਹਨ, ਕਿਉਂਕਿ ਅਸੀਂ ਹਰੇਕ ਤਬਦੀਲੀ ਨੂੰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਲਿਖਦੇ ਹਾਂ। ਸਾਡੇ ਡੇਟਾਬੇਸ ਨੂੰ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲਗਭਗ 10K ਬੇਨਤੀਆਂ ਹਨ। Redis ਵਿੱਚ ਪੀਕ ਲੋਡ ਤੇ, ਅਸੀਂ ਪ੍ਰਤੀ ਸਕਿੰਟ 80-100K ਬੇਨਤੀਆਂ ਲਿਖਦੇ ਹਾਂ।

ਅਸੀਂ Redis ਤੋਂ PostgreSQL ਕਿਉਂ ਬਦਲੇ

ਸ਼ੁਰੂ ਵਿੱਚ, ਸਾਡੀ ਸੇਵਾ Redis ਨਾਲ ਕੰਮ ਕਰਦੀ ਸੀ, ਇੱਕ ਮੁੱਖ-ਮੁੱਲ ਸਟੋਰ ਜੋ ਸਰਵਰ ਦੀ RAM ਵਿੱਚ ਸਾਰਾ ਡਾਟਾ ਸਟੋਰ ਕਰਦਾ ਹੈ।

Redis ਦੇ ਫਾਇਦੇ:

1. ਉੱਚ ਪ੍ਰਤੀਕਿਰਿਆ ਦੀ ਗਤੀ, ਕਿਉਂਕਿ ਹਰ ਚੀਜ਼ ਮੈਮੋਰੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ;
2. ਬੈਕਅੱਪ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੀ ਸੌਖ.

ਸਾਡੇ ਲਈ Redis ਦੇ ਨੁਕਸਾਨ:

1. ਕੋਈ ਅਸਲੀ ਲੈਣ-ਦੇਣ ਨਹੀਂ ਹਨ। ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਪੱਧਰ 'ਤੇ ਨਕਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਹਮੇਸ਼ਾ ਵਧੀਆ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਸੀ ਅਤੇ ਬਹੁਤ ਗੁੰਝਲਦਾਰ ਕੋਡ ਲਿਖਣ ਦੀ ਲੋੜ ਸੀ।
2. ਡਾਟਾ ਦੀ ਮਾਤਰਾ ਮੈਮੋਰੀ ਦੀ ਮਾਤਰਾ ਦੁਆਰਾ ਸੀਮਿਤ ਹੈ. ਜਿਵੇਂ ਕਿ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਵਧਦੀ ਹੈ, ਮੈਮੋਰੀ ਵਧੇਗੀ, ਅਤੇ, ਅੰਤ ਵਿੱਚ, ਅਸੀਂ ਚੁਣੇ ਹੋਏ ਉਦਾਹਰਣ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਚਲੇ ਜਾਵਾਂਗੇ, ਜਿਸ ਵਿੱਚ AWS ਨੂੰ ਉਦਾਹਰਣ ਦੀ ਕਿਸਮ ਨੂੰ ਬਦਲਣ ਲਈ ਸਾਡੀ ਸੇਵਾ ਨੂੰ ਰੋਕਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
3. ਇਹ ਲਗਾਤਾਰ ਇੱਕ ਘੱਟ ਲੇਟੈਂਸੀ ਪੱਧਰ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਜ਼ਰੂਰੀ ਹੈ, ਕਿਉਂਕਿ. ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਬੇਨਤੀਆਂ ਹਨ। ਸਾਡੇ ਲਈ ਸਰਵੋਤਮ ਦੇਰੀ ਪੱਧਰ 17-20 ms ਹੈ। 30-40 ms ਦੇ ਪੱਧਰ 'ਤੇ, ਸਾਨੂੰ ਸਾਡੀ ਅਰਜ਼ੀ ਤੋਂ ਬੇਨਤੀਆਂ ਦੇ ਲੰਬੇ ਜਵਾਬ ਮਿਲਦੇ ਹਨ ਅਤੇ ਸੇਵਾ ਨੂੰ ਘਟਾਇਆ ਜਾਂਦਾ ਹੈ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਸਾਡੇ ਨਾਲ ਸਤੰਬਰ 2018 ਵਿੱਚ ਵਾਪਰਿਆ, ਜਦੋਂ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ Redis ਦੇ ਨਾਲ ਇੱਕ ਘਟਨਾ ਨੂੰ ਆਮ ਨਾਲੋਂ 2 ਗੁਣਾ ਵੱਧ ਲੇਟੈਂਸੀ ਪ੍ਰਾਪਤ ਹੋਈ। ਮੁੱਦੇ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਅਸੀਂ ਅਣ-ਨਿਯਤ ਰੱਖ-ਰਖਾਅ ਲਈ ਅੱਧ-ਦਿਨ ਸੇਵਾ ਬੰਦ ਕਰ ਦਿੱਤੀ ਹੈ ਅਤੇ ਸਮੱਸਿਆ ਵਾਲੇ Redis ਉਦਾਹਰਨ ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਹੈ।
4. ਕੋਡ ਵਿੱਚ ਮਾਮੂਲੀ ਗਲਤੀਆਂ ਦੇ ਨਾਲ ਵੀ ਡੇਟਾ ਅਸੰਗਤਤਾ ਪ੍ਰਾਪਤ ਕਰਨਾ ਆਸਾਨ ਹੈ ਅਤੇ ਫਿਰ ਇਸ ਡੇਟਾ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਕੋਡ ਲਿਖਣ ਵਿੱਚ ਬਹੁਤ ਸਮਾਂ ਬਿਤਾਉਣਾ ਹੈ।

ਅਸੀਂ ਨੁਕਸਾਨਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਅਤੇ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਸਾਨੂੰ ਆਮ ਲੈਣ-ਦੇਣ ਅਤੇ ਲੇਟੈਂਸੀ 'ਤੇ ਘੱਟ ਨਿਰਭਰਤਾ ਦੇ ਨਾਲ, ਕੁਝ ਹੋਰ ਸੁਵਿਧਾਜਨਕ ਵੱਲ ਜਾਣ ਦੀ ਲੋੜ ਹੈ। ਖੋਜ ਕੀਤੀ, ਕਈ ਵਿਕਲਪਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਅਤੇ PostgreSQL ਦੀ ਚੋਣ ਕੀਤੀ।

ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ 1,5 ਸਾਲਾਂ ਤੋਂ ਇੱਕ ਨਵੇਂ ਡੇਟਾਬੇਸ ਵਿੱਚ ਜਾ ਰਹੇ ਹਾਂ ਅਤੇ ਡੇਟਾ ਦਾ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਹਿੱਸਾ ਹੀ ਤਬਦੀਲ ਕੀਤਾ ਹੈ, ਇਸਲਈ ਹੁਣ ਅਸੀਂ Redis ਅਤੇ PostgreSQL ਦੇ ਨਾਲ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ। ਡੇਟਾਬੇਸ ਦੇ ਵਿਚਕਾਰ ਡੇਟਾ ਨੂੰ ਹਿਲਾਉਣ ਅਤੇ ਬਦਲਣ ਦੇ ਪੜਾਵਾਂ ਬਾਰੇ ਵਧੇਰੇ ਜਾਣਕਾਰੀ ਇਸ ਵਿੱਚ ਲਿਖੀ ਗਈ ਹੈ ਮੇਰੇ ਸਾਥੀ ਦਾ ਲੇਖ.

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

PgBouncer ਨੂੰ ਲਾਗੂ ਕਰਨਾ

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

ਸਾਡੇ ਕੋਲ ਕਨੈਕਸ਼ਨ ਮੈਨੇਜਰ ਲਈ ਦੋ ਵਿਕਲਪ ਸਨ: Pgpool ਅਤੇ PgBouncer। ਪਰ ਪਹਿਲਾ ਡੇਟਾਬੇਸ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਮੋਡ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ PgBouncer ਨੂੰ ਚੁਣਿਆ ਹੈ।

ਅਸੀਂ ਕੰਮ ਦੀ ਨਿਮਨਲਿਖਤ ਸਕੀਮ ਸਥਾਪਤ ਕੀਤੀ ਹੈ: ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ PgBouncer ਤੱਕ ਪਹੁੰਚ ਕਰਦੀ ਹੈ, ਜਿਸਦੇ ਪਿੱਛੇ PostgreSQL ਮਾਸਟਰ ਹਨ, ਅਤੇ ਹਰੇਕ ਮਾਸਟਰ ਦੇ ਪਿੱਛੇ ਅਸਿੰਕ੍ਰੋਨਸ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਾਲੀ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹੈ।


ਉਸੇ ਸਮੇਂ, ਅਸੀਂ PostgreSQL ਵਿੱਚ ਡੇਟਾ ਦੀ ਪੂਰੀ ਮਾਤਰਾ ਨੂੰ ਸਟੋਰ ਨਹੀਂ ਕਰ ਸਕਦੇ ਸੀ ਅਤੇ ਡੇਟਾਬੇਸ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਗਤੀ ਸਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ, ਇਸ ਲਈ ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ 'ਤੇ PostgreSQL ਨੂੰ ਸ਼ਾਰਡਿੰਗ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਹੈ। ਉੱਪਰ ਦੱਸੀ ਗਈ ਸਕੀਮ ਇਸਦੇ ਲਈ ਮੁਕਾਬਲਤਨ ਸੁਵਿਧਾਜਨਕ ਹੈ: ਇੱਕ ਨਵਾਂ PostgreSQL ਸ਼ਾਰਡ ਜੋੜਦੇ ਸਮੇਂ, ਇਹ PgBouncer ਸੰਰਚਨਾ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਕਾਫੀ ਹੈ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਤੁਰੰਤ ਨਵੇਂ ਸ਼ਾਰਡ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ।

PgBouncer ਫੇਲਓਵਰ

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

ਉਸ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ PgBouncer ਅਤੇ PostgreSQL ਕਲੱਸਟਰਾਂ ਦੀ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਬਾਰੇ ਗੰਭੀਰਤਾ ਨਾਲ ਸੋਚਿਆ, ਕਿਉਂਕਿ ਅਜਿਹੀ ਸਥਿਤੀ ਸਾਡੇ AWS ਖਾਤੇ ਵਿੱਚ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਨਾਲ ਹੋ ਸਕਦੀ ਹੈ।

ਅਸੀਂ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ PgBouncer ਫਾਲਟ ਟੋਲਰੈਂਸ ਸਕੀਮ ਬਣਾਈ ਹੈ: ਸਾਰੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਨੈੱਟਵਰਕ ਲੋਡ ਬੈਲੈਂਸਰ ਤੱਕ ਪਹੁੰਚ ਕਰਦੇ ਹਨ, ਜਿਸਦੇ ਪਿੱਛੇ ਦੋ PgBouncer ਹਨ। ਹਰੇਕ PgBouncer ਹਰੇਕ ਸ਼ਾਰਡ ਦੇ ਉਸੇ PostgreSQL ਮਾਸਟਰ ਨੂੰ ਵੇਖਦਾ ਹੈ। ਜੇਕਰ ਇੱਕ AWS ਉਦਾਹਰਨ ਕ੍ਰੈਸ਼ ਦੁਬਾਰਾ ਵਾਪਰਦਾ ਹੈ, ਤਾਂ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇੱਕ ਹੋਰ PgBouncer ਦੁਆਰਾ ਰੀਡਾਇਰੈਕਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਨੈੱਟਵਰਕ ਲੋਡ ਬੈਲੈਂਸਰ ਫੇਲਓਵਰ AWS ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤਾ ਗਿਆ ਹੈ।

ਇਹ ਸਕੀਮ ਨਵੇਂ PgBouncer ਸਰਵਰਾਂ ਨੂੰ ਜੋੜਨਾ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ।

ਇੱਕ PostgreSQL ਫੇਲਓਵਰ ਕਲੱਸਟਰ ਬਣਾਓ

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦੇ ਸਮੇਂ, ਅਸੀਂ ਵੱਖ-ਵੱਖ ਵਿਕਲਪਾਂ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ: ਸਵੈ-ਲਿਖਤ ਫੇਲਓਵਰ, repmgr, AWS RDS, Patroni।

ਸਵੈ-ਲਿਖਤ ਸਕ੍ਰਿਪਟਾਂ

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

ਇਸ ਪਹੁੰਚ ਦੇ ਫਾਇਦੇ ਵੱਧ ਤੋਂ ਵੱਧ ਸਰਲਤਾ ਹਨ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਸਕ੍ਰਿਪਟਾਂ ਲਿਖਦੇ ਹੋ ਅਤੇ ਸਮਝਦੇ ਹੋ ਕਿ ਉਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ.

ਨੁਕਸਾਨ:

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

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

Repmgr

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

AWS RDS

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

ਨੁਕਸਾਨਾਂ ਵਿੱਚ ਵਧੀਆ ਵਿਵਸਥਾਵਾਂ ਦੀ ਘਾਟ ਸ਼ਾਮਲ ਹੈ। ਵਧੀਆ ਟਿਊਨਿੰਗ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਦੇ ਤੌਰ 'ਤੇ: ਸਾਡੇ ਉਦਾਹਰਣਾਂ ਵਿੱਚ tcp ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਪਾਬੰਦੀਆਂ ਹਨ, ਜੋ ਕਿ ਬਦਕਿਸਮਤੀ ਨਾਲ, RDS ਵਿੱਚ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

ਇਸ ਤੋਂ ਇਲਾਵਾ, AWS RDS ਰੈਗੂਲਰ ਇੰਸਟੈਂਸ ਕੀਮਤ ਨਾਲੋਂ ਲਗਭਗ ਦੁੱਗਣਾ ਮਹਿੰਗਾ ਹੈ, ਜੋ ਕਿ ਇਸ ਹੱਲ ਨੂੰ ਛੱਡਣ ਦਾ ਮੁੱਖ ਕਾਰਨ ਸੀ।

ਸਰਪ੍ਰਸਤ

ਇਹ Github 'ਤੇ ਚੰਗੇ ਦਸਤਾਵੇਜ਼ਾਂ, ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਅਤੇ ਸਰੋਤ ਕੋਡ ਦੇ ਨਾਲ PostgreSQL ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਇੱਕ ਪਾਈਥਨ ਟੈਂਪਲੇਟ ਹੈ।

Patroni ਦੇ ਫਾਇਦੇ:

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

ਨੁਕਸਾਨ:

• ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ PgBouncer ਨਾਲ ਸਹੀ ਢੰਗ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ। ਹਾਲਾਂਕਿ ਇਸਨੂੰ ਮਾਇਨਸ ਕਹਿਣਾ ਔਖਾ ਹੈ, ਕਿਉਂਕਿ ਪੈਟਰੋਨੀ ਦਾ ਕੰਮ PostgreSQL ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਹੈ, ਅਤੇ Patroni ਨਾਲ ਕਨੈਕਸ਼ਨ ਕਿਵੇਂ ਚੱਲੇਗਾ ਇਹ ਪਹਿਲਾਂ ਹੀ ਸਾਡੀ ਸਮੱਸਿਆ ਹੈ;
• ਪੈਟਰੋਨੀ ਨੂੰ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਕੁਝ ਉਦਾਹਰਣਾਂ ਹਨ, ਜਦੋਂ ਕਿ ਸਕ੍ਰੈਚ ਤੋਂ ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਉਦਾਹਰਣਾਂ ਹਨ।

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਫੇਲਓਵਰ ਕਲੱਸਟਰ ਬਣਾਉਣ ਲਈ Patroni ਨੂੰ ਚੁਣਿਆ।

Patroni ਲਾਗੂ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ

Patroni ਤੋਂ ਪਹਿਲਾਂ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਮਾਸਟਰ ਦੀ ਸੰਰਚਨਾ ਵਿੱਚ 12 PostgreSQL ਸ਼ਾਰਡ ਅਤੇ ਅਸਿੰਕ੍ਰੋਨਸ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਨਾਲ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੀ। ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰਾਂ ਨੇ ਨੈੱਟਵਰਕ ਲੋਡ ਬੈਲੈਂਸਰ ਦੁਆਰਾ ਡੇਟਾਬੇਸ ਤੱਕ ਪਹੁੰਚ ਕੀਤੀ, ਜਿਸ ਦੇ ਪਿੱਛੇ PgBouncer ਦੇ ਨਾਲ ਦੋ ਉਦਾਹਰਨਾਂ ਸਨ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਪਿੱਛੇ ਸਾਰੇ PostgreSQL ਸਰਵਰ ਸਨ।


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

ਪੈਟਰੋਨੀ ਕੌਂਸਲ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

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

ਪੈਟਰੋਨੀ ਨੂੰ ਕੌਂਸਲ ਨਾਲ ਜੋੜਨ ਲਈ, ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਅਧਿਐਨ ਕਰਨਾ ਕਾਫ਼ੀ ਹੈ, ਜੋ ਕਹਿੰਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ HTTP ਜਾਂ https ਫਾਰਮੈਟ ਵਿੱਚ ਇੱਕ ਹੋਸਟ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਇਹ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਅਸੀਂ ਕੌਂਸਲ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਕੁਨੈਕਸ਼ਨ ਸਕੀਮ, ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ:

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

ਇਹ ਸਧਾਰਨ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਪਰ ਇੱਥੇ ਨੁਕਸਾਨ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ. ਕੌਂਸਲ ਦੇ ਨਾਲ, ਅਸੀਂ https ਰਾਹੀਂ ਇੱਕ ਸੁਰੱਖਿਅਤ ਕਨੈਕਸ਼ਨ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਾਂ ਅਤੇ ਸਾਡੀ ਕਨੈਕਸ਼ਨ ਦੀ ਸੰਰਚਨਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗੀ:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

ਪਰ ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ, ਪੈਟਰੋਨੀ ਕੌਂਸਲ ਨਾਲ ਨਹੀਂ ਜੁੜ ਸਕਦਾ, ਕਿਉਂਕਿ ਇਹ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ http ਰਾਹੀਂ ਜਾਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।

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

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

consul-template

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

ਇੱਕ ਹੱਲ ਦੀ ਖੋਜ ਵਿੱਚ, ਸਾਨੂੰ ਇੱਕ ਲੇਖ ਮਿਲਿਆ (ਬਦਕਿਸਮਤੀ ਨਾਲ ਸਿਰਲੇਖ ਯਾਦ ਨਹੀਂ ਹੈ) ਜਿੱਥੇ ਇਹ ਲਿਖਿਆ ਗਿਆ ਸੀ ਕਿ Сonsul-template ਨੇ PgBouncer ਅਤੇ Patroni ਨੂੰ ਜੋੜਨ ਵਿੱਚ ਬਹੁਤ ਮਦਦ ਕੀਤੀ ਹੈ। ਇਸ ਨੇ ਸਾਨੂੰ ਜਾਂਚ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕੀਤਾ ਕਿ ਕੌਂਸਲ-ਟੈਂਪਲੇਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਕੌਂਸਲ-ਟੈਂਪਲੇਟ ਲਗਾਤਾਰ Consul ਵਿੱਚ PostgreSQL ਕਲੱਸਟਰ ਦੀ ਸੰਰਚਨਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਲੀਡਰ ਬਦਲਦਾ ਹੈ, ਇਹ PgBouncer ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਮੁੜ ਲੋਡ ਕਰਨ ਲਈ ਇੱਕ ਕਮਾਂਡ ਭੇਜਦਾ ਹੈ।

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

Patroni ਦੇ ਨਾਲ ਨਵਾਂ ਆਰਕੀਟੈਕਚਰ

ਨਤੀਜੇ ਵਜੋਂ, ਸਾਨੂੰ ਕੰਮ ਦੀ ਹੇਠ ਲਿਖੀ ਯੋਜਨਾ ਮਿਲੀ:


ਸਾਰੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਬੈਲੇਂਸਰ ਤੱਕ ਪਹੁੰਚ ਕਰਦੇ ਹਨ → ਇਸਦੇ ਪਿੱਛੇ PgBouncer ਦੀਆਂ ਦੋ ਉਦਾਹਰਣਾਂ ਹਨ → ਹਰ ਇੱਕ ਮੌਕੇ 'ਤੇ, Consul-template ਨੂੰ ਲਾਂਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਹਰੇਕ Patroni ਕਲੱਸਟਰ ਦੀ ਸਥਿਤੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ ਅਤੇ PgBouncer ਕੌਂਫਿਗ ਦੀ ਪ੍ਰਸੰਗਿਕਤਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ, ਜੋ ਮੌਜੂਦਾ ਲੀਡਰ ਨੂੰ ਬੇਨਤੀਆਂ ਭੇਜਦਾ ਹੈ। ਹਰੇਕ ਕਲੱਸਟਰ ਦਾ।

ਮੈਨੁਅਲ ਟੈਸਟਿੰਗ

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

ਸਟਿੱਕਰ 10-20 ਸਕਿੰਟਾਂ ਦੇ ਅੰਦਰ ਵਾਪਸ ਆ ਗਿਆ, ਅਤੇ ਫਿਰ ਦੁਬਾਰਾ ਆਮ ਤੌਰ 'ਤੇ ਹਿੱਲਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪੈਟਰੋਨੀ ਕਲੱਸਟਰ ਨੇ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕੀਤਾ: ਇਸ ਨੇ ਲੀਡਰ ਨੂੰ ਬਦਲਿਆ, Сonsul ਨੂੰ ਜਾਣਕਾਰੀ ਭੇਜੀ, ਅਤੇ Сonsul-template ਨੇ ਤੁਰੰਤ ਇਸ ਜਾਣਕਾਰੀ ਨੂੰ ਚੁੱਕ ਲਿਆ, PgBouncer ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਅਤੇ ਮੁੜ ਲੋਡ ਕਰਨ ਲਈ ਕਮਾਂਡ ਭੇਜੀ।

ਉੱਚ ਬੋਝ ਹੇਠ ਕਿਵੇਂ ਬਚਣਾ ਹੈ ਅਤੇ ਡਾਊਨਟਾਈਮ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਿਵੇਂ ਰੱਖਣਾ ਹੈ?

ਸਭ ਕੁਝ ਬਿਲਕੁਲ ਕੰਮ ਕਰਦਾ ਹੈ! ਪਰ ਨਵੇਂ ਸਵਾਲ ਹਨ: ਇਹ ਉੱਚ ਲੋਡ ਦੇ ਅਧੀਨ ਕਿਵੇਂ ਕੰਮ ਕਰੇਗਾ? ਉਤਪਾਦਨ ਵਿੱਚ ਹਰ ਚੀਜ਼ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਕਿਵੇਂ ਰੋਲ ਆਊਟ ਕਰਨਾ ਹੈ?

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

ਦੋਵੇਂ ਕੰਮ ਅਭਿਲਾਸ਼ੀ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਪਰ ਸਾਡੇ ਕੋਲ PostgreSQL 9.6 ਹੈ। ਕੀ ਅਸੀਂ ਤੁਰੰਤ 11.2 ਤੱਕ ਅੱਪਗਰੇਡ ਕਰ ਸਕਦੇ ਹਾਂ?

ਅਸੀਂ ਇਸਨੂੰ 2 ਪੜਾਵਾਂ ਵਿੱਚ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦੇ ਹਾਂ: ਪਹਿਲਾਂ 11.2 ਵਿੱਚ ਅੱਪਗ੍ਰੇਡ ਕਰੋ, ਫਿਰ Patroni ਨੂੰ ਲਾਂਚ ਕਰੋ।

PostgreSQL ਅੱਪਡੇਟ

PostgreSQL ਸੰਸਕਰਣ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅਪਡੇਟ ਕਰਨ ਲਈ, ਵਿਕਲਪ ਦੀ ਵਰਤੋਂ ਕਰੋ -k, ਜਿਸ ਵਿੱਚ ਹਾਰਡ ਲਿੰਕ ਡਿਸਕ 'ਤੇ ਬਣਾਏ ਗਏ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਡੇਟਾ ਨੂੰ ਕਾਪੀ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ। 300-400 GB ਦੇ ਆਧਾਰ 'ਤੇ, ਅੱਪਡੇਟ ਨੂੰ 1 ਸਕਿੰਟ ਲੱਗਦਾ ਹੈ।

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

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

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

Patroni ਲਾਂਚ ਕਰੋ

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

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

rm -rf /var/lib/postgresql/

ਇਹ ਸਿਰਫ ਗੁਲਾਮ 'ਤੇ ਕਰਨ ਦੀ ਲੋੜ ਹੈ!

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

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

ਲੋਡ ਟੈਸਟ

ਅਸੀਂ ਇੱਕ ਟੈਸਟ ਲਾਂਚ ਕੀਤਾ ਹੈ ਜੋ ਬੋਰਡਾਂ 'ਤੇ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਲੋਡ ਸਾਡੇ ਔਸਤ ਰੋਜ਼ਾਨਾ ਮੁੱਲ 'ਤੇ ਪਹੁੰਚ ਗਿਆ, ਅਸੀਂ ਬਿਲਕੁਲ ਉਹੀ ਟੈਸਟ ਦੁਹਰਾਇਆ, ਅਸੀਂ PostgreSQL ਲੀਡਰ ਦੇ ਨਾਲ ਇੱਕ ਵਾਰ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਨੇ ਸਾਡੀ ਉਮੀਦ ਅਨੁਸਾਰ ਕੰਮ ਕੀਤਾ: ਪੈਟਰੋਨੀ ਨੇ ਲੀਡਰ ਨੂੰ ਬਦਲ ਦਿੱਤਾ, ਕੌਂਸਲ-ਟੈਂਪਲੇਟ ਨੇ PgBouncer ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਅਪਡੇਟ ਕੀਤਾ ਅਤੇ ਰੀਲੋਡ ਕਰਨ ਲਈ ਇੱਕ ਕਮਾਂਡ ਭੇਜੀ। ਗ੍ਰਾਫਾਨਾ ਵਿੱਚ ਸਾਡੇ ਗ੍ਰਾਫਾਂ ਦੇ ਅਨੁਸਾਰ, ਇਹ ਸਪੱਸ਼ਟ ਸੀ ਕਿ ਡੇਟਾਬੇਸ ਨਾਲ ਕੁਨੈਕਸ਼ਨ ਨਾਲ ਜੁੜੇ ਸਰਵਰਾਂ ਤੋਂ 20-30 ਸਕਿੰਟਾਂ ਦੀ ਦੇਰੀ ਅਤੇ ਥੋੜ੍ਹੀ ਜਿਹੀ ਗਲਤੀਆਂ ਹਨ. ਇਹ ਇੱਕ ਆਮ ਸਥਿਤੀ ਹੈ, ਅਜਿਹੇ ਮੁੱਲ ਸਾਡੇ ਫੇਲਓਵਰ ਲਈ ਸਵੀਕਾਰਯੋਗ ਹਨ ਅਤੇ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਸਰਵਿਸ ਡਾਊਨਟਾਈਮ ਨਾਲੋਂ ਬਿਹਤਰ ਹਨ।

ਪੈਟਰੋਨੀ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਲਿਆਉਣਾ

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਹੇਠ ਲਿਖੀ ਯੋਜਨਾ ਲੈ ਕੇ ਆਏ ਹਾਂ:

• ਕੰਸਲ-ਟੈਂਪਲੇਟ ਨੂੰ PgBouncer ਸਰਵਰਾਂ 'ਤੇ ਤਾਇਨਾਤ ਕਰੋ ਅਤੇ ਲਾਂਚ ਕਰੋ;
• PostgreSQL ਸੰਸਕਰਣ 11.2 ਲਈ ਅੱਪਡੇਟ;
• ਕਲੱਸਟਰ ਦਾ ਨਾਮ ਬਦਲੋ;
• ਪੈਟ੍ਰੋਨੀ ਕਲੱਸਟਰ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।

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

ਤਤਕਾਲ ਤੈਨਾਤੀ ਲਈ, ਅਸੀਂ Ansible ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਕਿਉਂਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਟੈਸਟ ਵਾਤਾਵਰਨ 'ਤੇ ਸਾਰੀਆਂ ਪਲੇਬੁੱਕਾਂ ਦੀ ਜਾਂਚ ਕਰ ਚੁੱਕੇ ਹਾਂ, ਅਤੇ ਪੂਰੀ ਸਕ੍ਰਿਪਟ ਦਾ ਲਾਗੂ ਕਰਨ ਦਾ ਸਮਾਂ ਹਰੇਕ ਸ਼ਾਰਡ ਲਈ 1,5 ਤੋਂ 2 ਮਿੰਟ ਤੱਕ ਸੀ। ਅਸੀਂ ਆਪਣੀ ਸੇਵਾ ਨੂੰ ਰੋਕੇ ਬਿਨਾਂ ਹਰ ਇੱਕ ਸ਼ਾਰਡ ਵਿੱਚ ਬਦਲੇ ਵਿੱਚ ਸਭ ਕੁਝ ਰੋਲ ਆਊਟ ਕਰ ਸਕਦੇ ਹਾਂ, ਪਰ ਸਾਨੂੰ ਹਰੇਕ PostgreSQL ਨੂੰ ਕਈ ਮਿੰਟਾਂ ਲਈ ਬੰਦ ਕਰਨਾ ਹੋਵੇਗਾ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਉਪਭੋਗਤਾ ਜਿਨ੍ਹਾਂ ਦਾ ਡੇਟਾ ਇਸ ਸ਼ਾਰਡ ਵਿੱਚ ਹੈ, ਇਸ ਸਮੇਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਸਾਡੇ ਲਈ ਅਸਵੀਕਾਰਨਯੋਗ ਹੈ।

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


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


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

Patroni ਕਲੱਸਟਰ ਨੂੰ ਮੁੜ-ਚਾਲੂ ਕਰੋ

ਹਾਲਾਂਕਿ, ਸਾਨੂੰ ਇੱਕ ਨਵੀਂ ਸਮੱਸਿਆ ਮਿਲੀ, ਜਿਸ ਬਾਰੇ ਸਾਨੂੰ ਸ਼ੱਕ ਵੀ ਨਹੀਂ ਸੀ। Consul ਨੂੰ ਅੱਪਡੇਟ ਕਰਦੇ ਸਮੇਂ, ਅਸੀਂ ਸਿਰਫ਼ ਕੌਂਸਲ ਲੀਵ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਲੱਸਟਰ ਤੋਂ ਕੌਂਸਲ ਨੋਡ ਨੂੰ ਹਟਾ ਦਿੰਦੇ ਹਾਂ → Patroni ਕਿਸੇ ਹੋਰ ਕੌਂਸਲ ਸਰਵਰ ਨਾਲ ਜੁੜਦਾ ਹੈ → ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ। ਪਰ ਜਦੋਂ ਅਸੀਂ ਕੌਂਸਲ ਕਲੱਸਟਰ ਦੀ ਆਖਰੀ ਸਥਿਤੀ 'ਤੇ ਪਹੁੰਚ ਗਏ ਅਤੇ ਇਸ ਨੂੰ ਕੌਂਸਲ ਛੁੱਟੀ ਕਮਾਂਡ ਭੇਜੀ, ਤਾਂ ਸਾਰੇ ਪੈਟਰੋਨੀ ਕਲੱਸਟਰ ਬਸ ਮੁੜ ਚਾਲੂ ਹੋ ਗਏ, ਅਤੇ ਲੌਗਸ ਵਿੱਚ ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀ ਗਲਤੀ ਦੇਖੀ:

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

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

ਇੱਕ ਹੱਲ ਲੱਭਣ ਲਈ, ਅਸੀਂ ਗੀਥਬ 'ਤੇ ਇੱਕ ਮੁੱਦੇ ਰਾਹੀਂ Patroni ਲੇਖਕਾਂ ਨਾਲ ਸੰਪਰਕ ਕੀਤਾ। ਉਹਨਾਂ ਨੇ ਸਾਡੀਆਂ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਵਿੱਚ ਸੁਧਾਰਾਂ ਦਾ ਸੁਝਾਅ ਦਿੱਤਾ:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

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

ਸਮੱਸਿਆ ਅਜੇ ਵੀ ਅਣਸੁਲਝੀ ਹੋਈ ਹੈ। ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਹੱਲਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ:

• ਹਰੇਕ ਪੈਟਰੋਨੀ ਕਲੱਸਟਰ ਮੌਕੇ 'ਤੇ ਕੌਂਸਲ-ਏਜੰਟ ਦੀ ਵਰਤੋਂ ਕਰੋ;
• ਕੋਡ ਵਿੱਚ ਸਮੱਸਿਆ ਨੂੰ ਠੀਕ ਕਰੋ।

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

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਸਾਨੂੰ ਕੋਈ ਹੋਰ ਤਰੁੱਟੀਆਂ ਦਾ ਸਾਹਮਣਾ ਨਹੀਂ ਕਰਨਾ ਪਿਆ।

Patroni ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਨਤੀਜੇ

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


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

Patroni ਦੀ ਵਰਤੋਂ ਦਾ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਸੰਖੇਪ:

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

ਸਰੋਤ: www.habr.com