ਕੁਬਰਨੇਟਸ, ਸਾਡੀਆਂ ਚੋਣਾਂ ਅਤੇ ਅਨੁਭਵ ਲਈ PostgreSQL ਸਟੇਟਮੈਂਟਾਂ ਦੀ ਇੱਕ ਸੰਖੇਪ ਜਾਣਕਾਰੀ

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

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

RDS ਕੀ ਹੈ

ਜਦੋਂ ਲੋਕ RDS ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਨ, ਸਾਡੇ ਅਨੁਭਵ ਵਿੱਚ, ਉਹਨਾਂ ਦਾ ਮਤਲਬ ਇੱਕ ਪ੍ਰਬੰਧਿਤ DBMS ਸੇਵਾ ਹੈ ਜੋ:

1. ਸੰਰਚਨਾ ਕਰਨ ਲਈ ਆਸਾਨ;
2. ਸਨੈਪਸ਼ਾਟ ਨਾਲ ਕੰਮ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਤੋਂ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਰੱਖਦਾ ਹੈ (ਤਰਜੀਹੀ ਤੌਰ 'ਤੇ ਸਮਰਥਨ ਨਾਲ ਪੀ.ਆਈ.ਟੀ.ਆਰ);
3. ਤੁਹਾਨੂੰ ਮਾਸਟਰ-ਸਲੇਵ ਟੋਪੋਲੋਜੀ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ;
4. ਐਕਸਟੈਂਸ਼ਨਾਂ ਦੀ ਇੱਕ ਅਮੀਰ ਸੂਚੀ ਹੈ;
5. ਆਡਿਟਿੰਗ ਅਤੇ ਉਪਭੋਗਤਾ/ਪਹੁੰਚ ਪ੍ਰਬੰਧਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

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

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

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

PostgreSQL ਲਈ ਕਈ ਪ੍ਰਸਿੱਧ K8s ਆਪਰੇਟਰ ਹਨ:

• ਸਟੋਲੋਨ;
• ਕਰੰਚੀ ਡਾਟਾ PostgreSQL ਆਪਰੇਟਰ;
• ਜ਼ਲੈਂਡੋ ਪੋਸਟਗ੍ਰੇਸ ਆਪਰੇਟਰ।

ਆਉ ਉਹਨਾਂ ਨੂੰ ਹੋਰ ਧਿਆਨ ਨਾਲ ਵੇਖੀਏ.

ਆਪਰੇਟਰ ਦੀ ਚੋਣ

ਉੱਪਰ ਦੱਸੀਆਂ ਗਈਆਂ ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ - ਕੁਬਰਨੇਟਸ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸੰਚਾਲਨ ਇੰਜਨੀਅਰ ਦੇ ਤੌਰ 'ਤੇ - ਆਪਰੇਟਰਾਂ ਤੋਂ ਇਹ ਵੀ ਉਮੀਦ ਕਰਦੇ ਹਾਂ:

• Git ਅਤੇ ਨਾਲ ਤੈਨਾਤੀ ਕਸਟਮ ਸਰੋਤ;
• ਪੌਡ ਐਂਟੀ-ਐਫੀਨਿਟੀ ਸਪੋਰਟ;
• ਨੋਡ ਐਫੀਨਿਟੀ ਜਾਂ ਨੋਡ ਚੋਣਕਾਰ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨਾ;
• ਸਹਿਣਸ਼ੀਲਤਾ ਦੀ ਸਥਾਪਨਾ;
• ਟਿਊਨਿੰਗ ਸਮਰੱਥਾ ਦੀ ਉਪਲਬਧਤਾ;
• ਸਮਝਣ ਯੋਗ ਤਕਨਾਲੋਜੀਆਂ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਹੁਕਮ ਵੀ।

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

ਆਉ ਹੁਣ PostgreSQL ਆਪਰੇਟਰਾਂ ਵੱਲ ਵਧੀਏ।

1. ਸਟੋਲਨ

ਸਟੋਲਨ ਵਿੱਚ ਇਤਾਲਵੀ ਕੰਪਨੀ Sorint.lab ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਜ਼ਿਕਰ ਕੀਤੀ ਰਿਪੋਰਟ DBMS ਲਈ ਆਪਰੇਟਰਾਂ ਵਿੱਚ ਇੱਕ ਕਿਸਮ ਦਾ ਮਿਆਰ ਮੰਨਿਆ ਜਾਂਦਾ ਸੀ। ਇਹ ਕਾਫ਼ੀ ਪੁਰਾਣਾ ਪ੍ਰੋਜੈਕਟ ਹੈ: ਇਸਦਾ ਪਹਿਲਾ ਜਨਤਕ ਰੀਲੀਜ਼ ਨਵੰਬਰ 2015 (!) ਵਿੱਚ ਹੋਇਆ ਸੀ, ਅਤੇ GitHub ਰਿਪੋਜ਼ਟਰੀ ਲਗਭਗ 3000 ਸਿਤਾਰਿਆਂ ਅਤੇ 40+ ਯੋਗਦਾਨੀਆਂ ਦਾ ਮਾਣ ਕਰਦੀ ਹੈ।

ਦਰਅਸਲ, ਸਟੋਲਨ ਵਿਚਾਰਸ਼ੀਲ ਆਰਕੀਟੈਕਚਰ ਦਾ ਇੱਕ ਸ਼ਾਨਦਾਰ ਉਦਾਹਰਣ ਹੈ:

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

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

ਇੱਕ ਪਾਸੇ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਓਪਰੇਟਰ ਅਸਲ ਵਿੱਚ ਇੱਕ ਆਪਰੇਟਰ ਨਹੀਂ ਹੈ (ਆਖ਼ਰਕਾਰ, ਇਹ CRD ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ). ਪਰ ਦੂਜੇ ਪਾਸੇ, ਇਹ ਇੱਕ ਲਚਕੀਲਾ ਸਿਸਟਮ ਹੈ ਜੋ ਤੁਹਾਨੂੰ K8s ਵਿੱਚ ਸਰੋਤਾਂ ਨੂੰ ਸੰਰਚਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਫਿੱਟ ਦੇਖਦੇ ਹੋ।

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

2. ਕਰੰਚੀ ਡੇਟਾ PostgreSQL ਆਪਰੇਟਰ

ਕਰੰਚੀ ਡੇਟਾ ਤੋਂ ਆਪਰੇਟਰ, ਇੱਕ ਨੌਜਵਾਨ ਅਮਰੀਕੀ ਸ਼ੁਰੂਆਤ, ਇੱਕ ਤਰਕਪੂਰਨ ਵਿਕਲਪ ਵਾਂਗ ਜਾਪਦਾ ਸੀ। ਇਸਦਾ ਜਨਤਕ ਇਤਿਹਾਸ ਮਾਰਚ 2017 ਵਿੱਚ ਪਹਿਲੀ ਰੀਲੀਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਉਦੋਂ ਤੋਂ GitHub ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਸਿਰਫ 1300 ਤੋਂ ਘੱਟ ਸਿਤਾਰੇ ਅਤੇ 50+ ਯੋਗਦਾਨੀ ਪ੍ਰਾਪਤ ਹੋਏ ਹਨ। ਸਤੰਬਰ ਤੋਂ ਨਵੀਨਤਮ ਰਿਲੀਜ਼ ਨੂੰ Kubernetes 1.15-1.18, OpenShift 3.11+ ਅਤੇ 4.4+, GKE ਅਤੇ VMware Enterprise PKS 1.3+ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਟੈਸਟ ਕੀਤਾ ਗਿਆ ਸੀ।

Crunchy Data PostgreSQL ਆਪਰੇਟਰ ਦਾ ਆਰਕੀਟੈਕਚਰ ਵੀ ਦੱਸੀਆਂ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ:

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

• CRD ਦੁਆਰਾ ਨਿਯੰਤਰਣ ਹੈ;
• ਸੁਵਿਧਾਜਨਕ ਉਪਭੋਗਤਾ ਪ੍ਰਬੰਧਨ (ਸੀਆਰਡੀ ਦੁਆਰਾ ਵੀ);
• ਹੋਰ ਭਾਗਾਂ ਨਾਲ ਏਕੀਕਰਣ ਕਰੰਚੀ ਡੇਟਾ ਕੰਟੇਨਰ ਸੂਟ — PostgreSQL ਲਈ ਕੰਟੇਨਰ ਚਿੱਤਰਾਂ ਦਾ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸੰਗ੍ਰਹਿ ਅਤੇ ਇਸਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਉਪਯੋਗਤਾਵਾਂ (ਸਮੇਤ pgBackRest, pgAudit, ਯੋਗਦਾਨ ਤੋਂ ਐਕਸਟੈਂਸ਼ਨਾਂ ਆਦਿ)।

ਹਾਲਾਂਕਿ, ਕਰੰਚੀ ਡੇਟਾ ਤੋਂ ਆਪਰੇਟਰ ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਨੇ ਕਈ ਸਮੱਸਿਆਵਾਂ ਦਾ ਖੁਲਾਸਾ ਕੀਤਾ:

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

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

ਇਸ ਆਪਰੇਟਰ ਦੀ ਇੱਕ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾ ਵੱਖ-ਵੱਖ ਸਹਾਇਕ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਨਾਲ ਇਸਦਾ ਤਿਆਰ-ਬਣਾਇਆ ਏਕੀਕਰਣ ਹੈ। ਉਦਾਹਰਨ ਲਈ, pgAdmin ਅਤੇ pgBounce, ਅਤੇ ਵਿੱਚ ਇੰਸਟਾਲ ਕਰਨਾ ਆਸਾਨ ਹੈ ਦਸਤਾਵੇਜ਼ ਪੂਰਵ-ਸੰਰਚਿਤ ਗ੍ਰਾਫਾਨਾ ਅਤੇ ਪ੍ਰੋਮੀਥੀਅਸ ਨੂੰ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਹਾਲ ਹੀ ਵਿੱਚ ਰੀਲੀਜ਼ 4.5.0-beta1 ਪ੍ਰੋਜੈਕਟ ਦੇ ਨਾਲ ਬਿਹਤਰ ਏਕੀਕਰਣ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਨੋਟ ਕੀਤਾ ਗਿਆ ਹੈ pgMonitor, ਜਿਸਦਾ ਧੰਨਵਾਦ ਓਪਰੇਟਰ ਬਾਕਸ ਦੇ ਬਾਹਰ PgSQL ਮੈਟ੍ਰਿਕਸ ਦੀ ਸਪਸ਼ਟ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ।

ਹਾਲਾਂਕਿ, ਕੁਬਰਨੇਟਸ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਸਰੋਤਾਂ ਦੀ ਅਜੀਬ ਚੋਣ ਨੇ ਸਾਨੂੰ ਇੱਕ ਵੱਖਰਾ ਹੱਲ ਲੱਭਣ ਦੀ ਜ਼ਰੂਰਤ ਵੱਲ ਅਗਵਾਈ ਕੀਤੀ।

3. ਜ਼ਲੈਂਡੋ ਪੋਸਟਗ੍ਰੇਸ ਆਪਰੇਟਰ

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

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

"ਹੁੱਡ ਦੇ ਹੇਠਾਂ" ਇਹ ਆਪਰੇਟਰ ਸਮੇਂ-ਪਰੀਖਣ ਵਾਲੇ ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ:

• ਸਰਪ੍ਰਸਤ ਅਤੇ ਸਪਿਲੋ ਗੱਡੀ ਚਲਾਉਣ ਲਈ,
• ਵਾਲ-ਈ - ਬੈਕਅੱਪ ਲਈ,
• ਪੀਜੀਬਾਊਂਸਰ - ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਪੂਲ ਦੇ ਤੌਰ ਤੇ.

ਜ਼ਲੈਂਡੋ ਤੋਂ ਓਪਰੇਟਰ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ:

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

ਕਿਉਂਕਿ ਅਸੀਂ ਵਿਚਾਰ ਅਧੀਨ 3 ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਜ਼ਲੈਂਡੋ ਤੋਂ ਹੱਲ ਚੁਣਿਆ ਹੈ, ਇਸਦੀ ਸਮਰੱਥਾ ਦਾ ਇੱਕ ਹੋਰ ਵੇਰਵਾ ਹੇਠਾਂ ਪੇਸ਼ ਕੀਤਾ ਜਾਵੇਗਾ, ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅਭਿਆਸ ਦੇ ਨਾਲ-ਨਾਲ।

ਜ਼ਲੈਂਡੋ ਤੋਂ ਪੋਸਟਗ੍ਰੇਸ ਆਪਰੇਟਰ ਨਾਲ ਅਭਿਆਸ ਕਰੋ

ਓਪਰੇਟਰ ਤੈਨਾਤੀ ਬਹੁਤ ਸਧਾਰਨ ਹੈ: GitHub ਤੋਂ ਮੌਜੂਦਾ ਰੀਲੀਜ਼ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰੋ ਅਤੇ ਡਾਇਰੈਕਟਰੀ ਤੋਂ YAML ਫਾਈਲਾਂ ਨੂੰ ਲਾਗੂ ਕਰੋ ਪ੍ਰਗਟ ਹੁੰਦਾ ਹੈ. ਵਿਕਲਪਕ ਤੌਰ 'ਤੇ, ਤੁਸੀਂ ਵੀ ਵਰਤ ਸਕਦੇ ਹੋ operatorhub.

ਇੰਸਟਾਲੇਸ਼ਨ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਨੂੰ ਸਥਾਪਤ ਕਰਨ ਬਾਰੇ ਚਿੰਤਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਲਾਗ ਅਤੇ ਬੈਕਅੱਪ ਲਈ ਸਟੋਰੇਜ਼. ਇਹ ConfigMap ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ postgres-operator ਨੇਮਸਪੇਸ ਵਿੱਚ ਜਿੱਥੇ ਤੁਸੀਂ ਆਪਰੇਟਰ ਸਥਾਪਿਤ ਕੀਤਾ ਹੈ। ਇੱਕ ਵਾਰ ਰਿਪੋਜ਼ਟਰੀਆਂ ਦੀ ਸੰਰਚਨਾ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਆਪਣਾ ਪਹਿਲਾ PostgreSQL ਕਲੱਸਟਰ ਤੈਨਾਤ ਕਰ ਸਕਦੇ ਹੋ।

ਉਦਾਹਰਨ ਲਈ, ਸਾਡੀ ਮਿਆਰੀ ਤੈਨਾਤੀ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
 name: staging-db
spec:
 numberOfInstances: 3
 patroni:
   synchronous_mode: true
 postgresql:
   version: "12"
 resources:
   limits:
     cpu: 100m
     memory: 1Gi
   requests:
     cpu: 100m
     memory: 1Gi
 sidecars:
 - env:
   - name: DATA_SOURCE_URI
     value: 127.0.0.1:5432
   - name: DATA_SOURCE_PASS
     valueFrom:
       secretKeyRef:
         key: password
         name: postgres.staging-db.credentials
   - name: DATA_SOURCE_USER
     value: postgres
   image: wrouesnel/postgres_exporter
   name: prometheus-exporter
   resources:
     limits:
       cpu: 500m
       memory: 100Mi
     requests:
       cpu: 100m
       memory: 100Mi
 teamId: staging
 volume:
   size: 2Gi

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

ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਵੈੱਬ ਪ੍ਰਸ਼ਾਸਨ ਪੈਨਲ - postgres-operator-ui. ਇਹ ਆਪਰੇਟਰ ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਕਲੱਸਟਰ ਬਣਾਉਣ ਅਤੇ ਮਿਟਾਉਣ ਦੇ ਨਾਲ-ਨਾਲ ਆਪਰੇਟਰ ਦੁਆਰਾ ਬਣਾਏ ਬੈਕਅੱਪ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

PostgreSQL ਕਲੱਸਟਰਾਂ ਦੀ ਸੂਚੀ

ਬੈਕਅੱਪ ਪ੍ਰਬੰਧਨ

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

ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਹੱਲ

ਹਾਲਾਂਕਿ, ਆਪਰੇਟਰ ਦੀ ਵਰਤੋਂ ਨੇ ਜਲਦੀ ਹੀ ਕਈ ਮਹੱਤਵਪੂਰਨ ਕਮੀਆਂ ਦਾ ਖੁਲਾਸਾ ਕੀਤਾ:

1. nodeSelector ਸਹਿਯੋਗ ਦੀ ਘਾਟ;
2. ਬੈਕਅੱਪ ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਉਣ ਲਈ ਅਸਮਰੱਥਾ;
3. ਡਾਟਾਬੇਸ ਬਣਾਉਣ ਦੇ ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਡਿਫਾਲਟ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦੇ;
4. ਕਈ ਵਾਰ ਦਸਤਾਵੇਜ਼ ਗੁੰਮ ਹੁੰਦੇ ਹਨ ਜਾਂ ਪੁਰਾਣੇ ਹੁੰਦੇ ਹਨ।

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਹੱਲ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ. ਆਉ ਅੰਤ ਤੋਂ ਸ਼ੁਰੂ ਕਰੀਏ - ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦਸਤਾਵੇਜ਼.

ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਤੁਸੀਂ ਇਸ ਤੱਥ ਦਾ ਸਾਹਮਣਾ ਕਰੋਗੇ ਕਿ ਇਹ ਹਮੇਸ਼ਾ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੁੰਦਾ ਹੈ ਕਿ ਬੈਕਅੱਪ ਕਿਵੇਂ ਰਜਿਸਟਰ ਕਰਨਾ ਹੈ ਅਤੇ ਬੈਕਅੱਪ ਬਾਲਟੀ ਨੂੰ ਓਪਰੇਟਰ UI ਨਾਲ ਕਿਵੇਂ ਕਨੈਕਟ ਕਰਨਾ ਹੈ। ਦਸਤਾਵੇਜ਼ ਇਸ ਬਾਰੇ ਲੰਘਣ ਵਿੱਚ ਗੱਲ ਕਰਦੇ ਹਨ, ਪਰ ਅਸਲ ਵੇਰਵਾ ਇਸ ਵਿੱਚ ਹੈ PR:

1. ਇੱਕ ਗੁਪਤ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ;
2. ਇਸ ਨੂੰ ਪੈਰਾਮੀਟਰ ਦੇ ਤੌਰ 'ਤੇ ਆਪਰੇਟਰ ਨੂੰ ਭੇਜੋ pod_environment_secret_name ਓਪਰੇਟਰ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ CRD ਵਿੱਚ ਜਾਂ ConfigMap ਵਿੱਚ (ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਓਪਰੇਟਰ ਨੂੰ ਕਿਵੇਂ ਸਥਾਪਿਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦੇ ਹੋ)।

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

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

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

ਹਾਂ, 2 ਓਪਰੇਟਰਾਂ ਨੂੰ ਚਲਾ ਕੇ ਇਸਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਕਰਨ ਦਾ ਮੌਕਾ ਸੀ: ਇੱਕ ਸਟੇਜਿੰਗ (ਬੈਕਅੱਪ ਤੋਂ ਬਿਨਾਂ), ਅਤੇ ਦੂਜਾ ਉਤਪਾਦਨ ਲਈ। ਪਰ ਅਸੀਂ ਇੱਕ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਸੀ।

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

ਤੁਹਾਨੂੰ ਓਪਰੇਟਰ UI ਵਿੱਚ 3 ਵੇਰੀਏਬਲ ਜੋੜਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

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

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

ਅਜਿਹਾ ਕਿਉਂ ਹੈ? ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਕੋਡ ਵਿੱਚ ਹੈ ਜ਼ਰੂਰੀ GRANT, ਉਹ ਹਮੇਸ਼ਾ ਨਹੀਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਇੱਥੇ 2 ਤਰੀਕੇ ਹਨ: syncPreparedDatabases и syncDatabases. The syncPreparedDatabases - ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਭਾਗ ਵਿੱਚ preparedDatabases ਹੈ ਇੱਕ ਸ਼ਰਤ ਹੈ defaultRoles и defaultUsers ਭੂਮਿਕਾਵਾਂ ਬਣਾਉਣ ਲਈ, ਡਿਫੌਲਟ ਅਧਿਕਾਰ ਲਾਗੂ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਅਸੀਂ ਇੱਕ ਪੈਚ ਤਿਆਰ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਹਾਂ ਤਾਂ ਜੋ ਇਹ ਅਧਿਕਾਰ ਆਪਣੇ ਆਪ ਲਾਗੂ ਹੋ ਜਾਣ।

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

ਕੀ ਹੋਇਆ?

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

ਫੋਰਕ ਵਿੱਚ ਸਵੀਕਾਰ ਕੀਤੇ ਗਏ PR ਦੀ ਸੂਚੀ:

• ਡੌਕਰ ਵਿੱਚ ਆਪਰੇਟਰ ਲਈ ਇੱਕ ਸੁਰੱਖਿਅਤ ਹਲਕਾ ਚਿੱਤਰ ਬਣਾਉਣਾ;
• ਬੈਕਅੱਪ ਨੂੰ ਅਯੋਗ ਕਰਨਾ;
• k8s ਦੇ ਮੌਜੂਦਾ ਸੰਸਕਰਣਾਂ ਲਈ ਸਰੋਤ ਸੰਸਕਰਣਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ;
• ਨੋਡ ਐਫੀਨਿਟੀ ਨੂੰ ਲਾਗੂ ਕਰਨਾ.

ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੋਵੇਗਾ ਜੇਕਰ ਕਮਿਊਨਿਟੀ ਇਹਨਾਂ PRs ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ ਤਾਂ ਜੋ ਉਹ ਆਪਰੇਟਰ (1.6) ਦੇ ਅਗਲੇ ਸੰਸਕਰਣ ਦੇ ਨਾਲ ਅੱਪਸਟ੍ਰੀਮ ਪ੍ਰਾਪਤ ਕਰ ਸਕਣ।

ਬੋਨਸ! ਉਤਪਾਦਨ ਪਰਵਾਸ ਦੀ ਸਫਲਤਾ ਦੀ ਕਹਾਣੀ

ਜੇਕਰ ਤੁਸੀਂ Patroni ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਲਾਈਵ ਉਤਪਾਦਨ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਡਾਊਨਟਾਈਮ ਦੇ ਨਾਲ ਆਪਰੇਟਰ ਨੂੰ ਮਾਈਗ੍ਰੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

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

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

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

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

ਮਾਈਗ੍ਰੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲੀਆਂ ਅਗਲੀਆਂ ਕਮਾਂਡਾਂ ਹੇਠਾਂ ਦਿੱਤੇ ਹੋਸਟ ਨੋਟੇਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਗੀਆਂ:

1. ਮਾਸਟਰ - ਸਰੋਤ ਸਰਵਰ;
2. ਪ੍ਰਤੀਕ੍ਰਿਤੀ 1 - ਪੁਰਾਣੇ ਉਤਪਾਦਨ 'ਤੇ ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ;
3. ਪ੍ਰਤੀਕ੍ਰਿਤੀ 2 - ਨਵੀਂ ਲਾਜ਼ੀਕਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ।

ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੋਜਨਾ

1. ਸਕੀਮਾ ਵਿੱਚ ਸਾਰੀਆਂ ਟੇਬਲਾਂ ਲਈ ਮਾਸਟਰ 'ਤੇ ਇੱਕ ਗਾਹਕੀ ਬਣਾਓ public ਅਧਾਰ dbname:

psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"

2. ਮਾਸਟਰ 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਲਾਟ ਬਣਾਓ:

psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"

3. ਪੁਰਾਣੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਬੰਦ ਕਰੋ:

psql -h replica1 -c "select pg_wal_replay_pause();"

4. ਮਾਸਟਰ ਤੋਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੰਬਰ ਪ੍ਰਾਪਤ ਕਰੋ:

psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"

5. ਪੁਰਾਣੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਤੋਂ ਡੰਪ ਨੂੰ ਹਟਾਓ। ਅਸੀਂ ਇਸਨੂੰ ਕਈ ਥਰਿੱਡਾਂ ਵਿੱਚ ਕਰਾਂਗੇ, ਜੋ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ:

pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname

6. ਨਵੇਂ ਸਰਵਰ 'ਤੇ ਡੰਪ ਅੱਪਲੋਡ ਕਰੋ:

pg_restore -h replica2 -F d -j 8 -d dbname dump/

7. ਡੰਪ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ:

psql -h replica1 -c "select pg_wal_replay_resume();"

7. ਆਓ ਇੱਕ ਨਵੀਂ ਲਾਜ਼ੀਕਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ 'ਤੇ ਗਾਹਕੀ ਬਣਾਈਏ:

psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"

8. ਆਓ ਪ੍ਰਾਪਤ ਕਰੀਏ oid ਗਾਹਕੀ:

psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"

9. ਮੰਨ ਲਓ ਕਿ ਇਹ ਪ੍ਰਾਪਤ ਹੋਇਆ ਸੀ oid=1000. ਆਉ ਗਾਹਕੀ ਲਈ ਲੈਣ-ਦੇਣ ਨੰਬਰ ਲਾਗੂ ਕਰੀਏ:

psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"

10. ਆਉ ਨਕਲ ਸ਼ੁਰੂ ਕਰੀਏ:

psql -h replica2 -d dbname -c "alter subscription oldprod enable;"

11. ਗਾਹਕੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰੋ, ਨਕਲ ਨੂੰ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"

12. ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸ਼ੁਰੂ ਹੋਣ ਅਤੇ ਡੇਟਾਬੇਸ ਸਮਕਾਲੀ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਬਦਲ ਸਕਦੇ ਹੋ।

13. ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਅਯੋਗ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਨੂੰ ਕ੍ਰਮ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਦੱਸਿਆ ਗਿਆ ਹੈ wiki.postgresql.org 'ਤੇ ਲੇਖ ਵਿੱਚ.

ਇਸ ਯੋਜਨਾ ਲਈ ਧੰਨਵਾਦ, ਸਵਿੱਚਓਵਰ ਘੱਟੋ-ਘੱਟ ਦੇਰੀ ਨਾਲ ਹੋਇਆ।

ਸਿੱਟਾ

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

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

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਡਾਟਾਬੇਸ ਅਤੇ ਕੁਬਰਨੇਟਸ (ਸਮੀਖਿਆ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)";
• «Postgres ਮੰਗਲਵਾਰ #5: PostgreSQL ਅਤੇ Kubernetes. CI/CD ਟੈਸਟ ਆਟੋਮੇਸ਼ਨ";
• «K8s ਵਿੱਚ Redis ਆਪਰੇਟਰ ਦੇ ਨਾਲ ਇੱਕ ਕਹਾਣੀ ਅਤੇ ਇਸ ਡੇਟਾਬੇਸ ਤੋਂ ਡੇਟਾ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਉਪਯੋਗਤਾਵਾਂ ਦੀ ਇੱਕ ਛੋਟੀ-ਸਮੀਖਿਆ".

ਸਰੋਤ: www.habr.com