ਇੱਕ ਕਠੋਰ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਾਤਾਵਰਨ ਵਿੱਚ "ਮੁਫ਼ਤ" PostgreSQL ਨੂੰ ਕਿਵੇਂ ਫਿੱਟ ਕਰਨਾ ਹੈ

ਬਹੁਤ ਸਾਰੇ ਲੋਕ PostgreSQL DBMS ਤੋਂ ਜਾਣੂ ਹਨ, ਅਤੇ ਇਸ ਨੇ ਆਪਣੇ ਆਪ ਨੂੰ ਛੋਟੀਆਂ ਸਥਾਪਨਾਵਾਂ ਵਿੱਚ ਸਾਬਤ ਕੀਤਾ ਹੈ। ਹਾਲਾਂਕਿ, ਓਪਨ ਸੋਰਸ ਵੱਲ ਰੁਝਾਨ ਤੇਜ਼ੀ ਨਾਲ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਹੈ, ਭਾਵੇਂ ਇਹ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਅਤੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਲੋੜਾਂ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ। ਇਸ ਲੇਖ ਵਿੱਚ ਅਸੀਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗੇ ਕਿ ਪੋਸਟਗ੍ਰੇਸ ਨੂੰ ਇੱਕ ਕਾਰਪੋਰੇਟ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਿਵੇਂ ਏਕੀਕ੍ਰਿਤ ਕਰਨਾ ਹੈ ਅਤੇ ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ Commvault ਬੈਕਅੱਪ ਸਿਸਟਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇਸ ਡੇਟਾਬੇਸ ਲਈ ਇੱਕ ਬੈਕਅੱਪ ਸਿਸਟਮ (BSS) ਬਣਾਉਣ ਦੇ ਸਾਡੇ ਅਨੁਭਵ ਨੂੰ ਸਾਂਝਾ ਕਰਨਾ ਹੈ।

PostgreSQL ਨੇ ਪਹਿਲਾਂ ਹੀ ਇਸਦੀ ਕੀਮਤ ਸਾਬਤ ਕਰ ਦਿੱਤੀ ਹੈ - DBMS ਬਹੁਤ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸਦੀ ਵਰਤੋਂ ਅਲੀਬਾਬਾ ਅਤੇ TripAdvisor ਵਰਗੇ ਫੈਸ਼ਨੇਬਲ ਡਿਜੀਟਲ ਕਾਰੋਬਾਰਾਂ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਲਾਇਸੈਂਸਿੰਗ ਫੀਸਾਂ ਦੀ ਘਾਟ ਇਸਨੂੰ MS SQL ਜਾਂ Oracle DB ਵਰਗੇ ਰਾਖਸ਼ਾਂ ਲਈ ਇੱਕ ਲੁਭਾਉਣ ਵਾਲਾ ਵਿਕਲਪ ਬਣਾਉਂਦੀ ਹੈ। ਪਰ ਜਿਵੇਂ ਹੀ ਅਸੀਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਲੈਂਡਸਕੇਪ ਵਿੱਚ PostgreSQL ਬਾਰੇ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਤੁਰੰਤ ਸਖਤ ਲੋੜਾਂ ਵਿੱਚ ਚਲੇ ਜਾਂਦੇ ਹਾਂ: “ਸੰਰਚਨਾ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਬਾਰੇ ਕੀ? ਤਬਾਹੀ ਪ੍ਰਤੀਰੋਧ? ਵਿਆਪਕ ਨਿਗਰਾਨੀ ਕਿੱਥੇ ਹੈ? ਸਵੈਚਲਿਤ ਬੈਕਅੱਪ ਬਾਰੇ ਕੀ? ਟੇਪ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਸਿੱਧੇ ਅਤੇ ਸੈਕੰਡਰੀ ਸਟੋਰੇਜ 'ਤੇ ਵਰਤਣ ਬਾਰੇ ਕੀ?


ਇੱਕ ਪਾਸੇ, PostgreSQL ਵਿੱਚ ਬਿਲਟ-ਇਨ ਬੈਕਅੱਪ ਟੂਲ ਨਹੀਂ ਹਨ, ਜਿਵੇਂ ਕਿ "ਬਾਲਗ" DBMS ਜਿਵੇਂ ਕਿ Oracle DB ਵਿੱਚ RMAN ਜਾਂ SAP ਡਾਟਾਬੇਸ ਬੈਕਅੱਪ। ਦੂਜੇ ਪਾਸੇ, ਕਾਰਪੋਰੇਟ ਬੈਕਅੱਪ ਪ੍ਰਣਾਲੀਆਂ (ਵੀਮ, ਵੇਰੀਟਾਸ, ਕਮਵੌਲਟ) ਦੇ ਸਪਲਾਇਰ ਭਾਵੇਂ ਕਿ ਉਹ PostgreSQL ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਅਸਲ ਵਿੱਚ ਉਹ ਸਿਰਫ਼ ਇੱਕ ਖਾਸ (ਆਮ ਤੌਰ 'ਤੇ ਸਟੈਂਡਅਲੋਨ) ਸੰਰਚਨਾ ਅਤੇ ਵੱਖ-ਵੱਖ ਪਾਬੰਦੀਆਂ ਦੇ ਸੈੱਟ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ।

ਬੈਕਅੱਪ ਸਿਸਟਮ ਖਾਸ ਤੌਰ 'ਤੇ PostgreSQL ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ, ਜਿਵੇਂ ਕਿ Barman, Wal-g, pg_probackup, PostgreSQL DBMS ਦੀਆਂ ਛੋਟੀਆਂ ਸਥਾਪਨਾਵਾਂ ਜਾਂ ਜਿੱਥੇ IT ਲੈਂਡਸਕੇਪ ਦੇ ਹੋਰ ਤੱਤਾਂ ਦੇ ਭਾਰੀ ਬੈਕਅੱਪ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਵਿੱਚ ਬਹੁਤ ਮਸ਼ਹੂਰ ਹਨ। ਉਦਾਹਰਨ ਲਈ, PostgreSQL ਤੋਂ ਇਲਾਵਾ, ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਭੌਤਿਕ ਅਤੇ ਵਰਚੁਅਲ ਸਰਵਰ, OpenShift, Oracle, MariaDB, Cassandra, ਆਦਿ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ। ਇਹ ਸਭ ਨੂੰ ਇੱਕ ਆਮ ਟੂਲ ਨਾਲ ਬੈਕਅੱਪ ਕਰਨ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ. ਸਿਰਫ਼ PostgreSQL ਲਈ ਇੱਕ ਵੱਖਰਾ ਹੱਲ ਸਥਾਪਤ ਕਰਨਾ ਇੱਕ ਬੁਰਾ ਵਿਚਾਰ ਹੈ: ਡੇਟਾ ਨੂੰ ਡਿਸਕ ਵਿੱਚ ਕਿਤੇ ਕਾਪੀ ਕੀਤਾ ਜਾਵੇਗਾ, ਅਤੇ ਫਿਰ ਇਸਨੂੰ ਟੇਪ ਵਿੱਚ ਹਟਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਡਬਲ ਬੈਕਅੱਪ ਬੈਕਅੱਪ ਸਮਾਂ ਵਧਾਉਂਦਾ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ, ਵਧੇਰੇ ਗੰਭੀਰ ਤੌਰ 'ਤੇ, ਰਿਕਵਰੀ ਸਮਾਂ ਵੀ ਵਧਾਉਂਦਾ ਹੈ।

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

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

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

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

ਪਿੱਛੇ ਹਟਣ ਲਈ ਕਿਤੇ ਨਹੀਂ ਹੈ! ਮਾਸਕੋ ਡਿਵੈਲਪਰ ਪਿੱਛੇ ਹਨ!

ਹਾਲਾਂਕਿ, ਹਾਲ ਹੀ ਵਿੱਚ ਸਾਡੀ ਟੀਮ ਨੂੰ ਇੱਕ ਮੁਸ਼ਕਲ ਚੁਣੌਤੀ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ: AIS OSAGO 2.0 ਬਣਾਉਣ ਦੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ, ਜਿੱਥੇ ਅਸੀਂ IT ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬਣਾਇਆ ਹੈ, ਡਿਵੈਲਪਰਾਂ ਨੇ ਨਵੀਂ ਪ੍ਰਣਾਲੀ ਲਈ PostgreSQL ਨੂੰ ਚੁਣਿਆ ਹੈ।

ਵੱਡੇ ਸੌਫਟਵੇਅਰ ਡਿਵੈਲਪਰਾਂ ਲਈ "ਟਰੈਡੀ" ਓਪਨ-ਸੋਰਸ ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਹੁਤ ਸੌਖਾ ਹੈ। Facebook ਕੋਲ ਇਸ DBMS ਦੇ ਸੰਚਾਲਨ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਮਾਹਰ ਹਨ। ਅਤੇ RSA ਦੇ ਮਾਮਲੇ ਵਿੱਚ, "ਦੂਜੇ ਦਿਨ" ਦੇ ਸਾਰੇ ਕੰਮ ਸਾਡੇ ਮੋਢਿਆਂ 'ਤੇ ਆ ਗਏ. ਸਾਨੂੰ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ, ਇੱਕ ਕਲੱਸਟਰ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਅਤੇ, ਬੇਸ਼ਕ, ਬੈਕਅੱਪ ਸਥਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਸੀ। ਕਾਰਵਾਈ ਦਾ ਤਰਕ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਸੀ:

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

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

ਐਂਟਰਪ੍ਰਾਈਜ਼ ਲਈ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਜਾਦੂ

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

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

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

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

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

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

ਆਮ ਤੌਰ 'ਤੇ, ਪ੍ਰਕਿਰਿਆ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

Patroni ਪ੍ਰਾਇਮਰੀ ਚੁਣਦਾ ਹੈ → Keepalived IP ਕਲੱਸਟਰ ਨੂੰ ਚੁੱਕਦਾ ਹੈ ਅਤੇ ਸਕ੍ਰਿਪਟ ਚਲਾਉਂਦਾ ਹੈ → ਚੁਣੇ ਗਏ ਕਲੱਸਟਰ ਨੋਡ 'ਤੇ Commvault ਏਜੰਟ ਨੂੰ ਇੱਕ ਸੂਚਨਾ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ ਕਿ ਇਹ ਪ੍ਰਾਇਮਰੀ ਹੈ → Commvault ਸੂਡੋ-ਕਲਾਇੰਟ ਦੇ ਅੰਦਰ ਬੈਕਅੱਪ ਨੂੰ ਆਟੋਮੈਟਿਕਲੀ ਮੁੜ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ।

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

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

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

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

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

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

ਵਰਤਮਾਨ ਵਿੱਚ, IBS ਉਤਪਾਦਕਤਾ ਸੇਵਾਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਪਰ ਜੇਕਰ ਸਥਿਤੀ ਬਦਲਦੀ ਹੈ, ਤਾਂ Commvault ਲੋਡ ਸੀਮਿਤ ਕਰਨ ਨੂੰ ਸਮਰੱਥ ਕਰ ਸਕਦਾ ਹੈ।

ਕੀ ਇਹ ਚੰਗਾ ਹੈ? ਚੰਗਾ!

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

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

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

ਕੀ ਤੁਸੀਂ ਇੱਕ ਕਾਰਪੋਰੇਟ ਵਾਤਾਵਰਣ ਵਿੱਚ PostgreSQL ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੈ?

ਲੇਖਕ:

ਓਲੇਗ ਲਵਰੇਨੋਵ, ਡੇਟਾ ਸਟੋਰੇਜ ਪ੍ਰਣਾਲੀਆਂ ਦਾ ਡਿਜ਼ਾਈਨ ਇੰਜੀਨੀਅਰ, ਜੈਟ ਇਨਫੋਸਿਸਟਮ

ਦਿਮਿਤਰੀ ਏਰੀਕਿਨ, ਜੈਟ ਇਨਫੋਸਿਸਟਮ ਵਿਖੇ ਕੰਪਿਊਟਰ ਪ੍ਰਣਾਲੀਆਂ ਦਾ ਡਿਜ਼ਾਈਨ ਇੰਜੀਨੀਅਰ

ਸਰੋਤ: www.habr.com