WAL-G ನಿಂದ ಬ್ಯಾಕಪ್‌ಗಳು. 2019 ರಲ್ಲಿ ಏನಿದೆ? ಆಂಡ್ರೆ ಬೊರೊಡಿನ್

ಆಂಡ್ರೆ ಬೊರೊಡಿನ್ ಅವರ 2019 ರ ಆರಂಭದಿಂದ ವರದಿಯ ಪ್ರತಿಲೇಖನವನ್ನು ಓದಲು ನಾನು ನಿಮಗೆ ಸಲಹೆ ನೀಡುತ್ತೇನೆ "WAL-G ಜೊತೆಗೆ ಬ್ಯಾಕಪ್‌ಗಳು. 2019 ರಲ್ಲಿ ಏನಿದೆ?"

ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ನನ್ನ ಹೆಸರು ಆಂಡ್ರೆ ಬೊರೊಡಿನ್. ನಾನು Yandex ನಲ್ಲಿ ಡೆವಲಪರ್ ಆಗಿದ್ದೇನೆ. ನಾನು 2016 ರಿಂದ PostgreSQL ನಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇನೆ, ನಾನು ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ ಮಾತನಾಡಿದ ನಂತರ ಮತ್ತು ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ ಎಂದು ಅವರು ಹೇಳಿದರು - ನೀವು ಮೂಲ ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ನಿರ್ಮಿಸಿ, ಮತ್ತು ಎಲ್ಲವೂ ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತವೆ. ಮತ್ತು ಅಂದಿನಿಂದ ನಾನು ನಿಲ್ಲಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ - ನಾನು ಎಲ್ಲಾ ರೀತಿಯ ವಿಭಿನ್ನ ವಿಷಯಗಳನ್ನು ಬರೆಯುತ್ತೇನೆ.

ನಾನು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ವಿಷಯಗಳಲ್ಲಿ ಒಂದು ಬ್ಯಾಕಪ್ ಸಿಸ್ಟಮ್ ಆಗಿದೆ. WAL-G. ಸಾಮಾನ್ಯವಾಗಿ, Yandex ನಲ್ಲಿ ನಾವು ಬಹಳ ಸಮಯದಿಂದ PostgreSQL ನಲ್ಲಿ ಬ್ಯಾಕಪ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ಬ್ಯಾಕಪ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಹೇಗೆ ತಯಾರಿಸುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು ಆರು ವರದಿಗಳ ಸರಣಿಯನ್ನು ನೀವು ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಕಾಣಬಹುದು. ಮತ್ತು ಪ್ರತಿ ವರ್ಷ ಅವರು ಸ್ವಲ್ಪ ವಿಕಸನಗೊಳ್ಳುತ್ತಾರೆ, ಸ್ವಲ್ಪ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಾರೆ ಮತ್ತು ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹರಾಗುತ್ತಾರೆ.

ಆದರೆ ಇಂದು ವರದಿಯು ನಾವು ಏನು ಮಾಡಿದ್ದೇವೆ ಎಂಬುದರ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ, ಅದು ಎಷ್ಟು ಸರಳವಾಗಿದೆ ಮತ್ತು ಯಾವುದು ಎಂಬುದರ ಬಗ್ಗೆಯೂ ಇದೆ. WAL-G ಕುರಿತು ನನ್ನ ವರದಿಗಳನ್ನು ನಿಮ್ಮಲ್ಲಿ ಎಷ್ಟು ಮಂದಿ ಈಗಾಗಲೇ ವೀಕ್ಷಿಸಿದ್ದೀರಿ? ಕೆಲವು ಜನರು ವೀಕ್ಷಿಸದಿರುವುದು ಒಳ್ಳೆಯದು, ಏಕೆಂದರೆ ನಾನು ಸರಳವಾದ ವಿಷಯದಿಂದ ಪ್ರಾರಂಭಿಸುತ್ತೇನೆ.

ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನೀವು PostgreSQL ಕ್ಲಸ್ಟರ್ ಹೊಂದಿದ್ದರೆ, ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬರೂ ಅವರೊಂದಿಗೆ ಒಂದೆರಡು ಹೊಂದಿದ್ದಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ ಮತ್ತು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಯಾವುದೇ ಬ್ಯಾಕಪ್ ಸಿಸ್ಟಮ್ ಇಲ್ಲ, ನಂತರ ನೀವು ಯಾವುದೇ S3 ಸಂಗ್ರಹಣೆ ಅಥವಾ Google ಕ್ಲೌಡ್ ಹೊಂದಾಣಿಕೆಯ ಸಂಗ್ರಹಣೆಯನ್ನು ಪಡೆಯಬೇಕು.

ಉದಾಹರಣೆಗೆ, ನೀವು ನಮ್ಮ ಸ್ಟ್ಯಾಂಡ್‌ಗೆ ಬರಬಹುದು ಮತ್ತು Yandex ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರೇಜ್‌ಗಾಗಿ ಪ್ರಚಾರ ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಅದು S3 ಹೊಂದಾಣಿಕೆಯಾಗಿದೆ.

ನಂತರ ಬಕೆಟ್ ರಚಿಸಿ. ಇದು ಕೇವಲ ಮಾಹಿತಿಗಾಗಿ ಧಾರಕವಾಗಿದೆ.

ಸೇವಾ ಬಳಕೆದಾರರನ್ನು ರಚಿಸಿ.

ಸೇವಾ ಬಳಕೆದಾರರಿಗಾಗಿ ಪ್ರವೇಶ ಕೀಲಿಯನ್ನು ರಚಿಸಿ: aws-s3-key.

WAL-G ಯ ಇತ್ತೀಚಿನ ಸ್ಥಿರ ಬಿಡುಗಡೆಯನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ.

ನಮ್ಮ ಪೂರ್ವ-ಬಿಡುಗಡೆಗಳು ಬಿಡುಗಡೆಗಳಿಗಿಂತ ಹೇಗೆ ಭಿನ್ನವಾಗಿವೆ? ಬೇಗನೆ ಬಿಡುಗಡೆ ಮಾಡಲು ನನ್ನನ್ನು ಆಗಾಗ್ಗೆ ಕೇಳಲಾಗುತ್ತದೆ. ಮತ್ತು ಸಾಕಷ್ಟು ಸಮಯದವರೆಗೆ ಆವೃತ್ತಿಯಲ್ಲಿ ಯಾವುದೇ ದೋಷವಿಲ್ಲದಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ, ಒಂದು ತಿಂಗಳು, ನಂತರ ನಾನು ಅದನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತೇನೆ. ನವೆಂಬರ್‌ನಿಂದ ಈ ಬಿಡುಗಡೆ ಇಲ್ಲಿದೆ. ಮತ್ತು ಇದರರ್ಥ ಪ್ರತಿ ತಿಂಗಳು ನಾವು ಕೆಲವು ರೀತಿಯ ದೋಷವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ, ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ಣಾಯಕವಲ್ಲದ ಕ್ರಿಯಾತ್ಮಕತೆಯಲ್ಲಿ, ಆದರೆ ನಾವು ಇನ್ನೂ ಬಿಡುಗಡೆಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿಲ್ಲ. ಹಿಂದಿನ ಆವೃತ್ತಿಯು ನವೆಂಬರ್ ಮಾತ್ರ. ಅದರಲ್ಲಿ ನಮಗೆ ತಿಳಿದಿರುವ ಯಾವುದೇ ದೋಷಗಳಿಲ್ಲ, ಅಂದರೆ ಯೋಜನೆಯು ಮುಂದುವರೆದಂತೆ ದೋಷಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ.

ಒಮ್ಮೆ ನೀವು WAL-G ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ನಂತರ, ನೀವು ಸರಳವಾದ "ಬ್ಯಾಕ್‌ಅಪ್ ಪಟ್ಟಿ" ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಬಹುದು, ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳಲ್ಲಿ ಹಾದುಹೋಗಬಹುದು. ಮತ್ತು ಇದು ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರೇಜ್‌ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ ಮತ್ತು ನೀವು ಯಾವ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ನಿಮಗೆ ತಿಳಿಸುತ್ತದೆ. ಮೊದಲಿಗೆ, ಸಹಜವಾಗಿ, ನೀವು ಬ್ಯಾಕ್ಅಪ್ಗಳನ್ನು ಹೊಂದಿರಬಾರದು. ಈ ಸ್ಲೈಡ್‌ನ ಅಂಶವೆಂದರೆ ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದೆ ಎಂದು ತೋರಿಸುವುದು. ಇದು ಕನ್ಸೋಲ್ ಆಜ್ಞೆಯಾಗಿದ್ದು ಅದು ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಉಪಕಮಾಂಡ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ.

ಇದರ ನಂತರ, ನಿಮ್ಮ ಮೊದಲ ಬ್ಯಾಕಪ್ ಅನ್ನು ನೀವು ಮಾಡಬಹುದು. WAL-G ನಲ್ಲಿ "ಬ್ಯಾಕಪ್-ಪುಶ್" ಎಂದು ಹೇಳಿ ಮತ್ತು WAL-G ನಲ್ಲಿ ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನ pgdata ಸ್ಥಳವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ. ಮತ್ತು ಹೆಚ್ಚಾಗಿ, PostgreSQL ನಿಮಗೆ ಹೇಳುತ್ತದೆ, ನೀವು ಈಗಾಗಲೇ ಬ್ಯಾಕಪ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ನೀವು "ಆರ್ಕೈವ್-ಮೋಡ್" ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬೇಕು.

ಇದರರ್ಥ ನೀವು ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಹೋಗಬೇಕು ಮತ್ತು "archive_mode = on" ಅನ್ನು ಆನ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು "archive_command" ಅನ್ನು ಸೇರಿಸಬೇಕು, ಇದು WAL-G ನಲ್ಲಿ ಉಪಕಮಾಂಡ್ ಆಗಿದೆ. ಆದರೆ ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಜನರು ಸಾಮಾನ್ಯವಾಗಿ ಈ ವಿಷಯದ ಮೇಲೆ ಬಾರ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತಾರೆ ಮತ್ತು ಅದನ್ನು WAL-G ಸುತ್ತಲೂ ಸುತ್ತುತ್ತಾರೆ. ದಯವಿಟ್ಟು ಇದನ್ನು ಮಾಡಬೇಡಿ. WAL-G ನಲ್ಲಿ ಕಂಡುಬರುವ ಕಾರ್ಯವನ್ನು ಬಳಸಿ. ನೀವು ಏನನ್ನಾದರೂ ಕಳೆದುಕೊಂಡಿದ್ದರೆ, ಬರೆಯಿರಿ GitHub. WAL-G ಇದು ಆರ್ಕೈವ್_ಕಮಾಂಡ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಏಕೈಕ ಪ್ರೋಗ್ರಾಂ ಎಂದು ಊಹಿಸುತ್ತದೆ.

Yandex ಡೇಟಾಬೇಸ್ ನಿರ್ವಹಣೆಯಲ್ಲಿ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸಲು ನಾವು ಮುಖ್ಯವಾಗಿ WAL-G ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

ಮತ್ತು ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ಮಾಸ್ಟರ್ ಮತ್ತು ಹಲವಾರು ಪ್ರತಿಕೃತಿಗಳ ಟೋಪೋಲಜಿಯಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಇದು ಯಾಂಡೆಕ್ಸ್ ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರೇಜ್ನಲ್ಲಿ ಬ್ಯಾಕ್ಅಪ್ ನಕಲನ್ನು ಮಾಡುತ್ತದೆ.

ಪಾಯಿಂಟ್ ಇನ್ ಟೈಮ್ ರಿಕವರಿ ಬಳಸಿಕೊಂಡು ಕ್ಲಸ್ಟರ್ ನಕಲುಗಳನ್ನು ರಚಿಸುವುದು ಸಾಮಾನ್ಯ ಸನ್ನಿವೇಶಗಳು. ಆದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಬ್ಯಾಕ್ಅಪ್ ಸಿಸ್ಟಮ್ನ ಕಾರ್ಯಕ್ಷಮತೆ ನಮಗೆ ತುಂಬಾ ಮುಖ್ಯವಲ್ಲ. ನಾವು ಬ್ಯಾಕಪ್‌ನಿಂದ ಹೊಸ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಬೇಕಾಗಿದೆ.

ವಿಶಿಷ್ಟವಾಗಿ, ಹೊಸ ನೋಡ್ ಅನ್ನು ಸೇರಿಸುವಾಗ ನಮಗೆ ಬ್ಯಾಕಪ್ ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಗತ್ಯವಿದೆ. ಇದು ಏಕೆ ಮುಖ್ಯ? ಸಾಮಾನ್ಯವಾಗಿ ಜನರು ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೊಸ ನೋಡ್ ಅನ್ನು ಸೇರಿಸುತ್ತಾರೆ ಏಕೆಂದರೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕ್ಲಸ್ಟರ್ ರೀಡ್ ಲೋಡ್ ಅನ್ನು ನಿಭಾಯಿಸುವುದಿಲ್ಲ. ಅವರು ಹೊಸ ಪ್ರತಿಕೃತಿಯನ್ನು ಸೇರಿಸಬೇಕಾಗಿದೆ. ನಾವು pg_basebackup ನಿಂದ ಮಾಸ್ಟರ್‌ಗೆ ಲೋಡ್ ಅನ್ನು ಸೇರಿಸಿದರೆ, ನಂತರ ಮಾಸ್ಟರ್ ಕುಸಿಯಬಹುದು. ಆದ್ದರಿಂದ, ನಾವು ಆರ್ಕೈವ್‌ನಿಂದ ಹೊಸ ನೋಡ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ಅಪ್‌ಲೋಡ್ ಮಾಡಬಹುದು, ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಕನಿಷ್ಠ ಲೋಡ್ ಅನ್ನು ರಚಿಸುವುದು ನಮಗೆ ಬಹಳ ಮುಖ್ಯವಾಗಿತ್ತು.

ಮತ್ತು ಇದೇ ರೀತಿಯ ಮತ್ತೊಂದು ಪರಿಸ್ಥಿತಿ. ಸಂಪರ್ಕ ಕಳೆದುಕೊಂಡಿರುವ ಡೇಟಾ ಕೇಂದ್ರದಿಂದ ಕ್ಲಸ್ಟರ್ ಮಾಸ್ಟರ್ ಅನ್ನು ಬದಲಾಯಿಸಿದ ನಂತರ ಹಳೆಯ ಮಾಸ್ಟರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವ ಅವಶ್ಯಕತೆಯಿದೆ.

• ಪರಿಣಾಮವಾಗಿ, ಕಾಪಿ ಸಿಸ್ಟಮ್‌ಗೆ ಅಗತ್ಯತೆಗಳನ್ನು ರೂಪಿಸುವಾಗ, ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವಾಗ pg_basebackup ನಮಗೆ ಸೂಕ್ತವಲ್ಲ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ.
• ನಮ್ಮ ಡೇಟಾವನ್ನು ಕುಗ್ಗಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ. ಆದರೆ ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಬರುವ ಯಾವುದೇ ಬ್ಯಾಕಪ್ ವ್ಯವಸ್ಥೆಯು ಡೇಟಾ ಕಂಪ್ರೆಷನ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.
• ಕ್ಲೌಡ್‌ನಲ್ಲಿರುವ ಬಳಕೆದಾರರು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಪ್ರೊಸೆಸರ್ ಕೋರ್‌ಗಳನ್ನು ಖರೀದಿಸುವುದರಿಂದ ನಾವು ಎಲ್ಲವನ್ನೂ ಸಮಾನಾಂತರಗೊಳಿಸಲು ಬಯಸುತ್ತೇವೆ. ಆದರೆ ಕೆಲವು ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ನಾವು ಸಮಾನಾಂತರತೆಯನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಕೋರ್ಗಳು ನಿಷ್ಪ್ರಯೋಜಕವಾಗುತ್ತವೆ.
• ನಮಗೆ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅಗತ್ಯವಿದೆ ಏಕೆಂದರೆ ಆಗಾಗ್ಗೆ ಡೇಟಾ ನಮ್ಮದಲ್ಲ ಮತ್ತು ಸ್ಪಷ್ಟ ಪಠ್ಯದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುವುದಿಲ್ಲ. ಅಂದಹಾಗೆ, WAL-G ಗೆ ನಮ್ಮ ಕೊಡುಗೆ ಎನ್‌ಕ್ರಿಪ್ಶನ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಯಿತು. ನಾವು WAL-G ನಲ್ಲಿ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ್ದೇವೆ, ಅದರ ನಂತರ ನಮ್ಮನ್ನು ಕೇಳಲಾಯಿತು: "ಬಹುಶಃ ನಮ್ಮಲ್ಲಿ ಯಾರಾದರೂ ಯೋಜನೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಬಹುದೇ?" ಮತ್ತು ಅಂದಿನಿಂದ ನಾನು WAL-G ಯೊಂದಿಗೆ ಒಂದು ವರ್ಷಕ್ಕೂ ಹೆಚ್ಚು ಕಾಲ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ.
• ನಮಗೆ ಸಂಪನ್ಮೂಲ ಥ್ರೊಟ್ಲಿಂಗ್ ಕೂಡ ಅಗತ್ಯವಿತ್ತು, ಏಕೆಂದರೆ ಕಾಲಾನಂತರದಲ್ಲಿ ಕ್ಲೌಡ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ, ಕೆಲವೊಮ್ಮೆ ಜನರು ರಾತ್ರಿಯಲ್ಲಿ ಪ್ರಮುಖ ದಿನಸಿ ಲೋಡ್ ಅನ್ನು ಹೊಂದಿರುತ್ತಾರೆ ಮತ್ತು ಈ ಹೊರೆಗೆ ಮಧ್ಯಪ್ರವೇಶಿಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಸಂಪನ್ಮೂಲ ಥ್ರೊಟ್ಲಿಂಗ್ ಅನ್ನು ಸೇರಿಸಿದ್ದೇವೆ.
• ಹಾಗೆಯೇ ಪಟ್ಟಿ ಮತ್ತು ನಿರ್ವಹಣೆ.
• ಮತ್ತು ಪರಿಶೀಲನೆ.

ನಾವು ಹಲವಾರು ವಿಭಿನ್ನ ಸಾಧನಗಳನ್ನು ನೋಡಿದ್ದೇವೆ. ಅದೃಷ್ಟವಶಾತ್, PostgreSQL ನಲ್ಲಿ ನಾವು ದೊಡ್ಡ ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ಎಲ್ಲೆಡೆ ನಾವು ಏನನ್ನಾದರೂ ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ, ಕೆಲವು ಒಂದು ಸಣ್ಣ ಕಾರ್ಯ, ಕೆಲವು ಒಂದು ಸಣ್ಣ ವೈಶಿಷ್ಟ್ಯ.

ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿದ ನಂತರ, ನಾವು WAL-G ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೇವೆ ಎಂಬ ತೀರ್ಮಾನಕ್ಕೆ ಬಂದಿದ್ದೇವೆ. ಆಗ ಅದೊಂದು ಹೊಸ ಯೋಜನೆಯಾಗಿತ್ತು. ಬ್ಯಾಕಪ್ ಸಿಸ್ಟಮ್‌ನ ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯದ ಕಡೆಗೆ ಅಭಿವೃದ್ಧಿಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುವುದು ತುಂಬಾ ಸುಲಭ.

ನಾವು ಅನುಸರಿಸುವ ಮುಖ್ಯ ಸಿದ್ಧಾಂತವೆಂದರೆ WAL-G ಬಾಲಲೈಕಾದಂತೆ ಸರಳವಾಗಿರಬೇಕು.

WAL-G 4 ಆಜ್ಞೆಗಳನ್ನು ಹೊಂದಿದೆ. ಇದು:

ವಾಲ್-ಪುಶ್ - ಶಾಫ್ಟ್ ಅನ್ನು ಆರ್ಕೈವ್ ಮಾಡಿ.

ವಾಲ್-ಫೆಚ್ - ಶಾಫ್ಟ್ ಪಡೆಯಿರಿ.

ಬ್ಯಾಕಪ್-ಪುಶ್ - ಬ್ಯಾಕಪ್ ಮಾಡಿ.

ಬ್ಯಾಕಪ್-ಫೆಚ್ - ಬ್ಯಾಕಪ್ ಸಿಸ್ಟಮ್‌ನಿಂದ ಬ್ಯಾಕಪ್ ಪಡೆಯಿರಿ.

ವಾಸ್ತವವಾಗಿ, WAL-G ಈ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳ ನಿರ್ವಹಣೆಯನ್ನು ಸಹ ಹೊಂದಿದೆ, ಅಂದರೆ ಈ ಸಮಯದಲ್ಲಿ ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲದ ಇತಿಹಾಸದಲ್ಲಿ ದಾಖಲೆಗಳು ಮತ್ತು ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುವುದು ಮತ್ತು ಅಳಿಸುವುದು.

ನಮಗೆ ಒಂದು ಪ್ರಮುಖ ಕಾರ್ಯವೆಂದರೆ ಡೆಲ್ಟಾ ಪ್ರತಿಗಳನ್ನು ರಚಿಸುವ ಕಾರ್ಯ.

ಡೆಲ್ಟಾ ಪ್ರತಿಗಳು ಎಂದರೆ ನಾವು ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್‌ನ ಸಂಪೂರ್ಣ ಬ್ಯಾಕ್‌ಅಪ್ ಅನ್ನು ರಚಿಸುವುದಿಲ್ಲ, ಆದರೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಬದಲಾದ ಫೈಲ್‌ಗಳ ಬದಲಾದ ಪುಟಗಳು ಮಾತ್ರ. ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಇದು WAL ಅನ್ನು ಬಳಸಿಕೊಂಡು ಚೇತರಿಸಿಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯಕ್ಕೆ ಹೋಲುತ್ತದೆ ಎಂದು ತೋರುತ್ತದೆ. ಆದರೆ ನಾವು ಸಮಾನಾಂತರವಾಗಿ WAL ಸಿಂಗಲ್-ಥ್ರೆಡ್ ಡೆಲ್ಟಾ ಬ್ಯಾಕಪ್ ಅನ್ನು ಸುತ್ತಿಕೊಳ್ಳಬಹುದು. ಅದರಂತೆ, ನಾವು ಶನಿವಾರದಂದು ಮಾಡಿದ ಮೂಲ ಬ್ಯಾಕಪ್, ಡೆಲ್ಟಾ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ಪ್ರತಿದಿನ ಮತ್ತು ಗುರುವಾರ ನಾವು ವಿಫಲವಾದಾಗ, ನಾವು 4 ಡೆಲ್ಟಾ ಬ್ಯಾಕಪ್‌ಗಳು ಮತ್ತು 10 ಗಂಟೆಗಳ WAL ಅನ್ನು ಸುತ್ತಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ಡೆಲ್ಟಾ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳು ಸಮಾನಾಂತರವಾಗಿ ರೋಲ್ ಆಗುವುದರಿಂದ ಇದು ಸುಮಾರು ಅದೇ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

LSN-ಆಧಾರಿತ ಡೆಲ್ಟಾಗಳು - ಇದರರ್ಥ ಬ್ಯಾಕ್‌ಅಪ್ ರಚಿಸುವಾಗ, ನಾವು ಪ್ರತಿ ಪುಟವನ್ನು ಸಂಯೋಜಿಸಬೇಕು ಮತ್ತು ಅದು ಬದಲಾಗಿದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಹಿಂದಿನ ಬ್ಯಾಕಪ್‌ನ LSN ನೊಂದಿಗೆ ಅದರ LSN ಅನ್ನು ಪರಿಶೀಲಿಸಬೇಕು. ಬದಲಾದ ಡೇಟಾವನ್ನು ಸಂಭಾವ್ಯವಾಗಿ ಒಳಗೊಂಡಿರುವ ಯಾವುದೇ ಪುಟವು ಡೆಲ್ಟಾ ಬ್ಯಾಕಪ್‌ನಲ್ಲಿ ಇರಬೇಕು.

ನಾನು ಹೇಳಿದಂತೆ, ಸಮಾನಾಂತರತೆಗೆ ಸಾಕಷ್ಟು ಗಮನ ನೀಡಲಾಯಿತು.

ಆದರೆ PostgreSQL ನಲ್ಲಿನ ಆರ್ಕೈವ್ API ಸ್ಥಿರವಾಗಿದೆ. PostgreSQL ಒಂದು WAL ಫೈಲ್ ಅನ್ನು ಆರ್ಕೈವ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಮರುಸ್ಥಾಪಿಸುವಾಗ ಒಂದು WAL ಫೈಲ್ ಅನ್ನು ವಿನಂತಿಸುತ್ತದೆ. ಆದರೆ ಡೇಟಾಬೇಸ್ "WAL-FETCH" ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಒಂದು WAL ಫೈಲ್ ಅನ್ನು ವಿನಂತಿಸಿದಾಗ, ನಾವು "WAL-PREFETCH" ಆಜ್ಞೆಯನ್ನು ಕರೆಯುತ್ತೇವೆ, ಇದು ಮುಂದಿನ 8 ಫೈಲ್‌ಗಳನ್ನು ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರ್‌ನಿಂದ ಸಮಾನಾಂತರವಾಗಿ ಡೇಟಾವನ್ನು ತರಲು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ.

ಮತ್ತು ಡೇಟಾಬೇಸ್ ನಮಗೆ ಒಂದು ಫೈಲ್ ಅನ್ನು ಆರ್ಕೈವ್ ಮಾಡಲು ಕೇಳಿದಾಗ, ನಾವು archive_status ಅನ್ನು ನೋಡುತ್ತೇವೆ ಮತ್ತು ಇತರ WAL ಫೈಲ್‌ಗಳು ಇವೆಯೇ ಎಂದು ನೋಡುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಸಮಾನಾಂತರವಾಗಿ WAL ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ. ಇದು ಗಮನಾರ್ಹವಾದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಲಾಭವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಆರ್ಕೈವ್ ಮಾಡದ WAL ಸಂಖ್ಯೆಯಲ್ಲಿನ ಅಂತರವನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಅನೇಕ ಬ್ಯಾಕ್‌ಅಪ್ ಸಿಸ್ಟಮ್ ಡೆವಲಪರ್‌ಗಳು ಇದು ತುಂಬಾ ಅಪಾಯಕಾರಿ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ ಎಂದು ನಂಬುತ್ತಾರೆ ಏಕೆಂದರೆ ನಾವು PostgreSQL API ಅಲ್ಲದ ಕೋಡ್‌ನ ಇಂಟರ್ನಲ್‌ಗಳ ಬಗ್ಗೆ ನಮ್ಮ ಜ್ಞಾನವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತೇವೆ. PostgreSQL ನಮಗೆ archive_status ಫೋಲ್ಡರ್‌ನ ಉಪಸ್ಥಿತಿಯನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ ಮತ್ತು ಸೆಮ್ಯಾಂಟಿಕ್ಸ್, ಅಲ್ಲಿ WAL ಫೈಲ್‌ಗಳಿಗೆ ಸನ್ನದ್ಧತೆಯ ಸಂಕೇತಗಳ ಉಪಸ್ಥಿತಿಯನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಅದೇನೇ ಇದ್ದರೂ, ನಾವು ಮೂಲ ಕೋಡ್ ಅನ್ನು ಅಧ್ಯಯನ ಮಾಡುತ್ತಿದ್ದೇವೆ, ಇದು ಹಾಗೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ ಮತ್ತು ನಾವು ಅದನ್ನು ಬಳಸಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ. ಮತ್ತು PostgreSQL ಅಭಿವೃದ್ಧಿಗೊಳ್ಳುತ್ತಿರುವ ದಿಕ್ಕನ್ನು ನಾವು ನಿಯಂತ್ರಿಸುತ್ತೇವೆ; ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಈ ಕಾರ್ಯವಿಧಾನವು ಮುರಿದುಹೋದರೆ, ನಾವು ಅದನ್ನು ಬಳಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತೇವೆ.

ಅದರ ಶುದ್ಧ ರೂಪದಲ್ಲಿ, ಹಿಂದಿನ ಬ್ಯಾಕಪ್‌ನಿಂದ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಮೋಡ್-ಟೈಮ್ ಬದಲಾಗಿರುವ ಯಾವುದೇ ಕ್ಲಸ್ಟರ್ ಫೈಲ್ ಅನ್ನು LSN-ಆಧಾರಿತ WAL ಡೆಲ್ಟಾ ಓದುವ ಅಗತ್ಯವಿದೆ. ನಾವು ಇದರೊಂದಿಗೆ ದೀರ್ಘಕಾಲ ಬದುಕಿದ್ದೇವೆ, ಸುಮಾರು ಒಂದು ವರ್ಷ. ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ನಾವು WAL ಡೆಲ್ಟಾಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬ ತೀರ್ಮಾನಕ್ಕೆ ಬಂದಿದ್ದೇವೆ.

ಇದರರ್ಥ ನಾವು ಪ್ರತಿ ಬಾರಿ WAL ಅನ್ನು ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಆರ್ಕೈವ್ ಮಾಡಿದಾಗ, ನಾವು ಅದನ್ನು ಸಂಕುಚಿತಗೊಳಿಸುವುದು, ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುವುದು ಮತ್ತು ಅದನ್ನು ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಕಳುಹಿಸುವುದು ಮಾತ್ರವಲ್ಲ, ನಾವು ಅದನ್ನು ಅದೇ ಸಮಯದಲ್ಲಿ ಓದುತ್ತೇವೆ. ನಾವು ಅದರಲ್ಲಿರುವ ದಾಖಲೆಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ ಮತ್ತು ಓದುತ್ತೇವೆ. ಯಾವ ಬ್ಲಾಕ್‌ಗಳು ಬದಲಾಗಿವೆ ಎಂಬುದನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಡೆಲ್ಟಾ ಫೈಲ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ.

ಡೆಲ್ಟಾ ಫೈಲ್ ನಿರ್ದಿಷ್ಟ ಶ್ರೇಣಿಯ WAL ಫೈಲ್‌ಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, WAL ನ ಈ ಶ್ರೇಣಿಯಲ್ಲಿ ಯಾವ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ ಎಂಬ ಮಾಹಿತಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ತದನಂತರ ಈ ಡೆಲ್ಟಾ ಫೈಲ್‌ಗಳನ್ನು ಸಹ ಆರ್ಕೈವ್ ಮಾಡಲಾಗಿದೆ.

ನಾವು ಎಲ್ಲವನ್ನೂ ತ್ವರಿತವಾಗಿ ಸಮಾನಾಂತರಗೊಳಿಸಿದ್ದೇವೆ ಎಂಬ ಅಂಶವನ್ನು ಇಲ್ಲಿ ನಾವು ಎದುರಿಸುತ್ತೇವೆ, ಆದರೆ ನಾವು ಅನುಕ್ರಮ ಇತಿಹಾಸವನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಓದಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ವಿಭಾಗದಲ್ಲಿ ನಾವು ಹಿಂದಿನ WAL ದಾಖಲೆಯ ಅಂತ್ಯವನ್ನು ಎದುರಿಸಬಹುದು, ಅದು ನಮಗೆ ಇನ್ನೂ ಸಂಪರ್ಕಿಸಲು ಏನೂ ಇಲ್ಲ, ಏಕೆಂದರೆ ಸಮಾನಾಂತರ ಓದುವಿಕೆ ನಾವು ಮೊದಲು ಭವಿಷ್ಯವನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಕಾರಣವಾಯಿತು, ಅದು ಇನ್ನೂ ಭೂತಕಾಲವನ್ನು ಹೊಂದಿಲ್ಲ.

ಪರಿಣಾಮವಾಗಿ, ನಾವು _delta_partial ಫೈಲ್‌ಗಳಲ್ಲಿ ಗ್ರಹಿಸಲಾಗದ ತುಣುಕುಗಳನ್ನು ಹಾಕಬೇಕಾಗಿತ್ತು. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಹಿಂದಿನದಕ್ಕೆ ಹಿಂತಿರುಗಿದಾಗ, ನಾವು WAL ದಾಖಲೆಯ ತುಣುಕುಗಳನ್ನು ಒಂದಕ್ಕೆ ಅಂಟು ಮಾಡುತ್ತೇವೆ, ಅದರ ನಂತರ ನಾವು ಅದನ್ನು ಪಾರ್ಸ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅದರಲ್ಲಿ ಏನು ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ.

ನಮ್ಮ ಶಾಫ್ಟ್ ಪಾರ್ಸಿಂಗ್ ಇತಿಹಾಸದಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂದು ನಮಗೆ ಅರ್ಥವಾಗದ ಕನಿಷ್ಠ ಒಂದು ಹಂತವಿದ್ದರೆ, ಅದರ ಪ್ರಕಾರ, ಮುಂದಿನ ಬ್ಯಾಕ್‌ಅಪ್ ಸಮಯದಲ್ಲಿ ನಾವು ಸಾಮಾನ್ಯ LSN ನೊಂದಿಗೆ ಮಾಡಿದಂತೆ ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮತ್ತೆ ಓದಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ. - ಆಧಾರಿತ ಡೆಲ್ಟಾ.

ಪರಿಣಾಮವಾಗಿ, ನಮ್ಮ ಎಲ್ಲಾ ನೋವುಗಳು ನಾವು WAL-G ಪಾರ್ಸಿಂಗ್ ಲೈಬ್ರರಿಯನ್ನು ತೆರೆದ ಮೂಲಕ್ಕೆ ಕಾರಣವಾಯಿತು. ನನಗೆ ತಿಳಿದಿರುವಂತೆ, ಯಾರೂ ಇದನ್ನು ಇನ್ನೂ ಬಳಸುತ್ತಿಲ್ಲ, ಆದರೆ ಯಾರಾದರೂ ಅದನ್ನು ಬರೆಯಲು ಮತ್ತು ಬಳಸಲು ಬಯಸಿದರೆ, ಅದು ಸಾರ್ವಜನಿಕ ಡೊಮೇನ್‌ನಲ್ಲಿದೆ. (ನವೀಕರಿಸಿದ ಲಿಂಕ್ https://github.com/wal-g/wal-g/tree/master/internal/walparser)

ಪರಿಣಾಮವಾಗಿ, ಎಲ್ಲಾ ಮಾಹಿತಿ ಹರಿವುಗಳು ಸಾಕಷ್ಟು ಜಟಿಲವಾಗಿದೆ. ನಮ್ಮ ಮಾಸ್ಟರ್ ಶಾಫ್ಟ್ ಅನ್ನು ಆರ್ಕೈವ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಡೆಲ್ಟಾ ಫೈಲ್‌ಗಳನ್ನು ಆರ್ಕೈವ್ ಮಾಡುತ್ತಾರೆ. ಮತ್ತು ಬ್ಯಾಕಪ್ ನಕಲನ್ನು ಮಾಡುವ ಪ್ರತಿಕೃತಿಯು ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳ ನಡುವೆ ಹಾದುಹೋಗುವ ಸಮಯದಲ್ಲಿ ಡೆಲ್ಟಾ ಫೈಲ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಬೇಕು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಇತಿಹಾಸದ ಭಾಗಗಳನ್ನು ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಸೇರಿಸುವ ಮತ್ತು ಪಾರ್ಸ್ ಮಾಡಬೇಕಾದ ಅಗತ್ಯವಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಸಂಪೂರ್ಣ ಇತಿಹಾಸವು ದೊಡ್ಡ ಭಾಗಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಮತ್ತು ಇದರ ನಂತರವೇ ಪ್ರತಿಕೃತಿಯು ಪೂರ್ಣ ಡೆಲ್ಟಾ ಬ್ಯಾಕಪ್ ಅನ್ನು ಆರ್ಕೈವ್ ಮಾಡಬಹುದು.

ಗ್ರಾಫ್‌ಗಳಲ್ಲಿ ಎಲ್ಲವೂ ಹೆಚ್ಚು ಸರಳವಾಗಿ ಕಾಣುತ್ತದೆ. ಇದು ನಮ್ಮ ನೈಜ ಕ್ಲಸ್ಟರ್‌ಗಳಿಂದ ಡೌನ್‌ಲೋಡ್ ಆಗಿದೆ. ನಾವು ಒಂದೇ ದಿನದಲ್ಲಿ ತಯಾರಿಸಿದ LSN-ಆಧಾರಿತವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು LSN-ಆಧಾರಿತ ಡೆಲ್ಟಾ ಬ್ಯಾಕ್‌ಅಪ್ ಬೆಳಿಗ್ಗೆ ಮೂರರಿಂದ ಬೆಳಗಿನ ಐದು ಗಂಟೆಯವರೆಗೆ ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಪ್ರೊಸೆಸರ್ ಕೋರ್ಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ಇದು ಲೋಡ್ ಆಗಿದೆ. WAL-ಡೆಲ್ಟಾ ನಮಗೆ ಇಲ್ಲಿ ಸುಮಾರು 20 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು. ಅಂದರೆ, ಇದು ಗಮನಾರ್ಹವಾಗಿ ವೇಗವಾಯಿತು, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಹೆಚ್ಚು ತೀವ್ರವಾದ ವಿನಿಮಯವಿತ್ತು.

ಡೇಟಾಬೇಸ್‌ನ ಇತಿಹಾಸದಲ್ಲಿ ಯಾವ ಬ್ಲಾಕ್‌ಗಳು ಬದಲಾಗಿವೆ ಮತ್ತು ಯಾವ ಸಮಯದಲ್ಲಿ ಎಂಬುದರ ಕುರಿತು ನಾವು ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ನಾವು ಮುಂದೆ ಹೋಗಿ ಕ್ರಿಯಾತ್ಮಕತೆಯನ್ನು ಸಂಯೋಜಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ - "pg_prefaulter" ಎಂಬ PostgreSQL ವಿಸ್ತರಣೆ

ಇದರರ್ಥ ಸ್ಟ್ಯಾಂಡ್-ಬೈ ಬೇಸ್ ಪುನಃಸ್ಥಾಪನೆ ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದಾಗ, ಮುಂದಿನ WAL ಫೈಲ್ ಅನ್ನು ತರಲು WAL-G ಗೆ ಹೇಳುತ್ತದೆ. ಮುಂದಿನ ದಿನಗಳಲ್ಲಿ WAL ಮರುಪಡೆಯುವಿಕೆ ಪ್ರಕ್ರಿಯೆಯು ಯಾವ ಡೇಟಾ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ ಮತ್ತು ಈ ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ಓದುವ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಸರಿಸುಮಾರು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. SSD ನಿಯಂತ್ರಕಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೆಚ್ಚಿಸುವ ಸಲುವಾಗಿ ಇದನ್ನು ಮಾಡಲಾಗಿದೆ. ಏಕೆಂದರೆ ಬದಲಾಯಿಸಬೇಕಾದ ಪುಟಕ್ಕೆ WAL ರೋಲ್ ತಲುಪುತ್ತದೆ. ಈ ಪುಟವು ಡಿಸ್ಕ್ನಲ್ಲಿದೆ ಮತ್ತು ಪುಟ ಸಂಗ್ರಹದಲ್ಲಿಲ್ಲ. ಮತ್ತು ಈ ಪುಟವು ಬರಲು ಅವನು ಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಕಾಯುತ್ತಾನೆ. ಆದರೆ ಹತ್ತಿರದ WAL-G, ಇದು ಮುಂದಿನ ಕೆಲವು ನೂರು ಮೆಗಾಬೈಟ್ WAL ನಲ್ಲಿ ನಮಗೆ ಕೆಲವು ಪುಟಗಳು ಬೇಕಾಗುತ್ತವೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಅವುಗಳನ್ನು ಬೆಚ್ಚಗಾಗಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಎಂದು ತಿಳಿದಿದೆ. ಬಹು ಡಿಸ್ಕ್ ಪ್ರವೇಶಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಇದು SSD ಡ್ರೈವ್‌ಗಳಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಅನ್ವಯಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ನಾವು ನಮ್ಮ ಪ್ರಾಂಪ್ಟ್‌ಗಳೊಂದಿಗೆ ಮಾತ್ರ ಅದನ್ನು ಹಸ್ತಕ್ಷೇಪ ಮಾಡುತ್ತೇವೆ.

ಇದು ಈಗ ಕೋಡ್‌ನಲ್ಲಿದೆ.

ನಾವು ಸೇರಿಸಲು ಬಯಸುವ ವೈಶಿಷ್ಟ್ಯಗಳಿವೆ.

WAL-ಡೆಲ್ಟಾ ತುಲನಾತ್ಮಕವಾಗಿ ಕಡಿಮೆ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಈ ಚಿತ್ರ ತೋರಿಸುತ್ತದೆ. ಮತ್ತು ಇದು ದಿನದಲ್ಲಿ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಭವಿಸಿದ ಬದಲಾವಣೆಗಳನ್ನು ಓದುತ್ತಿದೆ. ನಾವು WAL-ಡೆಲ್ಟಾವನ್ನು ರಾತ್ರಿಯಲ್ಲಿ ಮಾತ್ರವಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಇನ್ನು ಮುಂದೆ ಲೋಡ್ನ ಗಮನಾರ್ಹ ಮೂಲವಲ್ಲ. ನಾವು ಪ್ರತಿ ನಿಮಿಷವೂ WAL-ಡೆಲ್ಟಾವನ್ನು ಓದಬಹುದು ಏಕೆಂದರೆ ಅದು ಅಗ್ಗವಾಗಿದೆ. ಒಂದು ನಿಮಿಷದಲ್ಲಿ ನಾವು ಕ್ಲಸ್ಟರ್‌ಗೆ ಸಂಭವಿಸಿದ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಬಹುದು. ಮತ್ತು ಇದನ್ನು "ತ್ವರಿತ WAL-ಡೆಲ್ಟಾ" ಎಂದು ಕರೆಯಬಹುದು.

ನಾವು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಿದಾಗ, ನಾವು ಅನುಕ್ರಮವಾಗಿ ಸುತ್ತಿಕೊಳ್ಳಬೇಕಾದ ಕಥೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆಗೊಳಿಸುತ್ತೇವೆ. ಅಂದರೆ, PostgreSQL ರೋಲ್ ಮಾಡುವ WAL ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡಬೇಕು, ಏಕೆಂದರೆ ಇದು ಗಮನಾರ್ಹ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ಆದರೆ ಇಷ್ಟೇ ಅಲ್ಲ. ಕೆಲವು ಬ್ಲಾಕ್ಗಳನ್ನು ಬ್ಯಾಕಪ್ ಸ್ಥಿರತೆಯ ಹಂತಕ್ಕೆ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿದ್ದರೆ, ನಾವು ಅದನ್ನು ಹಿಂದೆ ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅಂದರೆ, ಈಗ ನಾವು WAL-delta ಫಾರ್ವರ್ಡ್ ಮಾಡುವಿಕೆಯ ಫೈಲ್-ಬೈ-ಫೈಲ್ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಇದರರ್ಥ, ಉದಾಹರಣೆಗೆ, ಮಂಗಳವಾರ ಟೇಬಲ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅಳಿಸಿದರೆ ಅಥವಾ ಕೆಲವು ಫೈಲ್‌ಗಳನ್ನು ಟೇಬಲ್‌ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಅಳಿಸಿದರೆ, ಸೋಮವಾರ ಡೆಲ್ಟಾ ಉರುಳಿದಾಗ ಮತ್ತು ಶನಿವಾರದ pg_basebackup ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಿದಾಗ, ನಾವು ಈ ಡೇಟಾವನ್ನು ಸಹ ರಚಿಸುವುದಿಲ್ಲ.

ನಾವು ಈ ತಂತ್ರಜ್ಞಾನವನ್ನು ಪುಟ ಮಟ್ಟಕ್ಕೆ ವಿಸ್ತರಿಸಲು ಬಯಸುತ್ತೇವೆ. ಅಂದರೆ, ಫೈಲ್‌ನ ಕೆಲವು ಭಾಗವು ಸೋಮವಾರ ಬದಲಾದರೆ, ಆದರೆ ಬುಧವಾರದಂದು ತಿದ್ದಿ ಬರೆಯಲಾಗುತ್ತದೆ, ನಂತರ ಗುರುವಾರ ಒಂದು ಹಂತಕ್ಕೆ ಮರುಸ್ಥಾಪಿಸುವಾಗ, ನಾವು ಪುಟಗಳ ಮೊದಲ ಕೆಲವು ಆವೃತ್ತಿಗಳನ್ನು ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯುವ ಅಗತ್ಯವಿಲ್ಲ.

ಆದರೆ ಇದು ಇನ್ನೂ ನಮ್ಮೊಳಗೆ ಸಕ್ರಿಯವಾಗಿ ಚರ್ಚಿಸಲ್ಪಡುವ ಕಲ್ಪನೆಯಾಗಿದೆ, ಆದರೆ ಇದು ಇನ್ನೂ ಕೋಡ್ ಅನ್ನು ತಲುಪಿಲ್ಲ.

ನಾವು WAL-G ನಲ್ಲಿ ಇನ್ನೂ ಒಂದು ವೈಶಿಷ್ಟ್ಯವನ್ನು ಮಾಡಲು ಬಯಸುತ್ತೇವೆ. ನಾವು ಅದನ್ನು ವಿಸ್ತರಿಸಲು ಬಯಸುತ್ತೇವೆ ಏಕೆಂದರೆ ನಾವು ವಿಭಿನ್ನ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಅಗತ್ಯವಿದೆ ಮತ್ತು ಅದೇ ರೀತಿಯಲ್ಲಿ ಬ್ಯಾಕಪ್ ನಿರ್ವಹಣೆಯನ್ನು ಸಂಪರ್ಕಿಸಲು ಬಯಸುತ್ತೇವೆ. ಆದರೆ ಸಮಸ್ಯೆಯೆಂದರೆ MySQL API ಗಳು ಆಮೂಲಾಗ್ರವಾಗಿ ವಿಭಿನ್ನವಾಗಿವೆ. MySQL ನಲ್ಲಿ, PITR ಭೌತಿಕ WAL ಲಾಗ್ ಅನ್ನು ಆಧರಿಸಿಲ್ಲ, ಆದರೆ ಬಿನ್ಲಾಗ್ ಅನ್ನು ಆಧರಿಸಿದೆ. ಮತ್ತು ನಾವು MySQL ನಲ್ಲಿ ಆರ್ಕೈವಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ, ಅದು ಈ ಬಿನ್‌ಲಾಗ್ ಮುಗಿದಿದೆ ಮತ್ತು ಆರ್ಕೈವ್ ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ಕೆಲವು ಬಾಹ್ಯ ಸಿಸ್ಟಮ್‌ಗೆ ತಿಳಿಸುತ್ತದೆ. ನಾವು ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಕ್ರಾನ್‌ನಲ್ಲಿ ಎಲ್ಲೋ ನಿಂತು ಏನಾದರೂ ಸಿದ್ಧವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಬೇಕೇ?

ಮತ್ತು ಅದೇ ರೀತಿಯಲ್ಲಿ, MySQL ಮರುಸ್ಥಾಪನೆಯ ಸಮಯದಲ್ಲಿ, ನನಗೆ ಅಂತಹ ಮತ್ತು ಅಂತಹ ಫೈಲ್‌ಗಳು ಬೇಕು ಎಂದು ಸಿಸ್ಟಮ್‌ಗೆ ತಿಳಿಸುವ ಯಾವುದೇ ಮರುಸ್ಥಾಪನೆ ಆದೇಶವಿಲ್ಲ. ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ನಿಮಗೆ ಯಾವ ಫೈಲ್‌ಗಳು ಬೇಕು ಎಂದು ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕು. ನಿಮಗೆ ಯಾವ ಫೈಲ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ನೀವೇ ಊಹಿಸಬೇಕು. ಆದರೆ ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಹೇಗಾದರೂ ತಪ್ಪಿಸಬಹುದು. (ಸ್ಪಷ್ಟೀಕರಣ: MySQL ಈಗಾಗಲೇ ಬೆಂಬಲಿತವಾಗಿದೆ)

ವರದಿಯಲ್ಲಿ, WAL-G ನಿಮಗೆ ಸೂಕ್ತವಲ್ಲದ ಸಂದರ್ಭಗಳ ಬಗ್ಗೆಯೂ ಮಾತನಾಡಲು ನಾನು ಬಯಸುತ್ತೇನೆ.

ನೀವು ಸಿಂಕ್ರೊನಸ್ ಪ್ರತಿಕೃತಿಯನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಕೊನೆಯ ವಿಭಾಗವನ್ನು ಸಂರಕ್ಷಿಸಲಾಗಿದೆ ಎಂದು WAL-G ಖಾತರಿ ನೀಡುವುದಿಲ್ಲ. ಮತ್ತು ಆರ್ಕೈವಿಂಗ್ ಇತಿಹಾಸದ ಕೊನೆಯ ಕೆಲವು ಭಾಗಗಳಿಗಿಂತ ಹಿಂದುಳಿದಿದ್ದರೆ, ಅದು ಅಪಾಯವಾಗಿದೆ. ಯಾವುದೇ ಸಿಂಕ್ರೊನಸ್ ಪ್ರತಿಕೃತಿ ಇಲ್ಲದಿದ್ದರೆ, ನಾನು WAL-G ಅನ್ನು ಬಳಸಲು ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ. ಇನ್ನೂ, ಇದು ಮುಖ್ಯವಾಗಿ ಕ್ಲೌಡ್ ಸ್ಥಾಪನೆಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಇದು ಸಿಂಕ್ರೊನಸ್ ಪ್ರತಿಕೃತಿಯೊಂದಿಗೆ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯ ಪರಿಹಾರವನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಇದು ಕೊನೆಯ ಬೈಟ್‌ಗಳ ಸುರಕ್ಷತೆಗೆ ಕಾರಣವಾಗಿದೆ.

ಜನರು ಒಂದೇ ಸಮಯದಲ್ಲಿ WAL-G ಮತ್ತು WAL-E ಎರಡನ್ನೂ ಚಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವುದನ್ನು ನಾನು ಆಗಾಗ್ಗೆ ನೋಡುತ್ತೇನೆ. WAL-G WAL-E ನಿಂದ ಫೈಲ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಬಹುದು ಮತ್ತು WAL-E ನಲ್ಲಿ ಮಾಡಿದ ಬ್ಯಾಕಪ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಬಹುದು ಎಂಬ ಅರ್ಥದಲ್ಲಿ ನಾವು ಹಿಂದುಳಿದ ಹೊಂದಾಣಿಕೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತೇವೆ. ಆದರೆ ಈ ಎರಡೂ ವ್ಯವಸ್ಥೆಗಳು ಸಮಾನಾಂತರ ವಾಲ್-ಪುಶ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ, ಅವು ಪರಸ್ಪರ ಫೈಲ್‌ಗಳನ್ನು ಕದಿಯಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ನಾವು ಅದನ್ನು WAL-G ನಲ್ಲಿ ಸರಿಪಡಿಸಿದರೆ, ಅದು ಇನ್ನೂ WAL-E ನಲ್ಲಿ ಉಳಿಯುತ್ತದೆ. WAL-E ನಲ್ಲಿ, ಇದು ಆರ್ಕೈವ್-ಸ್ಟೇಟಸ್ ಅನ್ನು ನೋಡುತ್ತದೆ, ಮುಗಿದ ಫೈಲ್‌ಗಳನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಆರ್ಕೈವ್ ಮಾಡುತ್ತದೆ, ಆದರೆ ಇತರ ಸಿಸ್ಟಮ್‌ಗಳು ಈ WAL ಫೈಲ್ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ತಿಳಿದಿರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ PostgreSQL ಅದನ್ನು ಎರಡನೇ ಬಾರಿ ಆರ್ಕೈವ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ.

WAL-G ಭಾಗದಲ್ಲಿ ನಾವು ಇಲ್ಲಿ ಏನು ಸರಿಪಡಿಸಲಿದ್ದೇವೆ? ಈ ಫೈಲ್ ಅನ್ನು ಸಮಾನಾಂತರವಾಗಿ ವರ್ಗಾಯಿಸಲಾಗಿದೆ ಎಂದು ನಾವು PostgreSQL ಗೆ ತಿಳಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅದನ್ನು ಆರ್ಕೈವ್ ಮಾಡಲು PostgreSQL ಕೇಳಿದಾಗ, ಈ ಮೋಡ್-ಟೈಮ್ ಮತ್ತು ಈ md5 ನೊಂದಿಗೆ ಅಂತಹ ಫೈಲ್ ಅನ್ನು ಈಗಾಗಲೇ ಆರ್ಕೈವ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ನಾವು ಈಗಾಗಲೇ ತಿಳಿದಿರುತ್ತೇವೆ ಮತ್ತು ನಾವು PostgreSQL ಎಂದು ಹೇಳುತ್ತೇವೆ - ಸರಿ, ಮೂಲಭೂತವಾಗಿ ಏನನ್ನೂ ಮಾಡದೆ ಎಲ್ಲವೂ ಸಿದ್ಧವಾಗಿದೆ.

ಆದರೆ ಈ ಸಮಸ್ಯೆಯನ್ನು WAL-E ಬದಿಯಲ್ಲಿ ಸರಿಪಡಿಸಲು ಅಸಂಭವವಾಗಿದೆ, ಆದ್ದರಿಂದ WAL-G ಮತ್ತು WAL-E ಎರಡರಲ್ಲೂ ಫೈಲ್ ಅನ್ನು ಆರ್ಕೈವ್ ಮಾಡುವ ಆರ್ಕೈವ್ ಆಜ್ಞೆಯನ್ನು ರಚಿಸಲು ಪ್ರಸ್ತುತ ಅಸಾಧ್ಯವಾಗಿದೆ.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಈಗ ನಿಮಗೆ WAL-G ಸೂಕ್ತವಲ್ಲದ ಸಂದರ್ಭಗಳಿವೆ, ಆದರೆ ನಾವು ಅದನ್ನು ಖಂಡಿತವಾಗಿ ಸರಿಪಡಿಸುತ್ತೇವೆ.

ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಪ್ರಸ್ತುತ ಅಂತರ್ನಿರ್ಮಿತ ಬ್ಯಾಕಪ್ ಪರಿಶೀಲನೆಯನ್ನು ಹೊಂದಿಲ್ಲ. ಬ್ಯಾಕಪ್ ಅಥವಾ ಮರುಪ್ರಾಪ್ತಿ ಸಮಯದಲ್ಲಿ ನಾವು ಪರಿಶೀಲನೆಯನ್ನು ಹೊಂದಿಲ್ಲ. ಸಹಜವಾಗಿ, ಇದನ್ನು ಮೋಡದಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ. ಆದರೆ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸುವ ಮೂಲಕ ಪೂರ್ವ-ಪರಿಶೀಲನೆಯ ಮೂಲಕ ಇದನ್ನು ಸರಳವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ನಾನು ಈ ಕಾರ್ಯವನ್ನು ಬಳಕೆದಾರರಿಗೆ ನೀಡಲು ಬಯಸುತ್ತೇನೆ. ಆದರೆ ಪರಿಶೀಲನೆಯ ಮೂಲಕ, WAL-G ನಲ್ಲಿ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ಮತ್ತು ಅದನ್ನು ಪ್ರಾರಂಭಿಸಲು ಮತ್ತು ಹೊಗೆ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ: pg_dumpall to /dev/null ಮತ್ತು amcheck ಇಂಡೆಕ್ಸ್ ಪರಿಶೀಲನೆ.

ಪ್ರಸ್ತುತ WAL-G ನಲ್ಲಿ WAL ನಿಂದ ಒಂದು ಬ್ಯಾಕಪ್ ಅನ್ನು ಮುಂದೂಡಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ. ಅಂದರೆ, ನಾವು ಕೆಲವು ವಿಂಡೋವನ್ನು ಬೆಂಬಲಿಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ಕಳೆದ ಏಳು ದಿನಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು, ಕೊನೆಯ ಹತ್ತು ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು, ಕೊನೆಯ ಮೂರು ಪೂರ್ಣ ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು. ಆಗಾಗ್ಗೆ ಜನರು ಬಂದು ಹೇಳುತ್ತಾರೆ: "ನಮಗೆ ಹೊಸ ವರ್ಷದಂದು ಏನಾಯಿತು ಎಂಬುದರ ಬ್ಯಾಕಪ್ ಅಗತ್ಯವಿದೆ ಮತ್ತು ನಾವು ಅದನ್ನು ಶಾಶ್ವತವಾಗಿ ಇರಿಸಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ." WAL-G ಇನ್ನೂ ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. (ಗಮನಿಸಿ - ಇದನ್ನು ಈಗಾಗಲೇ ಸರಿಪಡಿಸಲಾಗಿದೆ. ಹೆಚ್ಚು ಓದಿ - ಬ್ಯಾಕಪ್-ಮಾರ್ಕ್ ಆಯ್ಕೆಯಲ್ಲಿ https://github.com/wal-g/wal-g/blob/master/PostgreSQL.md)

ಮತ್ತು PITR ಅನ್ನು ಮೌಲ್ಯೀಕರಿಸುವಾಗ ನಾವು ಎಲ್ಲಾ ಶಾಫ್ಟ್ ವಿಭಾಗಗಳಿಗೆ ಪುಟ ಚೆಕ್‌ಸಮ್‌ಗಳು ಮತ್ತು ಸಮಗ್ರತೆಯ ಪರಿಶೀಲನೆಗಳನ್ನು ಹೊಂದಿಲ್ಲ.

ಇದೆಲ್ಲದರಿಂದ ನಾನು ಗೂಗಲ್ ಸಮ್ಮರ್ ಆಫ್ ಕೋಡ್‌ಗಾಗಿ ಯೋಜನೆಯನ್ನು ಒಟ್ಟುಗೂಡಿಸಿದ್ದೇನೆ. Go ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಬರೆಯಲು ಮತ್ತು "G" ಅಕ್ಷರದೊಂದಿಗೆ ಒಂದು ಕಂಪನಿಯಿಂದ ಹಲವಾರು ಸಾವಿರ ಡಾಲರ್‌ಗಳನ್ನು ಪಡೆಯಲು ಬಯಸುವ ಸ್ಮಾರ್ಟ್ ವಿದ್ಯಾರ್ಥಿಗಳು ನಿಮಗೆ ತಿಳಿದಿದ್ದರೆ, ನಂತರ ಅವರಿಗೆ ನಮ್ಮ ಯೋಜನೆಯನ್ನು ಶಿಫಾರಸು ಮಾಡಿ. ನಾನು ಈ ಯೋಜನೆಗೆ ಮಾರ್ಗದರ್ಶಕನಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತೇನೆ, ಅವರು ಅದನ್ನು ಮಾಡಬಹುದು. ವಿದ್ಯಾರ್ಥಿಗಳಿಲ್ಲದಿದ್ದರೆ, ಬೇಸಿಗೆಯಲ್ಲಿ ನಾನೇ ಅದನ್ನು ತೆಗೆದುಕೊಂಡು ಹೋಗುತ್ತೇನೆ.

ಮತ್ತು ನಾವು ಹಲವಾರು ಇತರ ಸಣ್ಣ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಾವು ಕ್ರಮೇಣ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ. ಮತ್ತು ಕೆಲವು ವಿಚಿತ್ರವಾದ ಸಂಗತಿಗಳು ಸಂಭವಿಸುತ್ತವೆ.

ಉದಾಹರಣೆಗೆ, ನೀವು WAL-G ಅನ್ನು ಖಾಲಿ ಬ್ಯಾಕಪ್ ನೀಡಿದರೆ, ಅದು ಸರಳವಾಗಿ ಬೀಳುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಅವನು ಖಾಲಿ ಫೋಲ್ಡರ್ ಅನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡಬೇಕೆಂದು ನೀವು ಅವನಿಗೆ ಹೇಳಿದರೆ. pg_control ಫೈಲ್ ಇರುವುದಿಲ್ಲ. ಮತ್ತು ಅವನು ಏನನ್ನಾದರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ ಎಂದು ಅವನು ಭಾವಿಸುತ್ತಾನೆ. ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ನೀವು ಉಪಕರಣವನ್ನು ಹೇಗೆ ಬಳಸಬೇಕೆಂದು ವಿವರಿಸಲು ಬಳಕೆದಾರರಿಗೆ ಸಾಮಾನ್ಯ ಸಂದೇಶವನ್ನು ಬರೆಯಬೇಕಾಗಿದೆ. ಆದರೆ ಇದು ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನ ವೈಶಿಷ್ಟ್ಯವಲ್ಲ, ಆದರೆ ಉತ್ತಮ, ಅರ್ಥವಾಗುವ ಭಾಷೆಯ ಲಕ್ಷಣವಾಗಿದೆ.

ಆಫ್‌ಲೈನ್ ಬ್ಯಾಕಪ್ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿಲ್ಲ. ಡೇಟಾಬೇಸ್ ಸುಳ್ಳಾಗಿದ್ದರೆ, ನಾವು ಅದನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಆದರೆ ಇಲ್ಲಿ ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದೆ. LSN ಪ್ರಾರಂಭವಾದಾಗ ನಾವು ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ಕರೆಯುತ್ತೇವೆ. ಆಧಾರವಾಗಿರುವ ಬೇಸ್‌ನ LSN ಅನ್ನು ನಿಯಂತ್ರಣ ಫೈಲ್‌ನಿಂದ ಓದಬೇಕು. ಮತ್ತು ಇದು ಅಂತಹ ಅವಾಸ್ತವಿಕ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ. ಅನೇಕ ಬ್ಯಾಕಪ್ ವ್ಯವಸ್ಥೆಗಳು ಆಧಾರವಾಗಿರುವ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡಬಹುದು. ಮತ್ತು ಇದು ಅನುಕೂಲಕರವಾಗಿದೆ.

ಬ್ಯಾಕಪ್ ಸ್ಥಳಾವಕಾಶದ ಕೊರತೆಯನ್ನು ನಾವು ಪ್ರಸ್ತುತ ಸರಿಯಾಗಿ ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಏಕೆಂದರೆ ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಮನೆಯಲ್ಲಿ ದೊಡ್ಡ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ. ಮತ್ತು ಅವರು ಅದರ ಸುತ್ತಲೂ ಹೋಗಲಿಲ್ಲ. ಆದರೆ ಯಾರಾದರೂ ಇದೀಗ Go ನಲ್ಲಿ ಪ್ರೋಗ್ರಾಂ ಮಾಡಲು ಬಯಸಿದರೆ, ಬಕೆಟ್‌ಗೆ ಬಾಹ್ಯಾಕಾಶ ದೋಷಗಳ ನಿರ್ವಹಣೆಯನ್ನು ಸೇರಿಸಿ. ನಾನು ಖಂಡಿತವಾಗಿಯೂ ಪುಲ್ ವಿನಂತಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇನೆ.

ಮತ್ತು ನಮಗೆ ಚಿಂತೆ ಮಾಡುವ ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ವಿಭಿನ್ನ ಸನ್ನಿವೇಶಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಸಾಧ್ಯವಾದಷ್ಟು ಡಾಕರ್ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ನಾವು ಬಯಸುತ್ತೇವೆ. ಇದೀಗ ನಾವು ಮೂಲಭೂತ ಸನ್ನಿವೇಶಗಳನ್ನು ಮಾತ್ರ ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದೇವೆ. ಪ್ರತಿ ಬದ್ಧತೆಯಲ್ಲೂ, ಆದರೆ ನಾವು ಬೆಂಬಲಿಸುವ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಕಮಿಟ್-ಬೈ-ಕಮಿಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ, ಉದಾಹರಣೆಗೆ, ನಾವು PostgreSQL 9.4-9.5 ಗೆ ಸಾಕಷ್ಟು ಬೆಂಬಲವನ್ನು ಹೊಂದಿರುತ್ತೇವೆ. ನಾವು ಅವರನ್ನು ಬೆಂಬಲಿಸುತ್ತೇವೆ ಏಕೆಂದರೆ ಸಮುದಾಯವು PostgreSQL ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಆದರೆ ಎಲ್ಲವೂ ಮುರಿದುಹೋಗಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಕಮಿಟ್-ಬೈ-ಕಮಿಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಇದು ಗಂಭೀರ ಅಪಾಯ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ.

Yandex ಡೇಟಾಬೇಸ್ ನಿರ್ವಹಣೆಯಲ್ಲಿ ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ WAL-G ಚಾಲನೆಯಾಗುತ್ತಿದೆ. ಮತ್ತು ಇದು ಪ್ರತಿದಿನ ನೂರಾರು ಟೆರಾಬೈಟ್ ಡೇಟಾವನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡುತ್ತದೆ.

ನಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ ನಾವು ಬಹಳಷ್ಟು TODO ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನೀವು ಪ್ರೋಗ್ರಾಂ ಮಾಡಲು ಬಯಸಿದರೆ, ಬನ್ನಿ, ನಾವು ಪುಲ್ ವಿನಂತಿಗಳಿಗಾಗಿ ಕಾಯುತ್ತಿದ್ದೇವೆ, ನಾವು ಪ್ರಶ್ನೆಗಳಿಗಾಗಿ ಕಾಯುತ್ತಿದ್ದೇವೆ.

ಪ್ರಶ್ನೆಗಳು

ಶುಭ ಸಂಜೆ! ಧನ್ಯವಾದ! ನೀವು WAL-ಡೆಲ್ಟಾವನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ನೀವು ಬಹುಶಃ ಪೂರ್ಣ-ಪುಟದ ಬರಹಗಳ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತರಾಗಿದ್ದೀರಿ ಎಂಬುದು ನನ್ನ ಊಹೆ. ಮತ್ತು ಹಾಗಿದ್ದಲ್ಲಿ, ನೀವು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿದ್ದೀರಾ? ಸುಂದರವಾದ ಗ್ರಾಫ್ ತೋರಿಸಿದ್ದೀರಿ. FPW ಆಫ್ ಮಾಡಿದರೆ ಎಷ್ಟು ಸುಂದರವಾಗುತ್ತದೆ?

ಪೂರ್ಣ ಪುಟದ ಬರಹಗಳನ್ನು ನಮಗಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ, ನಾವು ಅದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸಿಲ್ಲ. ಅಂದರೆ, ನಾನು, ಡೆವಲಪರ್ ಆಗಿ, ಅದನ್ನು ಆಫ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಲಿಲ್ಲ. ಸಂಶೋಧಿಸಿದ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಬಹುಶಃ ಈ ಸಮಸ್ಯೆಯನ್ನು ಸಂಶೋಧಿಸಿದ್ದಾರೆ. ಆದರೆ ನಮಗೆ FPW ಅಗತ್ಯವಿದೆ. ಬಹುತೇಕ ಯಾರೂ ಅದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದಿಲ್ಲ, ಇಲ್ಲದಿದ್ದರೆ ಪ್ರತಿಕೃತಿಯಿಂದ ಬ್ಯಾಕ್ಅಪ್ ತೆಗೆದುಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯ.

ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ನನಗೆ ಎರಡು ಪ್ರಶ್ನೆಗಳಿವೆ. ಮೊದಲ ಪ್ರಶ್ನೆಯೆಂದರೆ ಟೇಬಲ್‌ಸ್ಪೇಸ್‌ಗಳಿಗೆ ಏನಾಗುತ್ತದೆ?

ಪುಲ್ ವಿನಂತಿಗಾಗಿ ನಾವು ಕಾಯುತ್ತಿದ್ದೇವೆ. ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ಗಳು SSD ಮತ್ತು NMVE ಡಿಸ್ಕ್‌ಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ ಮತ್ತು ನಮಗೆ ನಿಜವಾಗಿಯೂ ಈ ವೈಶಿಷ್ಟ್ಯದ ಅಗತ್ಯವಿಲ್ಲ. ನಾನು ಅದನ್ನು ಚೆನ್ನಾಗಿ ಮಾಡುವುದರಲ್ಲಿ ಗಂಭೀರ ಸಮಯವನ್ನು ಕಳೆಯಲು ಸಿದ್ಧನಿಲ್ಲ. ನಾವು ಇದನ್ನು ಬೆಂಬಲಿಸಬೇಕೆಂದು ನಾನು ಮನಃಪೂರ್ವಕವಾಗಿ ಪ್ರತಿಪಾದಿಸುತ್ತೇನೆ. ಅದನ್ನು ಬೆಂಬಲಿಸಿದವರೂ ಇದ್ದಾರೆ, ಆದರೆ ಅವರಿಗೆ ಸರಿಹೊಂದುವ ರೀತಿಯಲ್ಲಿ ಅದನ್ನು ಬೆಂಬಲಿಸಿದರು. ಅವರು ಫೋರ್ಕ್ ಮಾಡಿದರು, ಆದರೆ ಅವರು ಪುಲ್ ವಿನಂತಿಗಳನ್ನು ಮಾಡುವುದಿಲ್ಲ. (ಆವೃತ್ತಿ 0.2.13 ರಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ)

ಮತ್ತು ಎರಡನೇ ಪ್ರಶ್ನೆ. WAL-G ಇದು ಏಕಾಂಗಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಹೊದಿಕೆಗಳ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ನೀವು ಆರಂಭದಲ್ಲಿಯೇ ಹೇಳಿದ್ದೀರಿ. ನಾನೇ ಹೊದಿಕೆಗಳನ್ನು ಬಳಸುತ್ತೇನೆ. ಅವುಗಳನ್ನು ಏಕೆ ಬಳಸಬಾರದು?

ಇದು ಬಾಲಲೈಕಾದಂತೆ ಸರಳವಾಗಿರಬೇಕು ಎಂದು ನಾವು ಬಯಸುತ್ತೇವೆ. ಇದರರ್ಥ ಬಾಲಲೈಕಾವನ್ನು ಹೊರತುಪಡಿಸಿ ನಿಮಗೆ ಏನೂ ಅಗತ್ಯವಿಲ್ಲ. ವ್ಯವಸ್ಥೆಯು ಸರಳವಾಗಿರಬೇಕು ಎಂದು ನಾವು ಬಯಸುತ್ತೇವೆ. ನೀವು ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ಮಾಡಬೇಕಾದ ಕಾರ್ಯವನ್ನು ನೀವು ಹೊಂದಿದ್ದರೆ, ಬಂದು ನಮಗೆ ತಿಳಿಸಿ - ನಾವು ಅದನ್ನು Go ನಲ್ಲಿ ಮಾಡುತ್ತೇವೆ.

ಶುಭ ಸಂಜೆ! ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! GPG ಡೀಕ್ರಿಪ್ಶನ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು WAL-G ಅನ್ನು ಪಡೆಯಲು ನಮಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ, ಆದರೆ ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ. ಇದು ನಮಗೆ ಕೆಲಸ ಮಾಡದ ವಿಷಯವೇ? ಪರಿಸ್ಥಿತಿ ಹತಾಶವಾಗಿದೆ.

GitHub ನಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ರಚಿಸಿ ಮತ್ತು ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ.

ಅಂದರೆ, ನೀವು ಇದನ್ನು ಎದುರಿಸಲಿಲ್ಲವೇ?

ದೋಷ ವರದಿಯ ವೈಶಿಷ್ಟ್ಯವಿದೆ, ಅದು ಯಾವ ರೀತಿಯ ಫೈಲ್ ಎಂದು WAL-G ಅರ್ಥವಾಗದಿದ್ದಾಗ, ಅದು ಕೇಳುತ್ತದೆ: "ಬಹುಶಃ ಇದು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆಗಿರಬಹುದು?" ಬಹುಶಃ ಸಮಸ್ಯೆಯು ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅಲ್ಲ. ನಾನು ಈ ವಿಷಯದ ಲಾಗಿಂಗ್ ಅನ್ನು ಸುಧಾರಿಸಲು ಬಯಸುತ್ತೇನೆ. ಅವನು ಅದನ್ನು ಅರ್ಥೈಸಿಕೊಳ್ಳಬೇಕು. ಸಾರ್ವಜನಿಕ ಮತ್ತು ಖಾಸಗಿ ಕೀಲಿಗಳನ್ನು ಪಡೆಯುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೇಗೆ ಆಯೋಜಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಡುವುದಿಲ್ಲ ಎಂಬ ಅರ್ಥದಲ್ಲಿ ನಾವು ಪ್ರಸ್ತುತ ಈ ವಿಷಯದ ಕುರಿತು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ. ಏಕೆಂದರೆ ನಾವು ಬಾಹ್ಯ GPG ಎಂದು ಕರೆಯುತ್ತೇವೆ ಇದರಿಂದ ಅದು ನಮಗೆ ಅದರ ಕೀಗಳನ್ನು ನೀಡುತ್ತದೆ. ತದನಂತರ ನಾವು ಈ ಕೀಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ಅವುಗಳನ್ನು ಆಂತರಿಕ GPG ಗೆ ವರ್ಗಾಯಿಸುತ್ತೇವೆ, ಅದು ತೆರೆದ PGP ಆಗಿದೆ, ಇದು WAL-G ಒಳಗೆ ನಮಗೆ ಸಂಕಲಿಸಲಾಗಿದೆ ಮತ್ತು ಅಲ್ಲಿ ನಾವು ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಎಂದು ಕರೆಯುತ್ತೇವೆ. ಈ ನಿಟ್ಟಿನಲ್ಲಿ, ನಾವು ಸಿಸ್ಟಮ್ ಅನ್ನು ಸುಧಾರಿಸಲು ಬಯಸುತ್ತೇವೆ ಮತ್ತು ಲಿಬ್ಸೋಡಿಯಮ್ ಎನ್ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಬೆಂಬಲಿಸಲು ಬಯಸುತ್ತೇವೆ (ಆವೃತ್ತಿ 0.2.15 ರಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ). ಸಹಜವಾಗಿ, ಡಿಕೋಡಿಂಗ್ ಕೆಲಸ ಮಾಡಬೇಕು, ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ - ನಿಮಗೆ ಒಂದೆರಡು ಪದಗಳಿಗಿಂತ ಹೆಚ್ಚಿನ ರೋಗಲಕ್ಷಣದ ಅಗತ್ಯವಿದೆ. ನೀವು ಸ್ಪೀಕರ್‌ನ ಕೊಠಡಿಯಲ್ಲಿ ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಒಟ್ಟುಗೂಡಬಹುದು ಮತ್ತು ಸಿಸ್ಟಮ್ ಅನ್ನು ನೋಡಬಹುದು. (ಬಾಹ್ಯ GPG ಇಲ್ಲದೆ PGP ಎನ್‌ಕ್ರಿಪ್ಶನ್ - v0.2.9)

ನಮಸ್ಕಾರ! ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ನನಗೆ ಎರಡು ಪ್ರಶ್ನೆಗಳಿವೆ. ನಾನು pg_basebackup ಮತ್ತು WAL ಅನ್ನು ಎರಡು ಪೂರೈಕೆದಾರರಿಗೆ ಲಾಗ್ ಇನ್ ಮಾಡಲು ವಿಚಿತ್ರ ಆಸೆಯನ್ನು ಹೊಂದಿದ್ದೇನೆ, ಅಂದರೆ ನಾನು ಒಂದು ಕ್ಲೌಡ್ ಮತ್ತು ಇನ್ನೊಂದನ್ನು ಮಾಡಲು ಬಯಸುತ್ತೇನೆ. ಇದನ್ನು ಮಾಡಲು ಏನಾದರೂ ಮಾರ್ಗವಿದೆಯೇ?

ಇದು ಈಗ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ, ಆದರೆ ಇದು ಆಸಕ್ತಿದಾಯಕ ವಿಚಾರವಾಗಿದೆ.

ನಾನು ಒಬ್ಬ ಪೂರೈಕೆದಾರರನ್ನು ನಂಬುವುದಿಲ್ಲ, ನಾನು ಅದನ್ನು ಇನ್ನೊಂದರಲ್ಲಿ ಹೊಂದಲು ಬಯಸುತ್ತೇನೆ.

ಕಲ್ಪನೆಯು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ. ತಾಂತ್ರಿಕವಾಗಿ, ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕಷ್ಟವೇನಲ್ಲ. ಕಲ್ಪನೆಯು ಕಳೆದುಹೋಗದಂತೆ ತಡೆಯಲು, GitHub ನಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ಮಾಡಲು ನಾನು ನಿಮ್ಮನ್ನು ಕೇಳಬಹುದೇ?

ಹೌದು.

ತದನಂತರ, ವಿದ್ಯಾರ್ಥಿಗಳು Google ಸಮ್ಮರ್ ಆಫ್ ಕೋಡ್‌ಗೆ ಬಂದಾಗ, ನಾವು ಅವರನ್ನು ಯೋಜನೆಗೆ ಸೇರಿಸುತ್ತೇವೆ ಇದರಿಂದ ಹೆಚ್ಚಿನದನ್ನು ಪಡೆಯಲು ಹೆಚ್ಚಿನ ಕೆಲಸವಿದೆ.

ಮತ್ತು ಎರಡನೇ ಪ್ರಶ್ನೆ. GitHub ನಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ. ಇದು ಈಗಾಗಲೇ ಮುಚ್ಚಲ್ಪಟ್ಟಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಪುನಃಸ್ಥಾಪನೆ ಸಮಯದಲ್ಲಿ ಒಂದು ಪ್ಯಾನಿಕ್ ಇದೆ. ಮತ್ತು ಅದನ್ನು ಸೋಲಿಸಲು, ನೀವು ಪ್ರತ್ಯೇಕ ಸಭೆ ಮಾಡಿದ್ದೀರಿ. ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಇದು ಸರಿ. ಮತ್ತು ಒಂದು ಥ್ರೆಡ್ನಲ್ಲಿ ವೇರಿಯಬಲ್ ಪರಿಸರವನ್ನು ಮಾಡಲು ಒಂದು ಆಯ್ಕೆ ಇದೆ. ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಇದು ತುಂಬಾ ನಿಧಾನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮತ್ತು ನಾವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ಇನ್ನೂ ಸರಿಪಡಿಸಲಾಗಿಲ್ಲ.

ಸಮಸ್ಯೆಯೆಂದರೆ ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಸಂಗ್ರಹಣೆಯು (CEPH) ನಾವು ಹೆಚ್ಚಿನ ಹೊಂದಾಣಿಕೆಯೊಂದಿಗೆ ಸಂಪರ್ಕಕ್ಕೆ ಬಂದಾಗ ಅದನ್ನು ಮರುಹೊಂದಿಸುತ್ತದೆ. ಇದರ ಬಗ್ಗೆ ಏನು ಮಾಡಬಹುದು? ಮರುಪ್ರಯತ್ನದ ತರ್ಕವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ. ನಾವು ಫೈಲ್ ಅನ್ನು ಮತ್ತೆ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ. ಒಂದು ಪಾಸ್‌ನಲ್ಲಿ, ನಾವು ಡೌನ್‌ಲೋಡ್ ಮಾಡದ ಹಲವಾರು ಫೈಲ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಲಾಗ್ ಇನ್ ಮಾಡದ ಎಲ್ಲರಿಗೂ ನಾವು ಎರಡನೆಯದನ್ನು ಮಾಡುತ್ತೇವೆ. ಮತ್ತು ಪ್ರತಿ ಪುನರಾವರ್ತನೆಗೆ ಕನಿಷ್ಠ ಒಂದು ಫೈಲ್ ಅನ್ನು ಲೋಡ್ ಮಾಡುವವರೆಗೆ, ನಾವು ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ ಮತ್ತು ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ ಮತ್ತು ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ. ನಾವು ಮರುಪ್ರಯತ್ನದ ತರ್ಕವನ್ನು ಸುಧಾರಿಸಿದ್ದೇವೆ - ಘಾತೀಯ ಬ್ಯಾಕ್‌ಆಫ್. ಆದರೆ ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಯ ಬದಿಯಲ್ಲಿ ಸಂಪರ್ಕವು ಸರಳವಾಗಿ ಮುರಿಯುತ್ತದೆ ಎಂಬ ಅಂಶದೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕೆಂದು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಅಂದರೆ, ನಾವು ಒಂದು ಸ್ಟ್ರೀಮ್‌ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಿದಾಗ, ಅದು ಈ ಸಂಪರ್ಕಗಳನ್ನು ಮುರಿಯುವುದಿಲ್ಲ. ನಾವು ಇಲ್ಲಿ ಏನು ಸುಧಾರಿಸಬಹುದು? ನಾವು ನೆಟ್‌ವರ್ಕ್ ಥ್ರೊಟ್ಲಿಂಗ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದು ಕಳುಹಿಸುವ ಬೈಟ್‌ಗಳ ಸಂಖ್ಯೆಯಿಂದ ನಾವು ಪ್ರತಿ ಸಂಪರ್ಕವನ್ನು ಮಿತಿಗೊಳಿಸಬಹುದು. ಇಲ್ಲದಿದ್ದರೆ, ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರೇಜ್ ನಮಗೆ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಅಥವಾ ಸಮಾನಾಂತರವಾಗಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ನಮಗೆ ಅನುಮತಿಸುವುದಿಲ್ಲ ಎಂಬ ಅಂಶವನ್ನು ಹೇಗೆ ಎದುರಿಸಬೇಕೆಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ.

SLA ಇಲ್ಲವೇ? ಅವರು ತಮ್ಮನ್ನು ತಾವು ಹಿಂಸಿಸುವುದನ್ನು ಹೇಗೆ ಅನುಮತಿಸುತ್ತಾರೆ ಎಂದು ಅವರಿಗೆ ಬರೆಯಲಾಗಿಲ್ಲವೇ?

ಈ ಪ್ರಶ್ನೆಯೊಂದಿಗೆ ಬರುವ ಜನರು ಸಾಮಾನ್ಯವಾಗಿ ತಮ್ಮದೇ ಆದ ವಾಲ್ಟ್ ಅನ್ನು ಹೊಂದಿರುತ್ತಾರೆ. ಅಂದರೆ, ಅಮೆಜಾನ್ ಅಥವಾ ಗೂಗಲ್ ಕ್ಲೌಡ್ ಅಥವಾ ಯಾಂಡೆಕ್ಸ್ ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರೇಜ್‌ನಿಂದ ಯಾರೂ ಬರುವುದಿಲ್ಲ.

ಬಹುಶಃ ಪ್ರಶ್ನೆ ಇನ್ನು ಮುಂದೆ ನಿಮಗೆ ಇಲ್ಲವೇ?

ಈ ಸಂದರ್ಭದಲ್ಲಿ ಇಲ್ಲಿ ಪ್ರಶ್ನೆ ಯಾರಿಗೆ ಮುಖ್ಯವಲ್ಲ. ಇದನ್ನು ಹೇಗೆ ಎದುರಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಯಾವುದೇ ವಿಚಾರಗಳಿದ್ದರೆ, ಅದನ್ನು WAL-G ನಲ್ಲಿ ಮಾಡೋಣ. ಆದರೆ ಇಲ್ಲಿಯವರೆಗೆ ಇದನ್ನು ಹೇಗೆ ಎದುರಿಸಬೇಕೆಂದು ನನಗೆ ಯಾವುದೇ ಉತ್ತಮ ಆಲೋಚನೆಗಳಿಲ್ಲ. ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ವಿಭಿನ್ನವಾಗಿ ಪಟ್ಟಿ ಮಾಡುವುದನ್ನು ಬೆಂಬಲಿಸುವ ಕೆಲವು ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರೇಜ್‌ಗಳಿವೆ. ವಸ್ತುಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಲು ನೀವು ಅವರನ್ನು ಕೇಳುತ್ತೀರಿ ಮತ್ತು ಅವರು ಅಲ್ಲಿ ಫೋಲ್ಡರ್ ಅನ್ನು ಸೇರಿಸುತ್ತಾರೆ. WAL-G ಇದಕ್ಕೆ ಹೆದರುತ್ತಾನೆ - ಇಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ವಿಷಯವಿದೆ ಅದು ಫೈಲ್ ಅಲ್ಲ, ನಾನು ಅದನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಅಂದರೆ ಬ್ಯಾಕಪ್ ಅನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲಾಗಿಲ್ಲ. ಅಂದರೆ, ವಾಸ್ತವವಾಗಿ, ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ಮರುಸ್ಥಾಪಿಸಲಾದ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಆದರೆ ಅದು ನಿಮಗೆ ತಪ್ಪಾದ ಸ್ಥಿತಿಯನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರೇಜ್ ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಥವಾಗದ ಕೆಲವು ವಿಚಿತ್ರ ಮಾಹಿತಿಯನ್ನು ಹಿಂತಿರುಗಿಸಿದೆ.

ಇದು ಮೇಲ್ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ನಡೆಯುವ ಒಂದು ವಿಷಯ.

ನೀವು ಪುನರುತ್ಪಾದನೆಯನ್ನು ನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಾದರೆ ...

ಇದು ಸತತವಾಗಿ ಪುನರುತ್ಪಾದಿಸಲ್ಪಟ್ಟಿದೆ ...

ಪುನರುತ್ಪಾದನೆ ಇದ್ದರೆ, ನಾವು ಮರುಪ್ರಯತ್ನ ತಂತ್ರಗಳನ್ನು ಪ್ರಯೋಗಿಸುತ್ತೇವೆ ಮತ್ತು ಮರುಪ್ರಯತ್ನಿಸುವುದು ಮತ್ತು ಮೇಘವು ನಮ್ಮಿಂದ ಏನನ್ನು ಬಯಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಹೇಗೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಬಹುಶಃ ಇದು ಮೂರು ಸಂಪರ್ಕಗಳಲ್ಲಿ ನಮಗೆ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ ಮತ್ತು ಸಂಪರ್ಕವನ್ನು ಮುರಿಯುವುದಿಲ್ಲ, ನಂತರ ನಾವು ಎಚ್ಚರಿಕೆಯಿಂದ ಮೂರು ತಲುಪುತ್ತೇವೆ. ಏಕೆಂದರೆ ಈಗ ನಾವು ಸಂಪರ್ಕವನ್ನು ತ್ವರಿತವಾಗಿ ಬಿಡುತ್ತೇವೆ, ಅಂದರೆ ನಾವು 16 ಥ್ರೆಡ್‌ಗಳೊಂದಿಗೆ ಚೇತರಿಕೆ ಪ್ರಾರಂಭಿಸಿದರೆ, ಮೊದಲ ಮರುಪ್ರಯತ್ನದ ನಂತರ 8 ಥ್ರೆಡ್‌ಗಳು, 4 ಥ್ರೆಡ್‌ಗಳು, 2 ಥ್ರೆಡ್‌ಗಳು ಮತ್ತು ಒಂದು ಇರುತ್ತದೆ. ತದನಂತರ ಅದು ಫೈಲ್ ಅನ್ನು ಒಂದು ಸ್ಟ್ರೀಮ್‌ಗೆ ಎಳೆಯುತ್ತದೆ. ಪಂಪ್ ಮಾಡಲು 7,5 ಎಳೆಗಳಂತಹ ಕೆಲವು ಮ್ಯಾಜಿಕ್ ಮೌಲ್ಯಗಳು ಉತ್ತಮವಾಗಿದ್ದರೆ, ನಾವು ಅವುಗಳ ಮೇಲೆ ವಾಸಿಸುತ್ತೇವೆ ಮತ್ತು ಇನ್ನೊಂದು 7,5 ಎಳೆಗಳನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಇಲ್ಲಿದೆ ಒಂದು ಉಪಾಯ.

ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! WAL-G ಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸಂಪೂರ್ಣ ಕೆಲಸದ ಹರಿವು ಹೇಗಿರುತ್ತದೆ? ಉದಾಹರಣೆಗೆ, ಸ್ಟುಪಿಡ್ ಸಂದರ್ಭದಲ್ಲಿ ಪುಟಗಳಲ್ಲಿ ಯಾವುದೇ ಡೆಲ್ಟಾ ಇಲ್ಲದಿದ್ದಾಗ. ಮತ್ತು ನಾವು ಆರಂಭಿಕ ಬ್ಯಾಕ್ಅಪ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ತೆಗೆದುಹಾಕುತ್ತೇವೆ, ನಂತರ ನಾವು ಮುಖದಲ್ಲಿ ನೀಲಿ ಬಣ್ಣಕ್ಕೆ ಬರುವವರೆಗೆ ಶಾಫ್ಟ್ ಅನ್ನು ಆರ್ಕೈವ್ ಮಾಡುತ್ತೇವೆ. ಇಲ್ಲಿ, ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಸ್ಥಗಿತವಿದೆ. ಕೆಲವು ಹಂತದಲ್ಲಿ ನೀವು ಪುಟಗಳ ಡೆಲ್ಟಾ ಬ್ಯಾಕಪ್ ಮಾಡಬೇಕಾಗಿದೆ, ಅಂದರೆ ಕೆಲವು ಬಾಹ್ಯ ಪ್ರಕ್ರಿಯೆಯು ಇದನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿದೆ ಅಥವಾ ಇದು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ?

ಡೆಲ್ಟಾ ಬ್ಯಾಕಪ್ API ತುಂಬಾ ಸರಳವಾಗಿದೆ. ಅಲ್ಲಿ ಒಂದು ಸಂಖ್ಯೆ ಇದೆ - ಗರಿಷ್ಠ ಡೆಲ್ಟಾ ಹಂತಗಳು, ಅದನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ. ಇದು ಶೂನ್ಯಕ್ಕೆ ಡೀಫಾಲ್ಟ್ ಆಗುತ್ತದೆ. ಇದರರ್ಥ ನೀವು ಪ್ರತಿ ಬಾರಿ ಬ್ಯಾಕಪ್-ಪುಶ್ ಮಾಡಿದಾಗ, ಅದು ಪೂರ್ಣ ಬ್ಯಾಕಪ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ. ನೀವು ಅದನ್ನು ಯಾವುದೇ ಧನಾತ್ಮಕ ಸಂಖ್ಯೆಗೆ ಬದಲಾಯಿಸಿದರೆ, ಉದಾಹರಣೆಗೆ, 3, ನಂತರ ನೀವು ಮುಂದಿನ ಬಾರಿ ಬ್ಯಾಕ್ಅಪ್-ಪುಶ್ ಮಾಡಿದಾಗ, ಅದು ಹಿಂದಿನ ಬ್ಯಾಕ್ಅಪ್ಗಳ ಇತಿಹಾಸವನ್ನು ನೋಡುತ್ತದೆ. ನೀವು 3 ಡೆಲ್ಟಾಗಳ ಸರಪಳಿಯನ್ನು ಮೀರುವುದಿಲ್ಲ ಎಂದು ಅವನು ನೋಡುತ್ತಾನೆ ಮತ್ತು ಡೆಲ್ಟಾವನ್ನು ಮಾಡುತ್ತಾನೆ.

ಅಂದರೆ, ನಾವು ಪ್ರತಿ ಬಾರಿ WAL-G ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಅದು ಪೂರ್ಣ ಬ್ಯಾಕಪ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆಯೇ?

ಇಲ್ಲ, ನಾವು WAL-G ಅನ್ನು ನಡೆಸುತ್ತೇವೆ ಮತ್ತು ನಿಮ್ಮ ನೀತಿಗಳು ಅದನ್ನು ಅನುಮತಿಸಿದರೆ ಅದು ಡೆಲ್ಟಾ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.

ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ, ನೀವು ಅದನ್ನು ಪ್ರತಿ ಬಾರಿ ಶೂನ್ಯದೊಂದಿಗೆ ರನ್ ಮಾಡಿದರೆ, ಅದು pg_basebackup ನಂತೆ ವರ್ತಿಸುತ್ತದೆಯೇ?

ಇಲ್ಲ, ಇದು ಸಂಕೋಚನ ಮತ್ತು ಸಮಾನಾಂತರತೆಯನ್ನು ಬಳಸುವುದರಿಂದ ಅದು ಇನ್ನೂ ವೇಗವಾಗಿ ಚಲಿಸುತ್ತದೆ. Pg_basebackup ನಿಮ್ಮ ಪಕ್ಕದಲ್ಲಿ ಶಾಫ್ಟ್ ಅನ್ನು ಇರಿಸುತ್ತದೆ. ನೀವು ಆರ್ಕೈವಿಂಗ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೀರಿ ಎಂದು WAL-G ಊಹಿಸುತ್ತದೆ. ಮತ್ತು ಅದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡದಿದ್ದರೆ ಅದು ಎಚ್ಚರಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ.

Pg_basebackup ಅನ್ನು ಶಾಫ್ಟ್‌ಗಳಿಲ್ಲದೆ ಚಲಾಯಿಸಬಹುದು.

ಹೌದು, ಆಗ ಅವರು ಬಹುತೇಕ ಒಂದೇ ರೀತಿ ವರ್ತಿಸುತ್ತಾರೆ. ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗೆ Pg_basebackup ನಕಲುಗಳು. ಅಂದಹಾಗೆ, ನಾನು ನಮೂದಿಸಲು ಮರೆತಿರುವ ಹೊಸ ವೈಶಿಷ್ಟ್ಯವನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಈಗ pg_basebackup ನಿಂದ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗೆ ಬ್ಯಾಕಪ್ ಮಾಡಬಹುದು. ಇದು ಏಕೆ ಬೇಕು ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ, ಆದರೆ ಅದು ಇದೆ.

ಉದಾಹರಣೆಗೆ, CephFS ನಲ್ಲಿ. ಪ್ರತಿಯೊಬ್ಬರೂ ಆಬ್ಜೆಕ್ಟ್ ಸ್ಟೋರೇಜ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ.

ಹೌದು, ಬಹುಶಃ ಅದಕ್ಕಾಗಿಯೇ ಅವರು ಈ ವೈಶಿಷ್ಟ್ಯದ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಿದರು ಇದರಿಂದ ನಾವು ಅದನ್ನು ಮಾಡಬಹುದು. ಮತ್ತು ನಾವು ಅದನ್ನು ಮಾಡಿದ್ದೇವೆ.

ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ಫೈಲ್ ಸಿಸ್ಟಮ್ಗೆ ನಕಲಿಸುವ ಬಗ್ಗೆ ಕೇವಲ ಒಂದು ಪ್ರಶ್ನೆ ಇದೆ. ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ, ರಿಮೋಟ್ ಸ್ಟೋರೇಜ್‌ಗೆ ನಕಲು ಮಾಡುವುದನ್ನು ನೀವು ಈಗ ಬೆಂಬಲಿಸುತ್ತೀರಾ, ಉದಾಹರಣೆಗೆ, ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ಕೆಲವು ಶೆಲ್ಫ್ ಅಥವಾ ಇನ್ನೇನಾದರೂ ಇದ್ದರೆ?

ಈ ಸೂತ್ರೀಕರಣದಲ್ಲಿ, ಇದು ಕಷ್ಟಕರವಾದ ಪ್ರಶ್ನೆಯಾಗಿದೆ. ಹೌದು, ನಾವು ಬೆಂಬಲಿಸುತ್ತೇವೆ, ಆದರೆ ಈ ಕಾರ್ಯವನ್ನು ಇನ್ನೂ ಯಾವುದೇ ಬಿಡುಗಡೆಯಲ್ಲಿ ಸೇರಿಸಲಾಗಿಲ್ಲ. ಅಂದರೆ, ಎಲ್ಲಾ ಪೂರ್ವ-ಬಿಡುಗಡೆಗಳು ಇದನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ, ಆದರೆ ಬಿಡುಗಡೆಯ ಆವೃತ್ತಿಗಳು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಈ ಕಾರ್ಯವನ್ನು ಆವೃತ್ತಿ 0.2 ರಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ. ನಾವು ತಿಳಿದಿರುವ ಎಲ್ಲಾ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಿದ ತಕ್ಷಣ ಅದನ್ನು ಖಂಡಿತವಾಗಿಯೂ ಶೀಘ್ರದಲ್ಲೇ ಬಿಡುಗಡೆ ಮಾಡಲಾಗುತ್ತದೆ. ಆದರೆ ಇದೀಗ ಇದನ್ನು ಪ್ರಿ-ರಿಲೀಸ್‌ನಲ್ಲಿ ಮಾತ್ರ ಮಾಡಬಹುದು. ಪ್ರೀ-ರಿಲೀಸ್‌ನಲ್ಲಿ ಎರಡು ದೋಷಗಳಿವೆ. WAL-E ಮರುಪ್ರಾಪ್ತಿಯಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ, ನಾವು ಅದನ್ನು ಸರಿಪಡಿಸಿಲ್ಲ. ಮತ್ತು ಇತ್ತೀಚಿನ ಪೂರ್ವ-ಬಿಡುಗಡೆಯಲ್ಲಿ ಡೆಲ್ಟಾ-ಬ್ಯಾಕ್‌ಅಪ್ ಕುರಿತು ದೋಷವನ್ನು ಸೇರಿಸಲಾಗಿದೆ. ಆದ್ದರಿಂದ, ಬಿಡುಗಡೆ ಆವೃತ್ತಿಗಳನ್ನು ಬಳಸಲು ನಾವು ಎಲ್ಲರಿಗೂ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಪೂರ್ವ-ಬಿಡುಗಡೆಯಲ್ಲಿ ಹೆಚ್ಚಿನ ದೋಷಗಳಿಲ್ಲದ ತಕ್ಷಣ, ನಾವು Google ಕ್ಲೌಡ್, S3-ಹೊಂದಾಣಿಕೆಯ ವಿಷಯಗಳು ಮತ್ತು ಫೈಲ್ ಸಂಗ್ರಹಣೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತೇವೆ ಎಂದು ಹೇಳಬಹುದು.

ನಮಸ್ಕಾರ, ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು. ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, WAL-G ಬಾರ್ಮೆನ್ ನಂತಹ ಕೆಲವು ರೀತಿಯ ಕೇಂದ್ರೀಕೃತ ವ್ಯವಸ್ಥೆಯಲ್ಲವೇ? ನೀವು ಈ ದಿಕ್ಕಿನಲ್ಲಿ ಚಲಿಸಲು ಯೋಜಿಸುತ್ತೀರಾ?

ಸಮಸ್ಯೆಯೆಂದರೆ ನಾವು ಈ ದಿಕ್ಕಿನಿಂದ ದೂರ ಸರಿದಿದ್ದೇವೆ. WAL-G ಮೂಲ ಹೋಸ್ಟ್‌ನಲ್ಲಿ, ಕ್ಲಸ್ಟರ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ. ನಾವು ಹಲವಾರು ಸಾವಿರ ಕ್ಲಸ್ಟರ್‌ಗಳಿಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಾಗ, ನಾವು ಅನೇಕ ಬಾರ್ಟೆಂಡರ್ ಸ್ಥಾಪನೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ಪ್ರತಿ ಬಾರಿ ಏನಾದರೂ ಅವುಗಳಲ್ಲಿ ಬೀಳುತ್ತದೆ, ಅದು ದೊಡ್ಡ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಅವರು ದುರಸ್ತಿ ಮಾಡಬೇಕಾದ ಕಾರಣ, ಈಗ ಯಾವ ಕ್ಲಸ್ಟರ್‌ಗಳು ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಬ್ಯಾಕಪ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗಾಗಿ ಭೌತಿಕ ಯಂತ್ರಾಂಶದ ದಿಕ್ಕಿನಲ್ಲಿ WAL-G ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ನಾನು ಯೋಜಿಸುವುದಿಲ್ಲ. ಸಮುದಾಯವು ಇಲ್ಲಿ ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ಬಯಸಿದರೆ, ನಾನು ಅಭ್ಯಂತರವಿಲ್ಲ.

ಸಂಗ್ರಹಣೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ತಂಡಗಳನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ತುಂಬಾ ಒಳ್ಳೆಯವರಾಗಿದ್ದೇವೆ, ಅದು ನಾವಲ್ಲ, ನಮ್ಮ ಫೈಲ್‌ಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಇರಿಸುವ ವಿಶೇಷ ವ್ಯಕ್ತಿಗಳು ಇದ್ದಾರೆ. ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಫೈಲ್‌ಗಳ ನಷ್ಟವನ್ನು ತಡೆದುಕೊಳ್ಳಲು ಅವರು ಎಲ್ಲಾ ರೀತಿಯ ಬುದ್ಧಿವಂತ ಕೋಡಿಂಗ್ ಅನ್ನು ಮಾಡುತ್ತಾರೆ. ಅವರು ನೆಟ್ವರ್ಕ್ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ಗೆ ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ. ನೀವು ಬಾರ್ಟೆಂಡರ್ ಅನ್ನು ಹೊಂದಿರುವಾಗ, ಹೆಚ್ಚಿನ ದಟ್ಟಣೆಯನ್ನು ಹೊಂದಿರುವ ಸಣ್ಣ ಡೇಟಾಬೇಸ್‌ಗಳು ಒಂದೇ ಸರ್ವರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲ್ಪಟ್ಟಿವೆ ಎಂದು ನೀವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಕಂಡುಹಿಡಿಯಬಹುದು. ನೀವು ಅದರಲ್ಲಿ ಸಾಕಷ್ಟು ಜಾಗವನ್ನು ಹೊಂದಿರುವಂತೆ ತೋರುತ್ತಿದೆ, ಆದರೆ ಕೆಲವು ಕಾರಣಗಳಿಂದ ಎಲ್ಲವೂ ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಸರಿಹೊಂದುವುದಿಲ್ಲ. ಇದು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ತಿರುಗಬಹುದು. ಅಲ್ಲಿ ಸಾಕಷ್ಟು ನೆಟ್‌ವರ್ಕ್‌ಗಳಿವೆ, ಪ್ರೊಸೆಸರ್ ಕೋರ್‌ಗಳಿವೆ, ಆದರೆ ಇಲ್ಲಿ ಯಾವುದೇ ಡಿಸ್ಕ್‌ಗಳಿಲ್ಲ. ಮತ್ತು ಏನನ್ನಾದರೂ ಕಣ್ಕಟ್ಟು ಮಾಡುವ ಈ ಅಗತ್ಯದಿಂದ ನಾವು ಬೇಸತ್ತಿದ್ದೇವೆ ಮತ್ತು ಡೇಟಾ ಸಂಗ್ರಹಣೆಯು ಪ್ರತ್ಯೇಕ ಸೇವೆಯಾಗಿದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ನಾವು ತೆರಳಿದ್ದೇವೆ, ಇದಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕ ವಿಶೇಷ ಜನರು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ.

ಪಿಎಸ್ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲಾಗಿದೆ 0.2.15, ಇದರಲ್ಲಿ ನೀವು .walg.json ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಬಳಸಬಹುದು, ಇದು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಹೋಮ್ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿದೆ. ನೀವು ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ತ್ಯಜಿಸಬಹುದು. ಉದಾಹರಣೆ .walg.json ಈ ಸಂಚಿಕೆಯಲ್ಲಿದೆ https://github.com/wal-g/wal-g/issues/545

ವೀಡಿಯೊ:

ಮೂಲ: www.habr.com