ಅನೇಕ ಜನರು PostgreSQL DBMS ನೊಂದಿಗೆ ಪರಿಚಿತರಾಗಿದ್ದಾರೆ ಮತ್ತು ಇದು ಸಣ್ಣ ಅನುಸ್ಥಾಪನೆಗಳಲ್ಲಿ ಸ್ವತಃ ಸಾಬೀತಾಗಿದೆ. ಆದಾಗ್ಯೂ, ದೊಡ್ಡ ಕಂಪನಿಗಳು ಮತ್ತು ಎಂಟರ್‌ಪ್ರೈಸ್ ಅವಶ್ಯಕತೆಗಳಿಗೆ ಬಂದಾಗಲೂ ಓಪನ್ ಸೋರ್ಸ್‌ನ ಪ್ರವೃತ್ತಿಯು ಹೆಚ್ಚು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಅನ್ನು ಕಾರ್ಪೊರೇಟ್ ಪರಿಸರಕ್ಕೆ ಹೇಗೆ ಸಂಯೋಜಿಸುವುದು ಮತ್ತು ಕಾಮ್ವಾಲ್ಟ್ ಬ್ಯಾಕಪ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಉದಾಹರಣೆಯಾಗಿ ಬಳಸಿಕೊಂಡು ಈ ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ಬ್ಯಾಕಪ್ ಸಿಸ್ಟಮ್ (ಬಿಎಸ್‌ಎಸ್) ರಚಿಸುವ ನಮ್ಮ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದು ಹೇಗೆ ಎಂದು ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ನಿಮಗೆ ತಿಳಿಸುತ್ತೇವೆ.
PostgreSQL ಈಗಾಗಲೇ ತನ್ನ ಮೌಲ್ಯವನ್ನು ಸಾಬೀತುಪಡಿಸಿದೆ - DBMS ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದನ್ನು ಅಲಿಬಾಬಾ ಮತ್ತು ಟ್ರಿಪ್ ಅಡ್ವೈಸರ್‌ನಂತಹ ಫ್ಯಾಶನ್ ಡಿಜಿಟಲ್ ವ್ಯವಹಾರಗಳು ಬಳಸುತ್ತವೆ ಮತ್ತು ಪರವಾನಗಿ ಶುಲ್ಕದ ಕೊರತೆಯು MS SQL ಅಥವಾ Oracle DB ಯಂತಹ ರಾಕ್ಷಸರಿಗೆ ಪ್ರಲೋಭನಗೊಳಿಸುವ ಪರ್ಯಾಯವಾಗಿದೆ. ಆದರೆ ಎಂಟರ್‌ಪ್ರೈಸ್ ಲ್ಯಾಂಡ್‌ಸ್ಕೇಪ್‌ನಲ್ಲಿ ನಾವು PostgreSQL ಕುರಿತು ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸಿದ ತಕ್ಷಣ, ನಾವು ತಕ್ಷಣ ಕಟ್ಟುನಿಟ್ಟಾದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಎದುರಿಸುತ್ತೇವೆ: “ಕಾನ್ಫಿಗರೇಶನ್ ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಬಗ್ಗೆ ಏನು? ವಿಪತ್ತು ಪ್ರತಿರೋಧ? ಸಮಗ್ರ ಮೇಲ್ವಿಚಾರಣೆ ಎಲ್ಲಿದೆ? ಸ್ವಯಂಚಾಲಿತ ಬ್ಯಾಕಪ್‌ಗಳ ಬಗ್ಗೆ ಏನು? ಟೇಪ್ ಲೈಬ್ರರಿಗಳನ್ನು ನೇರವಾಗಿ ಮತ್ತು ಸೆಕೆಂಡರಿ ಸ್ಟೋರೇಜ್‌ನಲ್ಲಿ ಬಳಸುವುದರ ಬಗ್ಗೆ ಏನು?
ಒಂದೆಡೆ, Oracle DB ಅಥವಾ SAP ಡೇಟಾಬೇಸ್ ಬ್ಯಾಕಪ್‌ನಲ್ಲಿ RMAN ನಂತಹ "ವಯಸ್ಕ" DBMS ಗಳಂತಹ ಅಂತರ್ನಿರ್ಮಿತ ಬ್ಯಾಕಪ್ ಪರಿಕರಗಳನ್ನು PostgreSQL ಹೊಂದಿಲ್ಲ. ಮತ್ತೊಂದೆಡೆ, ಕಾರ್ಪೊರೇಟ್ ಬ್ಯಾಕ್ಅಪ್ ಸಿಸ್ಟಮ್‌ಗಳ ಪೂರೈಕೆದಾರರು (Veeam, Veritas, Commvault) ಅವರು PostgreSQL ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತಾರೆ, ವಾಸ್ತವವಾಗಿ ಅವರು ನಿರ್ದಿಷ್ಟ (ಸಾಮಾನ್ಯವಾಗಿ ಸ್ವತಂತ್ರ) ಸಂರಚನೆಯೊಂದಿಗೆ ಮತ್ತು ವಿವಿಧ ನಿರ್ಬಂಧಗಳೊಂದಿಗೆ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ.
PostgreSQL ಗಾಗಿ ವಿಶೇಷವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಬ್ಯಾಕಪ್ ವ್ಯವಸ್ಥೆಗಳು, ಉದಾಹರಣೆಗೆ Barman, Wal-g, pg_probackup, PostgreSQL DBMS ನ ಸಣ್ಣ ಸ್ಥಾಪನೆಗಳಲ್ಲಿ ಅಥವಾ IT ಭೂದೃಶ್ಯದ ಇತರ ಅಂಶಗಳ ಭಾರೀ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳು ಅಗತ್ಯವಿಲ್ಲದಿರುವಲ್ಲಿ ಅತ್ಯಂತ ಜನಪ್ರಿಯವಾಗಿವೆ. ಉದಾಹರಣೆಗೆ, PostgreSQL ಜೊತೆಗೆ, ಮೂಲಸೌಕರ್ಯವು ಭೌತಿಕ ಮತ್ತು ವರ್ಚುವಲ್ ಸರ್ವರ್‌ಗಳು, OpenShift, Oracle, MariaDB, Cassandra, ಇತ್ಯಾದಿಗಳನ್ನು ಒಳಗೊಂಡಿರಬಹುದು. ಇದೆಲ್ಲವನ್ನೂ ಸಾಮಾನ್ಯ ಸಾಧನದೊಂದಿಗೆ ಬ್ಯಾಕ್ಅಪ್ ಮಾಡಲು ಸಲಹೆ ನೀಡಲಾಗುತ್ತದೆ. PostgreSQL ಗಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಪ್ರತ್ಯೇಕ ಪರಿಹಾರವನ್ನು ಸ್ಥಾಪಿಸುವುದು ಕೆಟ್ಟ ಕಲ್ಪನೆ: ಡೇಟಾವನ್ನು ಎಲ್ಲೋ ಡಿಸ್ಕ್ಗೆ ನಕಲಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ಟೇಪ್ಗೆ ತೆಗೆದುಹಾಕಬೇಕಾಗುತ್ತದೆ. ಈ ಡಬಲ್ ಬ್ಯಾಕಪ್ ಬ್ಯಾಕಪ್ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚು ವಿಮರ್ಶಾತ್ಮಕವಾಗಿ, ಚೇತರಿಕೆಯ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
ಎಂಟರ್‌ಪ್ರೈಸ್ ಪರಿಹಾರದಲ್ಲಿ, ಅನುಸ್ಥಾಪನೆಯ ಬ್ಯಾಕ್ಅಪ್ ಒಂದು ಮೀಸಲಾದ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ನೋಡ್‌ಗಳೊಂದಿಗೆ ಸಂಭವಿಸುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, Commvault ಎರಡು-ನೋಡ್ ಕ್ಲಸ್ಟರ್ನೊಂದಿಗೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡಬಹುದು, ಇದರಲ್ಲಿ ಪ್ರಾಥಮಿಕ ಮತ್ತು ದ್ವಿತೀಯಕವನ್ನು ಕೆಲವು ನೋಡ್ಗಳಿಗೆ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ನಿಗದಿಪಡಿಸಲಾಗಿದೆ. ಮತ್ತು ಇದು ಪ್ರಾಥಮಿಕದಿಂದ ಬ್ಯಾಕಪ್ ಮಾಡಲು ಮಾತ್ರ ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ, ಏಕೆಂದರೆ ಸೆಕೆಂಡರಿಯಿಂದ ಬ್ಯಾಕಪ್ ಅದರ ಮಿತಿಗಳನ್ನು ಹೊಂದಿದೆ. DBMS ನ ವಿಶಿಷ್ಟತೆಗಳ ಕಾರಣದಿಂದಾಗಿ, ಸೆಕೆಂಡರಿಯಲ್ಲಿ ಡಂಪ್ ಅನ್ನು ರಚಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಆದ್ದರಿಂದ ಫೈಲ್ ಬ್ಯಾಕ್ಅಪ್ನ ಸಾಧ್ಯತೆ ಮಾತ್ರ ಉಳಿದಿದೆ.
ಅಲಭ್ಯತೆಯ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ದೋಷ-ಸಹಿಷ್ಣು ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸುವಾಗ, "ಲೈವ್" ಕ್ಲಸ್ಟರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರಾಥಮಿಕವು ವಿಭಿನ್ನ ಸರ್ವರ್‌ಗಳ ನಡುವೆ ಕ್ರಮೇಣ ವಲಸೆ ಹೋಗಬಹುದು. ಉದಾಹರಣೆಗೆ, Patroni ಸಾಫ್ಟ್‌ವೇರ್ ಸ್ವತಃ ಯಾದೃಚ್ಛಿಕವಾಗಿ ಆಯ್ಕೆಮಾಡಿದ ಕ್ಲಸ್ಟರ್ ನೋಡ್‌ನಲ್ಲಿ ಪ್ರಾಥಮಿಕವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. IBS ಇದನ್ನು ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಯಾವುದೇ ಮಾರ್ಗವನ್ನು ಹೊಂದಿಲ್ಲ, ಮತ್ತು ಸಂರಚನೆಯು ಬದಲಾದರೆ, ಪ್ರಕ್ರಿಯೆಗಳು ಮುರಿಯುತ್ತವೆ. ಅಂದರೆ, ಬಾಹ್ಯ ನಿಯಂತ್ರಣದ ಪರಿಚಯವು ISR ಅನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಏಕೆಂದರೆ ನಿಯಂತ್ರಣ ಸರ್ವರ್ ಸರಳವಾಗಿ ಎಲ್ಲಿ ಮತ್ತು ಯಾವ ಡೇಟಾವನ್ನು ನಕಲಿಸಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ.
ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ ಬ್ಯಾಕ್ಅಪ್ನ ಅನುಷ್ಠಾನವು ಮತ್ತೊಂದು ಸಮಸ್ಯೆಯಾಗಿದೆ. ಡಂಪ್ ಮೂಲಕ ಇದು ಸಾಧ್ಯ, ಮತ್ತು ಇದು ಸಣ್ಣ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ ದೊಡ್ಡ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ, ಡಂಪ್ ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಬಹಳಷ್ಟು ಸಂಪನ್ಮೂಲಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ನಿದರ್ಶನದ ವೈಫಲ್ಯಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು.
ಫೈಲ್ ಬ್ಯಾಕಪ್ ಪರಿಸ್ಥಿತಿಯನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ, ಆದರೆ ದೊಡ್ಡ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಇದು ನಿಧಾನವಾಗಿರುತ್ತದೆ ಏಕೆಂದರೆ ಇದು ಏಕ-ಥ್ರೆಡ್ ಮೋಡ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಮಾರಾಟಗಾರರು ಹಲವಾರು ಹೆಚ್ಚುವರಿ ನಿರ್ಬಂಧಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಒಂದೋ ನೀವು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಫೈಲ್ ಮತ್ತು ಡಂಪ್ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ ಅಥವಾ ಡಿಡ್ಪ್ಲಿಕೇಶನ್ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಹಲವು ಸಮಸ್ಯೆಗಳಿವೆ, ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಬದಲಿಗೆ ದುಬಾರಿ ಆದರೆ ಸಾಬೀತಾದ DBMS ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಸುಲಭವಾಗಿದೆ.
ಹಿಮ್ಮೆಟ್ಟಲು ಎಲ್ಲಿಯೂ ಇಲ್ಲ! ಮಾಸ್ಕೋ ಅಭಿವರ್ಧಕರು ಹಿಂದೆ ಇದ್ದಾರೆ!
ಆದಾಗ್ಯೂ, ಇತ್ತೀಚೆಗೆ ನಮ್ಮ ತಂಡವು ಕಠಿಣ ಸವಾಲನ್ನು ಎದುರಿಸಿದೆ: AIS OSAGO 2.0 ಅನ್ನು ರಚಿಸುವ ಯೋಜನೆಯಲ್ಲಿ, ನಾವು IT ಮೂಲಸೌಕರ್ಯವನ್ನು ರಚಿಸಿದ್ದೇವೆ, ಅಭಿವರ್ಧಕರು ಹೊಸ ವ್ಯವಸ್ಥೆಗಾಗಿ PostgreSQL ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದರು.
ದೊಡ್ಡ ಸಾಫ್ಟ್‌ವೇರ್ ಡೆವಲಪರ್‌ಗಳಿಗೆ "ಟ್ರೆಂಡಿ" ಓಪನ್ ಸೋರ್ಸ್ ಪರಿಹಾರಗಳನ್ನು ಬಳಸುವುದು ತುಂಬಾ ಸುಲಭ. ಈ DBMS ನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಬೆಂಬಲಿಸಲು Facebook ಸಾಕಷ್ಟು ತಜ್ಞರನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು RSA ಯ ಸಂದರ್ಭದಲ್ಲಿ, "ಎರಡನೇ ದಿನದ" ಎಲ್ಲಾ ಕಾರ್ಯಗಳು ನಮ್ಮ ಭುಜದ ಮೇಲೆ ಬಿದ್ದವು. ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಜೋಡಿಸಲು ಮತ್ತು ಬ್ಯಾಕಪ್ ಅನ್ನು ಹೊಂದಿಸಲು ನಮಗೆ ಅಗತ್ಯವಿದೆ. ಕ್ರಿಯೆಯ ತರ್ಕವು ಈ ಕೆಳಗಿನಂತಿತ್ತು:
- ಕ್ಲಸ್ಟರ್ನ ಪ್ರಾಥಮಿಕ ನೋಡ್‌ನಿಂದ ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಮಾಡಲು SRK ಗೆ ಕಲಿಸಿ. ಇದನ್ನು ಮಾಡಲು, SRK ಅದನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು - ಅಂದರೆ ಒಂದು ಅಥವಾ ಇನ್ನೊಂದು PostgreSQL ಕ್ಲಸ್ಟರ್ ನಿರ್ವಹಣಾ ಪರಿಹಾರದೊಂದಿಗೆ ಏಕೀಕರಣದ ಅಗತ್ಯವಿದೆ. ಆರ್‌ಎಸ್‌ಎ ಪ್ರಕರಣದಲ್ಲಿ, ಪತ್ರೋನಿ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಇದಕ್ಕಾಗಿ ಬಳಸಲಾಗಿದೆ.
- ಡೇಟಾದ ಪರಿಮಾಣ ಮತ್ತು ಮರುಪಡೆಯುವಿಕೆ ಅಗತ್ಯತೆಗಳ ಆಧಾರದ ಮೇಲೆ ಬ್ಯಾಕಪ್ ಪ್ರಕಾರವನ್ನು ನಿರ್ಧರಿಸಿ. ಉದಾಹರಣೆಗೆ, ನೀವು ಪುಟಗಳನ್ನು ಹರಳಾಗಿ ಮರುಸ್ಥಾಪಿಸಬೇಕಾದಾಗ, ಡಂಪ್ ಅನ್ನು ಬಳಸಿ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗಳು ದೊಡ್ಡದಾಗಿದ್ದರೆ ಮತ್ತು ಗ್ರ್ಯಾನ್ಯುಲರ್ ಮರುಸ್ಥಾಪನೆ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ, ಫೈಲ್ ಮಟ್ಟದಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ.
- ಬಹು-ಥ್ರೆಡ್ ಮೋಡ್‌ನಲ್ಲಿ ಬ್ಯಾಕ್ಅಪ್ ನಕಲನ್ನು ರಚಿಸಲು ಪರಿಹಾರಕ್ಕೆ ಬ್ಲಾಕ್ ಬ್ಯಾಕಪ್ ಸಾಧ್ಯತೆಯನ್ನು ಲಗತ್ತಿಸಿ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಹೆಚ್ಚುವರಿ ಘಟಕಗಳ ದೈತ್ಯಾಕಾರದ ಸರಂಜಾಮು ಇಲ್ಲದೆ ಪರಿಣಾಮಕಾರಿ ಮತ್ತು ಸರಳವಾದ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸಲು ನಾವು ಆರಂಭದಲ್ಲಿ ಹೊರಟಿದ್ದೇವೆ. ಕಡಿಮೆ ಊರುಗೋಲು, ಸಿಬ್ಬಂದಿ ಮೇಲೆ ಕಡಿಮೆ ಕೆಲಸದ ಹೊರೆ ಮತ್ತು IBS ವೈಫಲ್ಯದ ಅಪಾಯ ಕಡಿಮೆ. Veeam ಮತ್ತು RMAN ಬಳಸಿದ ವಿಧಾನಗಳನ್ನು ನಾವು ತಕ್ಷಣವೇ ಹೊರಗಿಟ್ಟಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಎರಡು ಪರಿಹಾರಗಳ ಒಂದು ಸೆಟ್ ಈಗಾಗಲೇ ಸಿಸ್ಟಮ್ನ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಬಗ್ಗೆ ಸುಳಿವು ನೀಡುತ್ತದೆ.
ಉದ್ಯಮಕ್ಕೆ ಸ್ವಲ್ಪ ಮ್ಯಾಜಿಕ್
ಆದ್ದರಿಂದ, ನಾವು ಪ್ರತಿ 10 ನೋಡ್‌ಗಳ 3 ಕ್ಲಸ್ಟರ್‌ಗಳಿಗೆ ವಿಶ್ವಾಸಾರ್ಹ ಬ್ಯಾಕಪ್ ಅನ್ನು ಖಾತರಿಪಡಿಸುವ ಅಗತ್ಯವಿದೆ, ಅದೇ ಮೂಲಸೌಕರ್ಯವನ್ನು ಬ್ಯಾಕಪ್ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ. PostgreSQL ವಿಷಯದಲ್ಲಿ ಡೇಟಾ ಕೇಂದ್ರಗಳು ಸಕ್ರಿಯ-ನಿಷ್ಕ್ರಿಯ ತತ್ವದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಒಟ್ಟು ಡೇಟಾಬೇಸ್ ಗಾತ್ರ 50 TB ಆಗಿತ್ತು. ಯಾವುದೇ ಕಾರ್ಪೊರೇಟ್ ಮಟ್ಟದ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯು ಇದನ್ನು ಸುಲಭವಾಗಿ ನಿಭಾಯಿಸುತ್ತದೆ. ಆದರೆ ಮುನ್ನೆಚ್ಚರಿಕೆಯು ಆರಂಭದಲ್ಲಿ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ಗೆ ಬ್ಯಾಕಪ್ ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ಪೂರ್ಣ ಮತ್ತು ಆಳವಾದ ಹೊಂದಾಣಿಕೆಯ ಸುಳಿವು ಇರಲಿಲ್ಲ. ಆದ್ದರಿಂದ, ನಾವು ಆರಂಭದಲ್ಲಿ PostgreSQL ಜೊತೆಗೆ ಗರಿಷ್ಠ ಕಾರ್ಯನಿರ್ವಹಣೆಯನ್ನು ಹೊಂದಿರುವ ಪರಿಹಾರವನ್ನು ಹುಡುಕಬೇಕಾಗಿತ್ತು ಮತ್ತು ಸಿಸ್ಟಮ್ ಅನ್ನು ಪರಿಷ್ಕರಿಸಬೇಕು.
ನಾವು 3 ಆಂತರಿಕ “ಹ್ಯಾಕಥಾನ್‌ಗಳನ್ನು” ನಡೆಸಿದ್ದೇವೆ - ನಾವು ಐವತ್ತಕ್ಕೂ ಹೆಚ್ಚು ಬೆಳವಣಿಗೆಗಳನ್ನು ನೋಡಿದ್ದೇವೆ, ಅವುಗಳನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ, ನಮ್ಮ ಕಲ್ಪನೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ. ಲಭ್ಯವಿರುವ ಆಯ್ಕೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿದ ನಂತರ, ನಾವು Commvault ಅನ್ನು ಆರಿಸಿದ್ದೇವೆ. ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ, ಈ ಉತ್ಪನ್ನವು ಸರಳವಾದ PostgreSQL ಕ್ಲಸ್ಟರ್ ಸ್ಥಾಪನೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಲ್ಲದು, ಮತ್ತು ಅದರ ಮುಕ್ತ ವಾಸ್ತುಶಿಲ್ಪವು ಯಶಸ್ವಿ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಏಕೀಕರಣಕ್ಕಾಗಿ ಭರವಸೆಯನ್ನು ಮೂಡಿಸಿತು (ಅವು ಸಮರ್ಥಿಸಲ್ಪಟ್ಟವು). Commvault PostgreSQL ಲಾಗ್‌ಗಳನ್ನು ಸಹ ಬ್ಯಾಕಪ್ ಮಾಡಬಹುದು. ಉದಾಹರಣೆಗೆ, PostgreSQL ವಿಷಯದಲ್ಲಿ ವೆರಿಟಾಸ್ ನೆಟ್‌ಬ್ಯಾಕಪ್ ಪೂರ್ಣ ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಮಾತ್ರ ಮಾಡಬಹುದು.
ವಾಸ್ತುಶಿಲ್ಪದ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು. CommServ HA ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಕಾಮ್ವಾಲ್ಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಸರ್ವರ್‌ಗಳನ್ನು ಪ್ರತಿ ಎರಡು ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ. ಸಿಸ್ಟಮ್ ಅನ್ನು ಪ್ರತಿಬಿಂಬಿಸಲಾಗಿದೆ, ಒಂದು ಕನ್ಸೋಲ್ ಮೂಲಕ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು HA ದೃಷ್ಟಿಕೋನದಿಂದ ಎಲ್ಲಾ ಎಂಟರ್‌ಪ್ರೈಸ್ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ.
ನಾವು ಪ್ರತಿ ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ಎರಡು ಭೌತಿಕ ಮಾಧ್ಯಮ ಸರ್ವರ್‌ಗಳನ್ನು ಸಹ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ನಾವು ಫೈಬರ್ ಚಾನೆಲ್ ಮೂಲಕ SAN ಮೂಲಕ ಬ್ಯಾಕಪ್‌ಗಳಿಗಾಗಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ಮೀಸಲಾದ ಡಿಸ್ಕ್ ಅರೇಗಳು ಮತ್ತು ಟೇಪ್ ಲೈಬ್ರರಿಗಳನ್ನು ಸಂಪರ್ಕಿಸಿದ್ದೇವೆ. ವಿಸ್ತೃತ ಡಿಡ್ಪ್ಲಿಕೇಶನ್ ಡೇಟಾಬೇಸ್‌ಗಳು ಮಾಧ್ಯಮ ಸರ್ವರ್‌ಗಳ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಸರ್ವರ್ ಅನ್ನು ಪ್ರತಿ CSV ಗೆ ಸಂಪರ್ಕಿಸುವುದರಿಂದ ಯಾವುದೇ ಘಟಕವು ವಿಫಲವಾದಲ್ಲಿ ನಿರಂತರ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಡೇಟಾ ಸೆಂಟರ್‌ಗಳಲ್ಲಿ ಒಂದು ಬಿದ್ದರೂ ಸಹ ಬ್ಯಾಕಪ್ ಅನ್ನು ಮುಂದುವರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.
ಪ್ಯಾಟ್ರೋನಿ ಪ್ರತಿ ಕ್ಲಸ್ಟರ್‌ಗೆ ಪ್ರಾಥಮಿಕ ನೋಡ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಇದು ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಯಾವುದೇ ಉಚಿತ ನೋಡ್ ಆಗಿರಬಹುದು - ಆದರೆ ಹೆಚ್ಚಾಗಿ ಮಾತ್ರ. ಬ್ಯಾಕಪ್‌ನಲ್ಲಿ, ಎಲ್ಲಾ ನೋಡ್‌ಗಳು ಸೆಕೆಂಡರಿ ಆಗಿರುತ್ತವೆ.
ಕಾಮ್ವಾಲ್ಟ್ ಯಾವ ಕ್ಲಸ್ಟರ್ ನೋಡ್ ಪ್ರಾಥಮಿಕವಾಗಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನಾವು ಸಿಸ್ಟಮ್ ಅನ್ನು (ಪರಿಹಾರದ ಮುಕ್ತ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಧನ್ಯವಾದಗಳು) ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಿದ್ದೇವೆ. ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, ಪ್ರಾಥಮಿಕ ನೋಡ್‌ನ ಪ್ರಸ್ತುತ ಸ್ಥಳವನ್ನು Commvault ನಿರ್ವಹಣಾ ಸರ್ವರ್‌ಗೆ ವರದಿ ಮಾಡುವ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ.
ಸಾಮಾನ್ಯವಾಗಿ, ಪ್ರಕ್ರಿಯೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
Patroni ಪ್ರಾಥಮಿಕವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ → Keepalived IP ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಎತ್ತಿಕೊಂಡು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ → ಆಯ್ಕೆಮಾಡಿದ ಕ್ಲಸ್ಟರ್ ನೋಡ್‌ನಲ್ಲಿ Commvault ಏಜೆಂಟ್ ಇದು ಪ್ರಾಥಮಿಕ ಎಂದು ಅಧಿಸೂಚನೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ → Commvault ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹುಸಿ-ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಬ್ಯಾಕಪ್ ಅನ್ನು ಮರುಸಂರಚಿಸುತ್ತದೆ.
ಈ ವಿಧಾನದ ಪ್ರಯೋಜನವೆಂದರೆ ಪರಿಹಾರವು ಸ್ಥಿರತೆ, ಲಾಗ್‌ಗಳ ಸರಿಯಾದತೆ ಅಥವಾ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ನಿದರ್ಶನದ ಚೇತರಿಕೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಇದು ಸುಲಭವಾಗಿ ಸ್ಕೇಲೆಬಲ್ ಆಗಿದೆ, ಏಕೆಂದರೆ ಕಾಮ್ವಾಲ್ಟ್ ಪ್ರಾಥಮಿಕ ಮತ್ತು ಮಾಧ್ಯಮಿಕ ನೋಡ್‌ಗಳನ್ನು ಸರಿಪಡಿಸಲು ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲ. ಪ್ರಾಥಮಿಕ ಎಲ್ಲಿದೆ ಎಂಬುದನ್ನು ಸಿಸ್ಟಮ್ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಕು, ಮತ್ತು ನೋಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಯಾವುದೇ ಮೌಲ್ಯಕ್ಕೆ ಹೆಚ್ಚಿಸಬಹುದು.
ಪರಿಹಾರವು ಆದರ್ಶ ಎಂದು ನಟಿಸುವುದಿಲ್ಲ ಮತ್ತು ತನ್ನದೇ ಆದ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೊಂದಿದೆ. ಕಾಮ್ವಾಲ್ಟ್ ಸಂಪೂರ್ಣ ನಿದರ್ಶನವನ್ನು ಮಾತ್ರ ಬ್ಯಾಕಪ್ ಮಾಡಬಹುದು, ಮತ್ತು ವೈಯಕ್ತಿಕ ಡೇಟಾಬೇಸ್ ಅಲ್ಲ. ಆದ್ದರಿಂದ, ಪ್ರತಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಪ್ರತ್ಯೇಕ ನಿದರ್ಶನವನ್ನು ರಚಿಸಲಾಗಿದೆ. ನೈಜ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ವರ್ಚುವಲ್ ಸ್ಯೂಡೋ-ಕ್ಲೈಂಟ್‌ಗಳಾಗಿ ಸಂಯೋಜಿಸಲಾಗಿದೆ. ಪ್ರತಿ ಕಾಮ್ವಾಲ್ಟ್ ಹುಸಿ-ಕ್ಲೈಂಟ್ ಯುನಿಕ್ಸ್ ಕ್ಲಸ್ಟರ್ ಆಗಿದೆ. ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ಗಾಗಿ ಕಾಮ್ವಾಲ್ಟ್ ಏಜೆಂಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದ ಕ್ಲಸ್ಟರ್ ನೋಡ್‌ಗಳನ್ನು ಅದಕ್ಕೆ ಸೇರಿಸಲಾಗುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಹುಸಿ-ಕ್ಲೈಂಟ್‌ನ ಎಲ್ಲಾ ವರ್ಚುವಲ್ ನೋಡ್‌ಗಳನ್ನು ಒಂದು ನಿದರ್ಶನವಾಗಿ ಬ್ಯಾಕಪ್ ಮಾಡಲಾಗುತ್ತದೆ.
ಪ್ರತಿ ಹುಸಿ-ಕ್ಲೈಂಟ್ ಒಳಗೆ, ಕ್ಲಸ್ಟರ್ನ ಸಕ್ರಿಯ ನೋಡ್ ಅನ್ನು ಸೂಚಿಸಲಾಗುತ್ತದೆ. Commvault ಗಾಗಿ ನಮ್ಮ ಏಕೀಕರಣ ಪರಿಹಾರವು ಇದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಅದರ ಕಾರ್ಯಾಚರಣೆಯ ತತ್ವವು ತುಂಬಾ ಸರಳವಾಗಿದೆ: ಕ್ಲಸ್ಟರ್ ಐಪಿ ಅನ್ನು ನೋಡ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿಸಿದರೆ, ಸ್ಕ್ರಿಪ್ಟ್ ಕಾಮ್ವಾಲ್ಟ್ ಏಜೆಂಟ್ ಬೈನರಿಯಲ್ಲಿ “ಸಕ್ರಿಯ ನೋಡ್” ನಿಯತಾಂಕವನ್ನು ಹೊಂದಿಸುತ್ತದೆ - ವಾಸ್ತವವಾಗಿ, ಸ್ಕ್ರಿಪ್ಟ್ ಮೆಮೊರಿಯ ಅಗತ್ಯವಿರುವ ಭಾಗದಲ್ಲಿ “1” ಅನ್ನು ಹೊಂದಿಸುತ್ತದೆ . ಏಜೆಂಟ್ ಈ ಡೇಟಾವನ್ನು CommServe ಗೆ ರವಾನಿಸುತ್ತದೆ ಮತ್ತು Commvault ಬಯಸಿದ ನೋಡ್‌ನಿಂದ ಬ್ಯಾಕಪ್ ಮಾಡುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸಂರಚನೆಯ ಸರಿಯಾದತೆಯನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ ಮಟ್ಟದಲ್ಲಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ, ಬ್ಯಾಕಪ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವಾಗ ದೋಷಗಳನ್ನು ತಪ್ಪಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, RPO ಮತ್ತು ಬ್ಯಾಕಪ್ ವಿಂಡೋ ಅಗತ್ಯತೆಗಳನ್ನು ಪೂರೈಸುವ, ಬಹು ಥ್ರೆಡ್‌ಗಳಾದ್ಯಂತ ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ದೊಡ್ಡ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡಲಾಗುತ್ತದೆ. ಸಿಸ್ಟಮ್ನಲ್ಲಿನ ಲೋಡ್ ಅತ್ಯಲ್ಪವಾಗಿದೆ: ಪೂರ್ಣ ಪ್ರತಿಗಳು ಆಗಾಗ್ಗೆ ಸಂಭವಿಸುವುದಿಲ್ಲ, ಇತರ ದಿನಗಳಲ್ಲಿ ಮಾತ್ರ ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಕಡಿಮೆ ಲೋಡ್ ಅವಧಿಯಲ್ಲಿ.
ಮೂಲಕ, PostgreSQL ಆರ್ಕೈವ್ ಲಾಗ್‌ಗಳನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡಲು ನಾವು ಪ್ರತ್ಯೇಕ ನೀತಿಗಳನ್ನು ಅನ್ವಯಿಸಿದ್ದೇವೆ - ಅವುಗಳನ್ನು ವಿಭಿನ್ನ ನಿಯಮಗಳ ಪ್ರಕಾರ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ವಿಭಿನ್ನ ವೇಳಾಪಟ್ಟಿಯ ಪ್ರಕಾರ ನಕಲಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಈ ಲಾಗ್‌ಗಳು ಅನನ್ಯ ಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿರುವುದರಿಂದ ಅವುಗಳಿಗೆ ಡಿಡ್ಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿಲ್ಲ.
ಸಂಪೂರ್ಣ IT ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಸ್ಥಿರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಪ್ರತಿಯೊಂದು ಕ್ಲಸ್ಟರ್ ನೋಡ್‌ಗಳಲ್ಲಿ ಪ್ರತ್ಯೇಕ Commvault ಫೈಲ್ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ. ಅವರು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಫೈಲ್‌ಗಳನ್ನು ಬ್ಯಾಕಪ್‌ಗಳಿಂದ ಹೊರಗಿಡುತ್ತಾರೆ ಮತ್ತು OS ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳಿಗೆ ಮಾತ್ರ ಉದ್ದೇಶಿಸಲಾಗಿದೆ. ಡೇಟಾದ ಈ ಭಾಗವು ತನ್ನದೇ ಆದ ನೀತಿ ಮತ್ತು ಶೇಖರಣಾ ಅವಧಿಯನ್ನು ಸಹ ಹೊಂದಿದೆ.
ಪ್ರಸ್ತುತ, IBS ಉತ್ಪಾದಕತೆಯ ಸೇವೆಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ, ಆದರೆ ಪರಿಸ್ಥಿತಿ ಬದಲಾದರೆ, Commvault ಲೋಡ್ ಮಿತಿಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು.
ಇದು ಚೆನ್ನಾಗಿದೆಯೇ? ಒಳ್ಳೆಯದು!
ಆದ್ದರಿಂದ, ನಾವು ಕೇವಲ ಕಾರ್ಯಸಾಧ್ಯವಲ್ಲ, ಆದರೆ PostgreSQL ಕ್ಲಸ್ಟರ್ ಸ್ಥಾಪನೆಗಾಗಿ ಸಂಪೂರ್ಣ ಸ್ವಯಂಚಾಲಿತ ಬ್ಯಾಕಪ್ ಅನ್ನು ಸಹ ಸ್ವೀಕರಿಸಿದ್ದೇವೆ ಮತ್ತು ಇದು ಎಂಟರ್‌ಪ್ರೈಸ್ ಕರೆಗಳಿಗೆ ಎಲ್ಲಾ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ.
1 ಗಂಟೆ ಮತ್ತು 2 ಗಂಟೆಗಳ ಆರ್‌ಪಿಒ ಮತ್ತು ಆರ್‌ಟಿಒ ನಿಯತಾಂಕಗಳನ್ನು ಮಾರ್ಜಿನ್‌ನಿಂದ ಮುಚ್ಚಲಾಗುತ್ತದೆ, ಅಂದರೆ ಸಂಗ್ರಹಿಸಿದ ಡೇಟಾದ ಪರಿಮಾಣದಲ್ಲಿ ಗಮನಾರ್ಹ ಹೆಚ್ಚಳದೊಂದಿಗೆ ಸಿಸ್ಟಮ್ ಅವುಗಳನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಅನೇಕ ಅನುಮಾನಗಳಿಗೆ ವಿರುದ್ಧವಾಗಿ, PostgreSQL ಮತ್ತು ಎಂಟರ್‌ಪ್ರೈಸ್ ಪರಿಸರವು ಸಾಕಷ್ಟು ಹೊಂದಾಣಿಕೆಯಾಗಿದೆ. ಮತ್ತು ಈಗ ನಮ್ಮ ಸ್ವಂತ ಅನುಭವದಿಂದ ಅಂತಹ DBMS ಗಳಿಗೆ ಬ್ಯಾಕ್ಅಪ್ ವಿವಿಧ ರೀತಿಯ ಸಂರಚನೆಗಳಲ್ಲಿ ಸಾಧ್ಯವಿದೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ.
ಸಹಜವಾಗಿ, ಈ ಹಾದಿಯಲ್ಲಿ ನಾವು ಏಳು ಜೋಡಿ ಕಬ್ಬಿಣದ ಬೂಟುಗಳನ್ನು ಧರಿಸಬೇಕಾಗಿತ್ತು, ಹಲವಾರು ತೊಂದರೆಗಳನ್ನು ನಿವಾರಿಸಬೇಕು, ಹಲವಾರು ಕುಂಟೆಗಳ ಮೇಲೆ ಹೆಜ್ಜೆ ಹಾಕಬೇಕು ಮತ್ತು ಹಲವಾರು ತಪ್ಪುಗಳನ್ನು ಸರಿಪಡಿಸಬೇಕು. ಆದರೆ ಈಗ ವಿಧಾನವನ್ನು ಈಗಾಗಲೇ ಪರೀಕ್ಷಿಸಲಾಗಿದೆ ಮತ್ತು ಕಠಿಣ ಉದ್ಯಮ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಸ್ವಾಮ್ಯದ DBMS ಬದಲಿಗೆ ಓಪನ್ ಸೋರ್ಸ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಬಳಸಬಹುದು.
ನೀವು ಕಾರ್ಪೊರೇಟ್ ಪರಿಸರದಲ್ಲಿ PostgreSQL ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದ್ದೀರಾ?
ಲೇಖಕರು:
ಒಲೆಗ್ ಲಾವ್ರೆನೋವ್, ಡೇಟಾ ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಗಳ ವಿನ್ಯಾಸ ಎಂಜಿನಿಯರ್, ಜೆಟ್ ಇನ್ಫೋಸಿಸ್ಟಮ್ಸ್
ಡಿಮಿಟ್ರಿ ಎರಿಕಿನ್, ಜೆಟ್ ಇನ್ಫೋಸಿಸ್ಟಮ್ಸ್‌ನಲ್ಲಿ ಕಂಪ್ಯೂಟರ್ ಸಿಸ್ಟಮ್‌ಗಳ ವಿನ್ಯಾಸ ಎಂಜಿನಿಯರ್
ಮೂಲ: www.habr.com