ಅವರ ವರದಿಯಲ್ಲಿ, ಆಂಡ್ರೆ ಬೊರೊಡಿನ್ ಅವರು ಸಂಪರ್ಕ ಪೂಲರ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವಾಗ PgBouncer ಅನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವ ಅನುಭವವನ್ನು ಹೇಗೆ ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡರು ಎಂದು ನಿಮಗೆ ತಿಳಿಸುತ್ತಾರೆ. , ಅವರು ಅದನ್ನು ಉತ್ಪಾದನೆಗೆ ಹೊರತಂದಿದ್ದಾರೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಹೊಸ ಆವೃತ್ತಿಗಳಲ್ಲಿ ನಾವು ಯಾವ ಪುಲ್ಲರ್‌ನ ಕಾರ್ಯಗಳನ್ನು ನೋಡಲು ಬಯಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ನಾವು ಚರ್ಚಿಸುತ್ತೇವೆ: ನಮ್ಮ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸುವುದು ಮಾತ್ರವಲ್ಲ, ಬಳಕೆದಾರರ ಸಮುದಾಯವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು ನಮಗೆ ಮುಖ್ಯವಾಗಿದೆ .
ವೀಡಿಯೊ:
ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ನನ್ನ ಹೆಸರು ಆಂಡ್ರ್ಯೂ.
ಯಾಂಡೆಕ್ಸ್‌ನಲ್ಲಿ, ನಾನು ತೆರೆದ ಮೂಲ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೇನೆ. ಮತ್ತು ಇಂದು ನಾವು ಸಂಪರ್ಕ ಪೂಲರ್ ಸಂಪರ್ಕಗಳ ಬಗ್ಗೆ ವಿಷಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ರಷ್ಯನ್ ಭಾಷೆಯಲ್ಲಿ ಸಂಪರ್ಕ ಪೂಲರ್ ಅನ್ನು ಹೇಗೆ ಕರೆಯುವುದು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದ್ದರೆ, ನಂತರ ಹೇಳಿ. ತಾಂತ್ರಿಕ ಸಾಹಿತ್ಯದಲ್ಲಿ ಸ್ಥಾಪಿಸಬೇಕಾದ ಉತ್ತಮ ತಾಂತ್ರಿಕ ಪದವನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾನು ನಿಜವಾಗಿಯೂ ಬಯಸುತ್ತೇನೆ.
ವಿಷಯವು ಸಾಕಷ್ಟು ಜಟಿಲವಾಗಿದೆ, ಏಕೆಂದರೆ ಅನೇಕ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಸಂಪರ್ಕ ಪೂಲರ್ ಅಂತರ್ನಿರ್ಮಿತವಾಗಿದೆ ಮತ್ತು ನೀವು ಅದರ ಬಗ್ಗೆ ತಿಳಿದುಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ. ಸಹಜವಾಗಿ, ಎಲ್ಲೆಡೆ ಕೆಲವು ಸೆಟ್ಟಿಂಗ್‌ಗಳಿವೆ, ಆದರೆ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ ಅದು ಆ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಸಮಾನಾಂತರವಾಗಿ (ಹೈಲೋಡ್++ 2019 ರಲ್ಲಿ) ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿಸುವ ಕುರಿತು ನಿಕೊಲಾಯ್ ಸಮೋಖ್ವಾಲೋವ್ ಅವರ ವರದಿಯಿದೆ. ಮತ್ತು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಈಗಾಗಲೇ ತಮ್ಮ ಪ್ರಶ್ನೆಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿರುವ ಜನರು ಇಲ್ಲಿಗೆ ಬಂದಿದ್ದಾರೆ ಮತ್ತು ಇವರು ನೆಟ್ವರ್ಕ್ ಮತ್ತು ಸಂಪನ್ಮೂಲ ಬಳಕೆಗೆ ಸಂಬಂಧಿಸಿದ ಹೆಚ್ಚು ಅಪರೂಪದ ಸಿಸ್ಟಮ್ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತಿರುವ ಜನರು. ಮತ್ತು ಕೆಲವು ಸ್ಥಳಗಳಲ್ಲಿ ಸಮಸ್ಯೆಗಳು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ ಎಂಬ ಅರ್ಥದಲ್ಲಿ ಸಾಕಷ್ಟು ಕಷ್ಟವಾಗಬಹುದು.
ಯಾಂಡೆಕ್ಸ್ ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಅನ್ನು ಹೊಂದಿದೆ. ಅನೇಕ Yandex ಸೇವೆಗಳು Yandex.Cloud ನಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ. ಮತ್ತು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಕನಿಷ್ಠ ಒಂದು ಮಿಲಿಯನ್ ವಿನಂತಿಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಹಲವಾರು ಪೆಟಾಬೈಟ್‌ಗಳ ಡೇಟಾವನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ.
ಮತ್ತು ನಾವು ಎಲ್ಲಾ ಸೇವೆಗಳಿಗೆ ಸಾಕಷ್ಟು ಪ್ರಮಾಣಿತ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಒದಗಿಸುತ್ತೇವೆ - ಇದು ನೋಡ್ನ ಮುಖ್ಯ ಪ್ರಾಥಮಿಕ ನೋಡ್, ಸಾಮಾನ್ಯ ಎರಡು ಪ್ರತಿಕೃತಿಗಳು (ಸಿಂಕ್ರೊನಸ್ ಮತ್ತು ಅಸಮಕಾಲಿಕ), ಬ್ಯಾಕ್ಅಪ್, ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ಓದುವ ವಿನಂತಿಗಳ ಸ್ಕೇಲಿಂಗ್.
ಪ್ರತಿಯೊಂದು ಕ್ಲಸ್ಟರ್ ನೋಡ್ ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಆಗಿದೆ, ಅದರ ಮೇಲೆ, ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಮತ್ತು ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳ ಜೊತೆಗೆ, ಸಂಪರ್ಕ ಪೂಲರ್ ಅನ್ನು ಸಹ ಸ್ಥಾಪಿಸಲಾಗಿದೆ. ಕನೆಕ್ಷನ್ ಪೂಲರ್ ಅನ್ನು ಫೆನ್ಸಿಂಗ್ಗಾಗಿ ಮತ್ತು ಅದರ ಮುಖ್ಯ ಉದ್ದೇಶಕ್ಕಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.
ಸಂಪರ್ಕ ಪೂಲರ್‌ನ ಮುಖ್ಯ ಉದ್ದೇಶವೇನು?
ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಪ್ರಕ್ರಿಯೆಯ ಮಾದರಿಯನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಇದರರ್ಥ ಒಂದು ಸಂಪರ್ಕವು ಒಂದು ಪ್ರಕ್ರಿಯೆ, ಒಂದು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಬ್ಯಾಕೆಂಡ್. ಮತ್ತು ಈ ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಬಹಳಷ್ಟು ವಿಭಿನ್ನ ಕ್ಯಾಶ್‌ಗಳಿವೆ, ಇದು ವಿಭಿನ್ನ ಸಂಪರ್ಕಗಳಿಗೆ ವಿಭಿನ್ನವಾಗಿಸಲು ಸಾಕಷ್ಟು ದುಬಾರಿಯಾಗಿದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, Postgres ಕೋಡ್ procArray ಎಂಬ ಶ್ರೇಣಿಯನ್ನು ಹೊಂದಿದೆ. ಇದು ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕಗಳ ಬಗ್ಗೆ ಮೂಲಭೂತ ಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿದೆ. ಮತ್ತು ಬಹುತೇಕ ಎಲ್ಲಾ procArray ಸಂಸ್ಕರಣಾ ಅಲ್ಗಾರಿದಮ್‌ಗಳು ರೇಖೀಯ ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೊಂದಿವೆ; ಅವುಗಳು ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕಗಳ ಸಂಪೂರ್ಣ ಶ್ರೇಣಿಯ ಮೇಲೆ ಚಲಿಸುತ್ತವೆ. ಇದು ಸಾಕಷ್ಟು ತ್ವರಿತ ಚಕ್ರವಾಗಿದೆ, ಆದರೆ ಹೆಚ್ಚು ಒಳಬರುವ ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕಗಳೊಂದಿಗೆ ವಸ್ತುಗಳು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ದುಬಾರಿಯಾಗುತ್ತವೆ. ಮತ್ತು ವಸ್ತುಗಳು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ದುಬಾರಿಯಾದಾಗ, ನೀವು ಬಹಳಷ್ಟು ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕಗಳಿಗೆ ಹೆಚ್ಚಿನ ಬೆಲೆಯನ್ನು ಪಾವತಿಸಬಹುದು.
3 ಸಂಭವನೀಯ ವಿಧಾನಗಳಿವೆ:
- ಅಪ್ಲಿಕೇಶನ್ ಬದಿಯಲ್ಲಿ.
- ಡೇಟಾಬೇಸ್ ಬದಿಯಲ್ಲಿ.
- ಮತ್ತು ನಡುವೆ, ಅಂದರೆ, ಎಲ್ಲಾ ರೀತಿಯ ಸಂಯೋಜನೆಗಳು.
ದುರದೃಷ್ಟವಶಾತ್, ಅಂತರ್ನಿರ್ಮಿತ ಪೂಲರ್ ಪ್ರಸ್ತುತ ಅಭಿವೃದ್ಧಿ ಹಂತದಲ್ಲಿದೆ. PostgreSQL ಪ್ರೊಫೆಷನಲ್‌ನಲ್ಲಿರುವ ನಮ್ಮ ಸ್ನೇಹಿತರು ಇದನ್ನು ಹೆಚ್ಚಾಗಿ ಮಾಡುತ್ತಾರೆ. ಅದು ಯಾವಾಗ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಊಹಿಸುವುದು ಕಷ್ಟ. ಮತ್ತು ವಾಸ್ತವವಾಗಿ, ವಾಸ್ತುಶಿಲ್ಪಿ ಆಯ್ಕೆ ಮಾಡಲು ನಾವು ಎರಡು ಪರಿಹಾರಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಇವುಗಳು ಅಪ್ಲಿಕೇಶನ್-ಸೈಡ್ ಪೂಲ್ ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಪೂಲ್.
ಅಪ್ಲಿಕೇಶನ್-ಸೈಡ್ ಪೂಲ್ ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ. ಮತ್ತು ಬಹುತೇಕ ಎಲ್ಲಾ ಕ್ಲೈಂಟ್ ಡ್ರೈವರ್‌ಗಳು ನಿಮಗೆ ಒಂದು ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತವೆ: ಡೇಟಾಬೇಸ್‌ಗೆ ಹಲವಾರು ಡಜನ್ ಸಂಪರ್ಕಗಳಂತೆ ನಿಮ್ಮ ಲಕ್ಷಾಂತರ ಸಂಪರ್ಕಗಳನ್ನು ಕೋಡ್‌ನಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಿ.
ಉದ್ಭವಿಸುವ ಸಮಸ್ಯೆಯೆಂದರೆ, ಒಂದು ನಿರ್ದಿಷ್ಟ ಹಂತದಲ್ಲಿ ನೀವು ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಅಳೆಯಲು ಬಯಸುತ್ತೀರಿ, ನೀವು ಅದನ್ನು ಅನೇಕ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಿಗೆ ನಿಯೋಜಿಸಲು ಬಯಸುತ್ತೀರಿ.
ನಂತರ ನೀವು ಹಲವಾರು ಲಭ್ಯತೆಯ ವಲಯಗಳನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ನೀವು ಅರಿತುಕೊಳ್ಳುತ್ತೀರಿ, ಹಲವಾರು ಡೇಟಾ ಕೇಂದ್ರಗಳು. ಮತ್ತು ಕ್ಲೈಂಟ್ ಸೈಡ್ ಪೂಲಿಂಗ್ ವಿಧಾನವು ದೊಡ್ಡ ಸಂಖ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ದೊಡ್ಡದು ಸುಮಾರು 10 ಸಂಪರ್ಕಗಳು. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಅಂಚು.
ನಾವು ಪ್ರಾಕ್ಸಿ ಪೂಲರ್‌ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಿದರೆ, ಎರಡು ಪೂಲರ್ಗಳು ಬಹಳಷ್ಟು ಕೆಲಸಗಳನ್ನು ಮಾಡಬಹುದು. ಅವರು ಕೇವಲ ಪೂಲರ್‌ಗಳಲ್ಲ. ಅವರು ಪೂಲರ್ಗಳು + ಹೆಚ್ಚು ತಂಪಾದ ಕಾರ್ಯವನ್ನು. ಈ и .
ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಎಲ್ಲರಿಗೂ ಈ ಹೆಚ್ಚುವರಿ ಕ್ರಿಯಾತ್ಮಕತೆಯ ಅಗತ್ಯವಿಲ್ಲ. ಮತ್ತು ಇದು ಪೂಲರ್ಗಳು ಸೆಷನ್ ಪೂಲಿಂಗ್ ಅನ್ನು ಮಾತ್ರ ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ, ಅಂದರೆ ಒಂದು ಒಳಬರುವ ಕ್ಲೈಂಟ್, ಡೇಟಾಬೇಸ್‌ಗೆ ಹೊರಹೋಗುವ ಕ್ಲೈಂಟ್.
ನಮ್ಮ ಉದ್ದೇಶಗಳಿಗೆ ಇದು ತುಂಬಾ ಸೂಕ್ತವಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು PgBouncer ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಇದು ವಹಿವಾಟು ಪೂಲಿಂಗ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ, ಅಂದರೆ ಸರ್ವರ್ ಸಂಪರ್ಕಗಳು ವಹಿವಾಟಿನ ಅವಧಿಗೆ ಮಾತ್ರ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗಳಿಗೆ ಹೊಂದಾಣಿಕೆಯಾಗುತ್ತವೆ.
ಮತ್ತು ನಮ್ಮ ಕೆಲಸದ ಹೊರೆಯಲ್ಲಿ, ಇದು ನಿಜ. ಆದರೆ ಕೆಲವು ಸಮಸ್ಯೆಗಳಿವೆ.
ನೀವು ಸೆಶನ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಬಯಸಿದಾಗ ಸಮಸ್ಯೆಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ, ಏಕೆಂದರೆ ನಿಮ್ಮ ಎಲ್ಲಾ ಒಳಬರುವ ಸಂಪರ್ಕಗಳು ಸ್ಥಳೀಯವಾಗಿರುತ್ತವೆ. ಎಲ್ಲರೂ ಲೂಪ್‌ಬ್ಯಾಕ್‌ನೊಂದಿಗೆ ಬಂದರು ಮತ್ತು ಹೇಗಾದರೂ ಅಧಿವೇಶನವನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಕಷ್ಟವಾಗುತ್ತದೆ.
ಸಹಜವಾಗಿ ನೀವು application_name_add_host ಅನ್ನು ಬಳಸಬಹುದು. ಅಪ್ಲಿಕೇಶನ್_ಹೆಸರಿಗೆ IP ವಿಳಾಸವನ್ನು ಸೇರಿಸಲು ಬೌನ್ಸರ್ ಬದಿಯಲ್ಲಿ ಇದು ಒಂದು ಮಾರ್ಗವಾಗಿದೆ. ಆದರೆ ಅಪ್ಲಿಕೇಶನ್_ಹೆಸರನ್ನು ಹೆಚ್ಚುವರಿ ಸಂಪರ್ಕದಿಂದ ಹೊಂದಿಸಲಾಗಿದೆ.
ಈ ಗ್ರಾಫ್‌ನಲ್ಲಿ, ಹಳದಿ ರೇಖೆಯು ನಿಜವಾದ ವಿನಂತಿಗಳು ಮತ್ತು ಅಲ್ಲಿ ನೀಲಿ ರೇಖೆಯು ಡೇಟಾಬೇಸ್‌ಗೆ ಹಾರುವ ವಿನಂತಿಗಳು. ಮತ್ತು ಈ ವ್ಯತ್ಯಾಸವು ನಿಖರವಾಗಿ ಅಪ್ಲಿಕೇಶನ್_ಹೆಸರಿನ ಸ್ಥಾಪನೆಯಾಗಿದೆ, ಇದು ಪತ್ತೆಹಚ್ಚಲು ಮಾತ್ರ ಅಗತ್ಯವಿದೆ, ಆದರೆ ಇದು ಉಚಿತವಲ್ಲ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಬೌನ್ಸರ್ನಲ್ಲಿ ನೀವು ಒಂದು ಪೂಲ್ ಅನ್ನು ಮಿತಿಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ, ಅಂದರೆ ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರರಿಗೆ ಪ್ರತಿ ನಿರ್ದಿಷ್ಟ ಡೇಟಾಬೇಸ್‌ಗೆ ಡೇಟಾಬೇಸ್ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆ.
ಇದು ಯಾವುದಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ? ನೀವು C++ ನಲ್ಲಿ ಬರೆಯಲಾದ ಲೋಡ್ ಮಾಡಲಾದ ಸೇವೆಯನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಭಯಾನಕ ಏನನ್ನೂ ಮಾಡದ ನೋಡ್‌ನಲ್ಲಿ ಎಲ್ಲೋ ಹತ್ತಿರದ ಸಣ್ಣ ಸೇವೆಯನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಆದರೆ ಅದರ ಚಾಲಕವು ಹುಚ್ಚನಾಗುತ್ತಾನೆ. ಇದು 20 ಸಂಪರ್ಕಗಳನ್ನು ತೆರೆಯುತ್ತದೆ ಮತ್ತು ಉಳಿದಂತೆ ಕಾಯುತ್ತದೆ. ನಿಮ್ಮ ಕೋಡ್ ಸಹ ಸಾಮಾನ್ಯವಾಗಿದೆ.
ನಾವು ಸಹಜವಾಗಿ, ಈ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸೇರಿಸುವ ಬೌನ್ಸರ್‌ಗಾಗಿ ಸಣ್ಣ ಪ್ಯಾಚ್ ಅನ್ನು ಬರೆದಿದ್ದೇವೆ, ಅಂದರೆ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಪೂಲ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತೇವೆ.
ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಬದಿಯಲ್ಲಿ ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಅಂದರೆ, ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿನ ಪಾತ್ರಗಳನ್ನು ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯಿಂದ ಮಿತಿಗೊಳಿಸಿ.
ಆದರೆ ನೀವು ಸರ್ವರ್‌ಗೆ ಏಕೆ ಸಂಪರ್ಕ ಹೊಂದಿಲ್ಲ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನೀವು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. PgBouncer ಸಂಪರ್ಕ ದೋಷವನ್ನು ಎಸೆಯುವುದಿಲ್ಲ, ಅದು ಯಾವಾಗಲೂ ಅದೇ ಮಾಹಿತಿಯನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ. ಮತ್ತು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ: ಬಹುಶಃ ನಿಮ್ಮ ಪಾಸ್ವರ್ಡ್ ಬದಲಾಗಿರಬಹುದು, ಬಹುಶಃ ಡೇಟಾಬೇಸ್ ಕಳೆದುಹೋಗಿರಬಹುದು, ಬಹುಶಃ ಏನಾದರೂ ತಪ್ಪಾಗಿದೆ. ಆದರೆ ಯಾವುದೇ ರೋಗನಿರ್ಣಯವಿಲ್ಲ. ಅಧಿವೇಶನವನ್ನು ಸ್ಥಾಪಿಸಲಾಗದಿದ್ದರೆ, ಅದನ್ನು ಏಕೆ ಸ್ಥಾಪಿಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲ.
ಒಂದು ನಿರ್ದಿಷ್ಟ ಹಂತದಲ್ಲಿ, ನೀವು ಅಪ್ಲಿಕೇಶನ್ ಗ್ರಾಫ್‌ಗಳನ್ನು ನೋಡುತ್ತೀರಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ ಎಂದು ನೋಡಿ.
ಮೇಲ್ಭಾಗವನ್ನು ನೋಡಿ ಮತ್ತು ಬೌನ್ಸರ್ ಏಕ-ಥ್ರೆಡ್ ಆಗಿದೆ ಎಂದು ನೋಡಿ. ಇದು ಸೇವಾ ಜೀವನದಲ್ಲಿ ಒಂದು ಮಹತ್ವದ ತಿರುವು. ನೀವು ಒಂದೂವರೆ ವರ್ಷದಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅಳೆಯಲು ತಯಾರಿ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ನೀವು ಅರಿತುಕೊಂಡಿದ್ದೀರಿ ಮತ್ತು ನೀವು ಪೂಲರ್ ಅನ್ನು ಅಳೆಯುವ ಅಗತ್ಯವಿದೆ.
ನಮಗೆ ಹೆಚ್ಚು PgBouncers ಬೇಕು ಎಂಬ ತೀರ್ಮಾನಕ್ಕೆ ಬಂದಿದ್ದೇವೆ.
ಬೌನ್ಸರ್ ಅನ್ನು ಸ್ವಲ್ಪ ತೇಪೆ ಮಾಡಲಾಗಿದೆ.
ಮತ್ತು ಅವರು TCP ಪೋರ್ಟ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುವ ಮೂಲಕ ಹಲವಾರು ಬೌನ್ಸರ್‌ಗಳನ್ನು ಬೆಳೆಸುವಂತೆ ಮಾಡಿದರು. ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರೌಂಡ್-ರಾಬಿನ್ ಬಳಸಿ ಒಳಬರುವ TCP ಸಂಪರ್ಕಗಳನ್ನು ಅವುಗಳ ನಡುವೆ ವರ್ಗಾಯಿಸುತ್ತದೆ.
ಇದು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಪಾರದರ್ಶಕವಾಗಿರುತ್ತದೆ, ಅಂದರೆ ನೀವು ಒಂದು ಬೌನ್ಸರ್ ಅನ್ನು ಹೊಂದಿರುವಂತೆ ತೋರುತ್ತಿದೆ, ಆದರೆ ಚಾಲನೆಯಲ್ಲಿರುವ ಬೌನ್ಸರ್‌ಗಳ ನಡುವೆ ನೀವು ನಿಷ್ಕ್ರಿಯ ಸಂಪರ್ಕಗಳ ವಿಘಟನೆಯನ್ನು ಹೊಂದಿರುವಿರಿ.
ಮತ್ತು ಒಂದು ನಿರ್ದಿಷ್ಟ ಕ್ಷಣದಲ್ಲಿ ಈ 3 ಬೌನ್ಸರ್‌ಗಳು ಪ್ರತಿಯೊಬ್ಬರೂ ತಮ್ಮ ಕೋರ್ ಅನ್ನು 100% ರಷ್ಟು ತಿನ್ನುವುದನ್ನು ನೀವು ಗಮನಿಸಬಹುದು. ನಿಮಗೆ ಕೆಲವು ಬೌನ್ಸರ್‌ಗಳ ಅಗತ್ಯವಿದೆ. ಏಕೆ?
ಏಕೆಂದರೆ ನೀವು TLS ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ. ನೀವು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿರುವಿರಿ. ಮತ್ತು ನೀವು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಅನ್ನು TLS ಜೊತೆಗೆ ಮತ್ತು ಇಲ್ಲದೆ ಬೆಂಚ್‌ಮಾರ್ಕ್ ಮಾಡಿದರೆ, ಸ್ಥಾಪಿತ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯು ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದರೊಂದಿಗೆ ಸುಮಾರು ಎರಡು ಆರ್ಡರ್‌ಗಳ ಪ್ರಮಾಣದಲ್ಲಿ ಇಳಿಯುತ್ತದೆ ಎಂದು ನೀವು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ, ಏಕೆಂದರೆ TLS ಹ್ಯಾಂಡ್ಶೇಕ್ CPU ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತದೆ.
ಮತ್ತು ಮೇಲ್ಭಾಗದಲ್ಲಿ ನೀವು ಒಳಬರುವ ಸಂಪರ್ಕಗಳ ಅಲೆಯಿರುವಾಗ ಕಾರ್ಯಗತಗೊಳ್ಳುವ ಕೆಲವು ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಕಾರ್ಯಗಳನ್ನು ನೋಡಬಹುದು. ನಮ್ಮ ಪ್ರಾಥಮಿಕವು ಲಭ್ಯತೆಯ ವಲಯಗಳ ನಡುವೆ ಬದಲಾಯಿಸಬಹುದಾದ ಕಾರಣ, ಒಳಬರುವ ಸಂಪರ್ಕಗಳ ಅಲೆಯು ಸಾಕಷ್ಟು ವಿಶಿಷ್ಟವಾದ ಪರಿಸ್ಥಿತಿಯಾಗಿದೆ. ಅಂದರೆ, ಕೆಲವು ಕಾರಣಗಳಿಂದ ಹಳೆಯ ಪ್ರಾಥಮಿಕವು ಲಭ್ಯವಿಲ್ಲ, ಸಂಪೂರ್ಣ ಲೋಡ್ ಅನ್ನು ಮತ್ತೊಂದು ಡೇಟಾ ಕೇಂದ್ರಕ್ಕೆ ಕಳುಹಿಸಲಾಗಿದೆ. ಅವರೆಲ್ಲರೂ ಒಂದೇ ಸಮಯದಲ್ಲಿ TLS ಗೆ ಹಲೋ ಹೇಳಲು ಬರುತ್ತಾರೆ.
ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ TLS ಹ್ಯಾಂಡ್ಶೇಕ್ ಇನ್ನು ಮುಂದೆ ಬೌನ್ಸರ್‌ಗೆ ಹಲೋ ಹೇಳುವುದಿಲ್ಲ, ಆದರೆ ಅವನ ಗಂಟಲನ್ನು ಹಿಂಡುತ್ತದೆ. ಸಮಯ ಮೀರಿದ ಕಾರಣ, ಒಳಬರುವ ಸಂಪರ್ಕಗಳ ಅಲೆಯು ಅಳವಡಿಕೆಯಾಗಬಹುದು. ನೀವು ಘಾತೀಯ ಬ್ಯಾಕ್‌ಆಫ್ ಇಲ್ಲದೆ ಬೇಸ್‌ಗೆ ಮರುಪ್ರಯತ್ನಿಸಿದರೆ, ಅವರು ಸುಸಂಬದ್ಧ ಅಲೆಯಲ್ಲಿ ಮತ್ತೆ ಮತ್ತೆ ಬರುವುದಿಲ್ಲ.
16 ಕೋರ್‌ಗಳನ್ನು 16% ನಲ್ಲಿ ಲೋಡ್ ಮಾಡುವ 100 PgBouncers ನ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ.
ನಾವು ಕ್ಯಾಸ್ಕೇಡ್ PgBouncer ಗೆ ಬಂದೆವು. ಬೌನ್ಸರ್‌ನೊಂದಿಗೆ ನಮ್ಮ ಲೋಡ್‌ನಲ್ಲಿ ಸಾಧಿಸಬಹುದಾದ ಅತ್ಯುತ್ತಮ ಕಾನ್ಫಿಗರೇಶನ್ ಇದು. ನಮ್ಮ ಬಾಹ್ಯ ಬೌನ್ಸರ್‌ಗಳನ್ನು TCP ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಆಂತರಿಕ ಬೌನ್ಸರ್‌ಗಳನ್ನು ನೈಜ ಪೂಲಿಂಗ್‌ಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಬಾಹ್ಯ ಸಂಪರ್ಕಗಳನ್ನು ಹೆಚ್ಚು ವಿಘಟಿಸುವುದಿಲ್ಲ.
ಈ ಸಂರಚನೆಯಲ್ಲಿ, ಮೃದುವಾದ ಮರುಪ್ರಾರಂಭವು ಸಾಧ್ಯ. ನೀವು ಈ ಎಲ್ಲಾ 18 ಬೌನ್ಸರ್‌ಗಳನ್ನು ಒಂದೊಂದಾಗಿ ಮರುಪ್ರಾರಂಭಿಸಬಹುದು. ಆದರೆ ಅಂತಹ ಸಂರಚನೆಯನ್ನು ನಿರ್ವಹಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ. Sysadmins, DevOps, ಮತ್ತು ಈ ಸರ್ವರ್‌ಗೆ ನಿಜವಾಗಿ ಜವಾಬ್ದಾರರಾಗಿರುವ ಜನರು ಈ ವ್ಯವಸ್ಥೆಯಿಂದ ಹೆಚ್ಚು ಸಂತೋಷಪಡುವುದಿಲ್ಲ.
ನಮ್ಮ ಎಲ್ಲಾ ಸುಧಾರಣೆಗಳನ್ನು ಮುಕ್ತ ಮೂಲಕ್ಕೆ ಪ್ರಚಾರ ಮಾಡಬಹುದು ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಬೌನ್ಸರ್ ಅನ್ನು ಉತ್ತಮವಾಗಿ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಒಂದು ಪೋರ್ಟ್‌ನಲ್ಲಿ ಹಲವಾರು ಪಿಜಿಬೌನ್ಸರ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವ ಸಾಮರ್ಥ್ಯವು ಒಂದು ತಿಂಗಳ ಹಿಂದೆ ಬದ್ಧವಾಗಿದೆ. ಹಲವಾರು ವರ್ಷಗಳ ಹಿಂದೆ ಈ ವೈಶಿಷ್ಟ್ಯದೊಂದಿಗೆ ಪುಲ್ ವಿನಂತಿ ಇತ್ತು.
ಅಥವಾ ಇನ್ನೊಂದು ಉದಾಹರಣೆ. ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ, ಅನಗತ್ಯ ದೃಢೀಕರಣವಿಲ್ಲದೆಯೇ ರಹಸ್ಯವನ್ನು ಬೇರೆ ಸಂಪರ್ಕಕ್ಕೆ ಕಳುಹಿಸುವ ಮೂಲಕ ಪ್ರಗತಿಯಲ್ಲಿರುವ ವಿನಂತಿಯನ್ನು ನೀವು ರದ್ದುಗೊಳಿಸಬಹುದು. ಆದರೆ ಕೆಲವು ಗ್ರಾಹಕರು ಸರಳವಾಗಿ TCP ಮರುಹೊಂದಿಕೆಯನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ, ಅಂದರೆ ಅವರು ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕವನ್ನು ಮುರಿಯುತ್ತಾರೆ. ಬೌನ್ಸರ್ ಏನು ಮಾಡುತ್ತಾನೆ? ಅವನು ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ. ಇದು ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮುಂದುವರಿಯುತ್ತದೆ. ಸಣ್ಣ ವಿನಂತಿಗಳೊಂದಿಗೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ರಚಿಸಿದ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಂಪರ್ಕಗಳನ್ನು ನೀವು ಸ್ವೀಕರಿಸಿದ್ದರೆ, ಬೌನ್ಸರ್‌ನಿಂದ ಸಂಪರ್ಕವನ್ನು ಕಡಿತಗೊಳಿಸುವುದು ಸಾಕಾಗುವುದಿಲ್ಲ; ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ವಿನಂತಿಗಳನ್ನು ಸಹ ನೀವು ಪೂರ್ಣಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ.
ಇದನ್ನು ಪ್ಯಾಚ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಈ ಸಮಸ್ಯೆಯನ್ನು ಇನ್ನೂ ಬೌನ್ಸರ್‌ನ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗೆ ವಿಲೀನಗೊಳಿಸಲಾಗಿಲ್ಲ.
ಆದ್ದರಿಂದ ನಾವು ನಮ್ಮದೇ ಆದ ಕನೆಕ್ಷನ್ ಪೂಲರ್ ಬೇಕು ಎಂಬ ತೀರ್ಮಾನಕ್ಕೆ ಬಂದಿದ್ದೇವೆ, ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗುತ್ತದೆ, ಪ್ಯಾಚ್ ಮಾಡಲಾಗುತ್ತದೆ, ಇದರಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಸರಿಪಡಿಸಬಹುದು ಮತ್ತು ಅದು ಬಹು-ಥ್ರೆಡ್ ಆಗಿರಬೇಕು.
ನಾವು ಮಲ್ಟಿಥ್ರೆಡಿಂಗ್ ಅನ್ನು ಮುಖ್ಯ ಕಾರ್ಯವಾಗಿ ಹೊಂದಿಸಿದ್ದೇವೆ. ಒಳಬರುವ TLS ಸಂಪರ್ಕಗಳ ತರಂಗವನ್ನು ನಾವು ಚೆನ್ನಾಗಿ ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಇದನ್ನು ಮಾಡಲು, ನಾವು Machinarium ಎಂಬ ಪ್ರತ್ಯೇಕ ಗ್ರಂಥಾಲಯವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕಾಗಿತ್ತು, ಇದು ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕದ ಯಂತ್ರ ಸ್ಥಿತಿಗಳನ್ನು ಅನುಕ್ರಮ ಕೋಡ್ ಎಂದು ವಿವರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ನೀವು libpq ಮೂಲ ಕೋಡ್ ಅನ್ನು ನೋಡಿದರೆ, ನಿಮಗೆ ಫಲಿತಾಂಶವನ್ನು ಹಿಂತಿರುಗಿಸುವ ಕೆಲವು ಸಂಕೀರ್ಣವಾದ ಕರೆಗಳನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ ಮತ್ತು "ನನಗೆ ನಂತರ ಕರೆ ಮಾಡಿ. ಇದೀಗ ನಾನು IO ಅನ್ನು ಹೊಂದಿದ್ದೇನೆ, ಆದರೆ IO ಹೋದಾಗ ನಾನು ಪ್ರೊಸೆಸರ್ನಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ಹೊಂದಿದ್ದೇನೆ. ಮತ್ತು ಇದು ಬಹು ಹಂತದ ಯೋಜನೆಯಾಗಿದೆ. ನೆಟ್ವರ್ಕ್ ಸಂವಹನವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ರಾಜ್ಯ ಯಂತ್ರದಿಂದ ವಿವರಿಸಲಾಗುತ್ತದೆ. "ನಾನು ಈ ಹಿಂದೆ N ಗಾತ್ರದ ಪ್ಯಾಕೆಟ್ ಹೆಡರ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದ್ದರೆ, ಈಗ ನಾನು N ಬೈಟ್‌ಗಳಿಗಾಗಿ ಕಾಯುತ್ತಿದ್ದೇನೆ," "ನಾನು SYNC ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸಿದ್ದರೆ, ಈಗ ನಾನು ಫಲಿತಾಂಶದ ಮೆಟಾಡೇಟಾದೊಂದಿಗೆ ಪ್ಯಾಕೆಟ್‌ಗಾಗಿ ಕಾಯುತ್ತಿದ್ದೇನೆ" ಎಂಬಂತಹ ಸಾಕಷ್ಟು ನಿಯಮಗಳು. ಜಟಿಲವನ್ನು ಲೈನ್ ಸ್ಕ್ಯಾನ್‌ಗೆ ಪರಿವರ್ತಿಸಿದಂತೆ ಫಲಿತಾಂಶವು ಕಷ್ಟಕರವಾದ, ವಿರುದ್ಧಾರ್ಥಕ ಕೋಡ್ ಆಗಿದೆ. ನಾವು ಅದನ್ನು ಮಾಡಿದ್ದೇವೆ ಆದ್ದರಿಂದ ರಾಜ್ಯ ಯಂತ್ರದ ಬದಲಿಗೆ, ಪ್ರೋಗ್ರಾಮರ್ ಸಾಮಾನ್ಯ ಕಡ್ಡಾಯ ಕೋಡ್ ರೂಪದಲ್ಲಿ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಮುಖ್ಯ ಮಾರ್ಗವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಈ ಕಡ್ಡಾಯ ಕೋಡ್‌ನಲ್ಲಿ ನೀವು ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಡೇಟಾಕ್ಕಾಗಿ ಕಾಯುವ ಮೂಲಕ ಮರಣದಂಡನೆ ಅನುಕ್ರಮವನ್ನು ಅಡ್ಡಿಪಡಿಸಬೇಕಾದ ಸ್ಥಳಗಳನ್ನು ಸೇರಿಸಬೇಕಾಗಿದೆ, ಮರಣದಂಡನೆಯ ಸಂದರ್ಭವನ್ನು ಮತ್ತೊಂದು ಕೊರೂಟಿನ್ (ಗ್ರೀನ್ ಥ್ರೆಡ್) ಗೆ ರವಾನಿಸುತ್ತದೆ. ಈ ವಿಧಾನವು ನಾವು ಸತತವಾಗಿ ಜಟಿಲದಲ್ಲಿ ಹೆಚ್ಚು ನಿರೀಕ್ಷಿತ ಮಾರ್ಗವನ್ನು ಬರೆಯುತ್ತೇವೆ ಮತ್ತು ನಂತರ ಅದಕ್ಕೆ ಶಾಖೆಗಳನ್ನು ಸೇರಿಸುತ್ತೇವೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಹೋಲುತ್ತದೆ.
ಪರಿಣಾಮವಾಗಿ, ನಾವು TCP ಸ್ವೀಕರಿಸುವ ಒಂದು ಥ್ರೆಡ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ರೌಂಡ್-ರಾಬಿನ್ ಅನೇಕ ಕೆಲಸಗಾರರಿಗೆ TPC ಸಂಪರ್ಕವನ್ನು ರವಾನಿಸುತ್ತದೆ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕವು ಯಾವಾಗಲೂ ಒಂದು ಪ್ರೊಸೆಸರ್ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಮತ್ತು ಇದು ಸಂಗ್ರಹ ಸ್ನೇಹಿಯಾಗಿ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಮತ್ತು ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸಿಸ್ಟಂ TCP ಸ್ಟಾಕ್ ಅನ್ನು ನಿವಾರಿಸಲು ನಾವು ಸಣ್ಣ ಪ್ಯಾಕೆಟ್‌ಗಳ ಸಂಗ್ರಹವನ್ನು ಒಂದು ದೊಡ್ಡ ಪ್ಯಾಕೆಟ್‌ಗೆ ಸ್ವಲ್ಪ ಸುಧಾರಿಸಿದ್ದೇವೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಒಡಿಸ್ಸಿಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದಾಗ, ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ರದ್ದುಗೊಳಿಸಬಹುದು ಮತ್ತು ರೋಲ್‌ಬ್ಯಾಕ್ ಅನ್ನು ಕಳುಹಿಸಬಹುದು ಎಂಬ ಅರ್ಥದಲ್ಲಿ ನಾವು ವಹಿವಾಟಿನ ಪೂಲಿಂಗ್ ಅನ್ನು ಸುಧಾರಿಸಿದ್ದೇವೆ, ಅಂದರೆ ಯಾರೂ ವಿನಂತಿಗಾಗಿ ಕಾಯದಿದ್ದರೆ, ಒಡಿಸ್ಸಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಪ್ರಯತ್ನಿಸಬೇಡಿ ಎಂದು ಹೇಳುತ್ತದೆ. ಅಮೂಲ್ಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡಬಹುದಾದ ವಿನಂತಿಯನ್ನು ಪೂರೈಸಿಕೊಳ್ಳಿ.
ಮತ್ತು ಸಾಧ್ಯವಾದಾಗಲೆಲ್ಲಾ, ನಾವು ಅದೇ ಕ್ಲೈಂಟ್‌ಗೆ ಸಂಪರ್ಕಗಳನ್ನು ಇರಿಸುತ್ತೇವೆ. ಇದು application_name_add_host ಅನ್ನು ಮರುಸ್ಥಾಪಿಸುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ಇದು ಸಾಧ್ಯವಾದರೆ, ರೋಗನಿರ್ಣಯಕ್ಕೆ ಅಗತ್ಯವಿರುವ ನಿಯತಾಂಕಗಳನ್ನು ನಾವು ಹೆಚ್ಚುವರಿಯಾಗಿ ಮರುಹೊಂದಿಸಬೇಕಾಗಿಲ್ಲ.
ನಾವು Yandex.Cloud ನ ಹಿತಾಸಕ್ತಿಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ. ಮತ್ತು ನೀವು ನಿರ್ವಹಿಸಿದ PostgreSQL ಅನ್ನು ಬಳಸಿದರೆ ಮತ್ತು ಸಂಪರ್ಕ ಪೂಲರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದ್ದರೆ, ನೀವು ತಾರ್ಕಿಕ ಪ್ರತಿಕೃತಿಯನ್ನು ಬಾಹ್ಯವಾಗಿ ರಚಿಸಬಹುದು, ಅಂದರೆ, ನೀವು ಬಯಸಿದರೆ, ತಾರ್ಕಿಕ ಪ್ರತಿಕೃತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ನಮ್ಮನ್ನು ಬಿಡಿ. ಬೌನ್ಸರ್ ತಾರ್ಕಿಕ ಪುನರಾವರ್ತನೆಯ ಹರಿವನ್ನು ಹೊರಗೆ ಬಿಡುಗಡೆ ಮಾಡುವುದಿಲ್ಲ.
ಇದು ತಾರ್ಕಿಕ ಪ್ರತಿಕೃತಿಯನ್ನು ಹೊಂದಿಸುವ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಬಾಹ್ಯವಾಗಿ ಭೌತಿಕ ಪ್ರತಿಕೃತಿಗೆ ನಾವು ಬೆಂಬಲವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಕ್ಲೌಡ್ನಲ್ಲಿ, ಸಹಜವಾಗಿ, ಇದು ಅಸಾಧ್ಯ, ಏಕೆಂದರೆ ಕ್ಲಸ್ಟರ್ ತನ್ನ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ಮಾಹಿತಿಯನ್ನು ನೀಡುತ್ತದೆ. ಆದರೆ ನಿಮ್ಮ ಸ್ಥಾಪನೆಗಳಲ್ಲಿ, ಒಡಿಸ್ಸಿಯಲ್ಲಿನ ಸಂಪರ್ಕ ಪೂಲರ್ ಮೂಲಕ ನಿಮಗೆ ಭೌತಿಕ ಪುನರಾವರ್ತನೆಯ ಅಗತ್ಯವಿದ್ದರೆ, ಇದು ಸಾಧ್ಯ.
ಒಡಿಸ್ಸಿಯು PgBouncer ನೊಂದಿಗೆ ಸಂಪೂರ್ಣ ಹೊಂದಾಣಿಕೆಯ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಹೊಂದಿದೆ. ನಾವು ಒಂದೇ ಕನ್ಸೋಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಅದು ಬಹುತೇಕ ಒಂದೇ ರೀತಿಯ ಆಜ್ಞೆಗಳನ್ನು ರನ್ ಮಾಡುತ್ತದೆ. ಏನಾದರೂ ಕಾಣೆಯಾಗಿದ್ದರೆ, ಪುಲ್ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿ ಅಥವಾ GitHub ನಲ್ಲಿ ಕನಿಷ್ಠ ಸಮಸ್ಯೆಯನ್ನು ಕಳುಹಿಸಿ ಮತ್ತು ನಾವು ಅಗತ್ಯ ಆಜ್ಞೆಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತೇವೆ. ಆದರೆ ನಾವು ಈಗಾಗಲೇ PgBouncer ಕನ್ಸೋಲ್‌ನ ಮುಖ್ಯ ಕಾರ್ಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಮತ್ತು, ಸಹಜವಾಗಿ, ನಾವು ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ದೋಷವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಡೇಟಾಬೇಸ್ ವರದಿ ಮಾಡಿದ ದೋಷವನ್ನು ನಾವು ಹಿಂತಿರುಗಿಸುತ್ತೇವೆ. ನೀವು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಏಕೆ ಸೇರಿಸಲಾಗಿಲ್ಲ ಎಂಬುದರ ಕುರಿತು ನೀವು ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ ಮತ್ತು ಅದರಲ್ಲಿ ನಿಮ್ಮನ್ನು ಸೇರಿಸಲಾಗಿಲ್ಲ.
PgBouncer ಜೊತೆಗೆ ನಿಮಗೆ 100% ಹೊಂದಾಣಿಕೆಯ ಅಗತ್ಯವಿದ್ದರೆ ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತದೆ. ನಾವು ಸುರಕ್ಷಿತವಾಗಿರಲು ಬೌನ್ಸರ್ ರೀತಿಯಲ್ಲಿಯೇ ವರ್ತಿಸಬಹುದು.
ಅಭಿವೃದ್ಧಿ
ಒಡಿಸ್ಸಿ ಮೂಲ ಕೋಡ್ ಬಗ್ಗೆ ಕೆಲವು ಪದಗಳು.
ಉದಾಹರಣೆಗೆ, "ವಿರಾಮ / ಪುನರಾರಂಭ" ಆಜ್ಞೆಗಳಿವೆ. ಅವುಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾಬೇಸ್ ನವೀಕರಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ನೀವು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಅನ್ನು ನವೀಕರಿಸಬೇಕಾದರೆ, ನೀವು ಅದನ್ನು ಸಂಪರ್ಕ ಪೂಲರ್‌ನಲ್ಲಿ ವಿರಾಮಗೊಳಿಸಬಹುದು, pg_upgrade ಮಾಡಿ, ನಂತರ ಪುನರಾರಂಭಿಸಿ. ಮತ್ತು ಕ್ಲೈಂಟ್‌ನ ಕಡೆಯಿಂದ ಡೇಟಾಬೇಸ್ ಸರಳವಾಗಿ ನಿಧಾನವಾಗುತ್ತಿರುವಂತೆ ಕಾಣುತ್ತದೆ. ಈ ಕಾರ್ಯವನ್ನು ಸಮುದಾಯದ ಜನರು ನಮಗೆ ತಂದಿದ್ದಾರೆ. ಅವಳು ಇನ್ನೂ ಫ್ರೀಜ್ ಆಗಿಲ್ಲ, ಆದರೆ ಶೀಘ್ರದಲ್ಲೇ ಎಲ್ಲವೂ ಆಗಿರುತ್ತದೆ. (ಈಗಾಗಲೇ ಫ್ರೀಜ್ ಮಾಡಲಾಗಿದೆ)
- ಈಗಾಗಲೇ ಫ್ರೀಜ್ ಆಗಿದೆ
ಹೆಚ್ಚುವರಿಯಾಗಿ, PgBouncer ನಲ್ಲಿನ ಹೊಸ ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ SCRAM ದೃಢೀಕರಣಕ್ಕೆ ಬೆಂಬಲವಾಗಿದೆ, ಇದನ್ನು Yandex.Cloud ನಲ್ಲಿ ಕೆಲಸ ಮಾಡದ ವ್ಯಕ್ತಿಯಿಂದ ನಮಗೆ ತರಲಾಗಿದೆ. ಎರಡೂ ಸಂಕೀರ್ಣ ಕಾರ್ಯಚಟುವಟಿಕೆಗಳು ಮತ್ತು ಪ್ರಮುಖವಾಗಿವೆ.
ಆದ್ದರಿಂದ, ನೀವು ಈಗ ಸ್ವಲ್ಪ ಕೋಡ್ ಬರೆಯಲು ಬಯಸಿದರೆ, ಒಡಿಸ್ಸಿಯನ್ನು ಯಾವುದರಿಂದ ಮಾಡಲಾಗಿದೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ.
ನೀವು ಒಡಿಸ್ಸಿ ಮೂಲವನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಇದು ಎರಡು ಮುಖ್ಯ ಗ್ರಂಥಾಲಯಗಳನ್ನು ಅವಲಂಬಿಸಿದೆ. ಕಿವಿ ಗ್ರಂಥಾಲಯವು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಸಂದೇಶ ಪ್ರೋಟೋಕಾಲ್‌ನ ಅನುಷ್ಠಾನವಾಗಿದೆ. ಅಂದರೆ, ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನ ಸ್ಥಳೀಯ ಪ್ರೋಟೋ 3 ಪ್ರಮಾಣಿತ ಸಂದೇಶಗಳಾಗಿದ್ದು, ಮುಂಭಾಗದ ತುದಿಗಳು ಮತ್ತು ಹಿಂಭಾಗದ ತುದಿಗಳು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬಹುದು. ಅವುಗಳನ್ನು ಕಿವಿ ಗ್ರಂಥಾಲಯದಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ.
ಮೆಷಿನೇರಿಯಂ ಲೈಬ್ರರಿಯು ಥ್ರೆಡ್ ಅನುಷ್ಠಾನ ಗ್ರಂಥಾಲಯವಾಗಿದೆ. ಈ ಮೆಷಿನೇರಿಯಂನ ಒಂದು ಸಣ್ಣ ತುಣುಕನ್ನು ಅಸೆಂಬ್ಲಿ ಭಾಷೆಯಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ಆದರೆ ಗಾಬರಿಯಾಗಬೇಡಿ, ಕೇವಲ 15 ಸಾಲುಗಳಿವೆ.
ಒಡಿಸ್ಸಿ ವಾಸ್ತುಶಿಲ್ಪ. ಕೊರೊಟೀನ್‌ಗಳು ಚಾಲನೆಯಲ್ಲಿರುವ ಮುಖ್ಯ ಯಂತ್ರವಿದೆ. ಈ ಯಂತ್ರವು ಒಳಬರುವ TCP ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಮತ್ತು ಕಾರ್ಮಿಕರಲ್ಲಿ ಅವುಗಳನ್ನು ವಿತರಿಸಲು ಅಳವಡಿಸುತ್ತದೆ.
ಹಲವಾರು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಹ್ಯಾಂಡ್ಲರ್ ಒಬ್ಬ ಕೆಲಸಗಾರನೊಳಗೆ ಕೆಲಸ ಮಾಡಬಹುದು. ಪೂಲ್‌ನಲ್ಲಿ ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲದ ಸಂಪರ್ಕಗಳನ್ನು ಅಳಿಸಲು ಮುಖ್ಯ ಥ್ರೆಡ್ ಕನ್ಸೋಲ್ ಮತ್ತು ಕ್ರೋನ್ ಕಾರ್ಯಗಳ ಸಂಸ್ಕರಣೆಯನ್ನು ಸಹ ರನ್ ಮಾಡುತ್ತದೆ.
ಒಡಿಸ್ಸಿಯನ್ನು ಪ್ರಮಾಣಿತ ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಪರೀಕ್ಷಾ ಸೂಟ್ ಬಳಸಿ ಪರೀಕ್ಷಿಸಲಾಗುತ್ತದೆ. ನಾವು ಬೌನ್ಸರ್ ಮೂಲಕ ಮತ್ತು ಒಡಿಸ್ಸಿ ಮೂಲಕ ಇನ್‌ಸ್ಟಾಲ್-ಚೆಕ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತೇವೆ, ನಾವು ಶೂನ್ಯ ಡಿವಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ. ದಿನಾಂಕ ಫಾರ್ಮ್ಯಾಟಿಂಗ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಹಲವಾರು ಪರೀಕ್ಷೆಗಳಿವೆ, ಅದು ಬೌನ್ಸರ್ ಮತ್ತು ಒಡಿಸ್ಸಿಯಲ್ಲಿ ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಉತ್ತೀರ್ಣರಾಗುವುದಿಲ್ಲ.
ಇದರ ಜೊತೆಗೆ, ತಮ್ಮದೇ ಆದ ಪರೀಕ್ಷೆಯನ್ನು ಹೊಂದಿರುವ ಅನೇಕ ಚಾಲಕರು ಇವೆ. ಮತ್ತು ನಾವು ಒಡಿಸ್ಸಿಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಅವರ ಪರೀಕ್ಷೆಗಳನ್ನು ಬಳಸುತ್ತೇವೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಮ್ಮ ಕ್ಯಾಸ್ಕೇಡ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಿಂದಾಗಿ, ನಾವು ವಿವಿಧ ಬಂಡಲ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಬೇಕಾಗಿದೆ: ಪೋಸ್ಟ್ಗ್ರೆಸ್ + ಒಡಿಸ್ಸಿ, ಪಿಜಿಬೌನ್ಸರ್ + ಒಡಿಸ್ಸಿ, ಒಡಿಸ್ಸಿ + ಒಡಿಸ್ಸಿ ಕ್ಯಾಸ್ಕೇಡ್‌ನಲ್ಲಿರುವ ಯಾವುದೇ ಭಾಗಗಳಲ್ಲಿ ಒಡಿಸ್ಸಿ ಕೊನೆಗೊಂಡಿದ್ದರೆ, ಅದು ಇನ್ನೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ನಿರೀಕ್ಷಿಸಿದಂತೆ.
ರೇಕ್
ನಾವು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಒಡಿಸ್ಸಿಯನ್ನು ಬಳಸುತ್ತೇವೆ. ಮತ್ತು ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ನಾನು ಹೇಳಿದರೆ ಅದು ನ್ಯಾಯೋಚಿತವಲ್ಲ. ಇಲ್ಲ, ಅಂದರೆ, ಹೌದು, ಆದರೆ ಯಾವಾಗಲೂ ಅಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದೆ, ನಂತರ PostgreSQL ಪ್ರೊಫೆಷನಲ್‌ನಿಂದ ನಮ್ಮ ಸ್ನೇಹಿತರು ಬಂದು ನಮಗೆ ಮೆಮೊರಿ ಸೋರಿಕೆಯಾಗಿದೆ ಎಂದು ಹೇಳಿದರು. ಅವರು ನಿಜವಾಗಿಯೂ ಇದ್ದರು, ನಾವು ಅವುಗಳನ್ನು ಸರಿಪಡಿಸಿದ್ದೇವೆ. ಆದರೆ ಅದು ಸರಳವಾಗಿತ್ತು.
ನಂತರ ಸಂಪರ್ಕ ಪೂಲರ್ ಒಳಬರುವ TLS ಸಂಪರ್ಕಗಳನ್ನು ಮತ್ತು ಹೊರಹೋಗುವ TLS ಸಂಪರ್ಕಗಳನ್ನು ಹೊಂದಿದೆ ಎಂದು ನಾವು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ. ಮತ್ತು ಸಂಪರ್ಕಗಳಿಗೆ ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರಗಳು ಮತ್ತು ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರಗಳು ಬೇಕಾಗುತ್ತವೆ.
ಬೌನ್ಸರ್ ಮತ್ತು ಒಡಿಸ್ಸಿ ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಅವುಗಳ pcache ಮೂಲಕ ಪುನಃ ಓದಲಾಗುತ್ತದೆ, ಆದರೆ ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು pcache ನಿಂದ ಪುನಃ ಓದುವ ಅಗತ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ನಮ್ಮ ಸ್ಕೇಲೆಬಲ್ ಒಡಿಸ್ಸಿ ಅಂತಿಮವಾಗಿ ಈ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಓದುವ ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಸಾಗುತ್ತದೆ. ಇದು ನಮಗೆ ಆಶ್ಚರ್ಯವನ್ನುಂಟುಮಾಡಿತು, ಏಕೆಂದರೆ ಅವನು ವಿರೋಧಿಸಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಲಿಲ್ಲ. ಮೊದಲಿಗೆ ಇದು ರೇಖೀಯವಾಗಿ ಅಳೆಯಿತು, ಆದರೆ 20 ಒಳಬರುವ ಏಕಕಾಲಿಕ ಸಂಪರ್ಕಗಳ ನಂತರ ಈ ಸಮಸ್ಯೆಯು ಸ್ವತಃ ತೋರಿಸಿದೆ.
ಪ್ಲಗ್ ಮಾಡಬಹುದಾದ ದೃಢೀಕರಣ ವಿಧಾನವು ಅಂತರ್ನಿರ್ಮಿತ Lunux ಉಪಕರಣಗಳನ್ನು ಬಳಸಿಕೊಂಡು ದೃಢೀಕರಿಸುವ ಸಾಮರ್ಥ್ಯವಾಗಿದೆ. PgBouncer ನಲ್ಲಿ ಇದನ್ನು PAM ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಕಾಯಲು ಪ್ರತ್ಯೇಕ ಥ್ರೆಡ್ ಇರುವ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರಸ್ತುತ ಸಂಪರ್ಕಕ್ಕೆ ಸೇವೆ ಸಲ್ಲಿಸುವ ಮತ್ತು PAM ಥ್ರೆಡ್‌ನಲ್ಲಿ ವಾಸಿಸಲು ಅವರನ್ನು ಕೇಳುವ ಮುಖ್ಯ PgBouncer ಥ್ರೆಡ್ ಇದೆ.
ಒಂದು ಸರಳ ಕಾರಣಕ್ಕಾಗಿ ನಾವು ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಿಲ್ಲ. ನಮ್ಮಲ್ಲಿ ಸಾಕಷ್ಟು ಎಳೆಗಳಿವೆ. ನಮಗೆ ಇದು ಏಕೆ ಬೇಕು?
ನೀವು PAM ದೃಢೀಕರಣ ಮತ್ತು PAM ಅಲ್ಲದ ದೃಢೀಕರಣವನ್ನು ಹೊಂದಿದ್ದರೆ ಇದು ಅಂತಿಮವಾಗಿ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು, ನಂತರ PAM ದೃಢೀಕರಣದ ದೊಡ್ಡ ಅಲೆಯು PAM ಅಲ್ಲದ ದೃಢೀಕರಣವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ವಿಳಂಬಗೊಳಿಸುತ್ತದೆ. ನಾವು ಸರಿಪಡಿಸದಿರುವ ವಿಷಯಗಳಲ್ಲಿ ಇದೂ ಒಂದು. ಆದರೆ ನೀವು ಅದನ್ನು ಸರಿಪಡಿಸಲು ಬಯಸಿದರೆ, ನೀವು ಇದನ್ನು ಮಾಡಬಹುದು.
ಎಲ್ಲಾ ಒಳಬರುವ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಒಂದು ಥ್ರೆಡ್ ಅನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದು ಇನ್ನೊಂದು ಕುಂಟೆ. ತದನಂತರ ಅವರನ್ನು ಕಾರ್ಮಿಕರ ಪೂಲ್‌ಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಟಿಎಲ್‌ಎಸ್ ಹ್ಯಾಂಡ್ಶೇಕ್ ನಡೆಯುತ್ತದೆ.
ಬಾಟಮ್ ಲೈನ್, ನೀವು 20 ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕಗಳ ಸುಸಂಬದ್ಧ ತರಂಗವನ್ನು ಹೊಂದಿದ್ದರೆ, ಅವೆಲ್ಲವನ್ನೂ ಸ್ವೀಕರಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ libpq ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ವರದಿ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಇದು 000 ಸೆಕೆಂಡುಗಳು ಎಂದು ತೋರುತ್ತದೆ.
ಅವರೆಲ್ಲರೂ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಮೂದಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಅವರು ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಮೂದಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಘಾತೀಯವಲ್ಲದ ಮರುಪ್ರಯತ್ನದಿಂದ ಇದೆಲ್ಲವನ್ನೂ ಮುಚ್ಚಬಹುದು.
ನಾವು ಸ್ವೀಕರಿಸುವ TCP ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯನ್ನು ನಾವು ಥ್ರೊಟ್ಲಿಂಗ್ ಮಾಡಿದ್ದೇವೆ ಎಂಬ ಅಂಶದೊಂದಿಗೆ ನಾವು PgBouncer ನಿಂದ ಸ್ಕೀಮ್ ಅನ್ನು ಇಲ್ಲಿ ನಕಲಿಸಿದ್ದೇವೆ ಎಂಬ ತೀರ್ಮಾನಕ್ಕೆ ಬಂದಿದ್ದೇವೆ.
ನಾವು ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಿರುವುದನ್ನು ನಾವು ನೋಡಿದರೆ, ಆದರೆ ಅಂತಿಮವಾಗಿ ಅವರಿಗೆ ಹ್ಯಾಂಡ್ಶೇಕ್ ಮಾಡಲು ಸಮಯವಿಲ್ಲ, ನಾವು ಅವುಗಳನ್ನು ಸರದಿಯಲ್ಲಿ ಇರಿಸುತ್ತೇವೆ ಇದರಿಂದ ಅವರು CPU ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುವುದಿಲ್ಲ. ಬಂದ ಎಲ್ಲಾ ಸಂಪರ್ಕಗಳಿಗೆ ಏಕಕಾಲಿಕ ಹ್ಯಾಂಡ್ಶೇಕ್ ಅನ್ನು ನಿರ್ವಹಿಸದಿರಬಹುದು ಎಂಬ ಅಂಶಕ್ಕೆ ಇದು ಕಾರಣವಾಗುತ್ತದೆ. ಆದರೆ ಲೋಡ್ ಸಾಕಷ್ಟು ಭಾರವಾಗಿದ್ದರೂ ಸಹ ಕನಿಷ್ಠ ಯಾರಾದರೂ ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಮೂದಿಸುತ್ತಾರೆ.
ಮಾರ್ಗಸೂಚಿ
ಒಡಿಸ್ಸಿಯಲ್ಲಿ ನೀವು ಭವಿಷ್ಯದಲ್ಲಿ ಏನನ್ನು ನೋಡಲು ಬಯಸುತ್ತೀರಿ? ನಾವು ನಮ್ಮನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಏನು ಸಿದ್ಧರಿದ್ದೇವೆ ಮತ್ತು ಸಮುದಾಯದಿಂದ ನಾವು ಏನನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ?
ಆಗಸ್ಟ್ 2019 ರಂತೆ.
ಆಗಸ್ಟ್‌ನಲ್ಲಿ ಒಡಿಸ್ಸಿ ಮಾರ್ಗಸೂಚಿಯು ಹೀಗಿತ್ತು:
- ನಾವು SCRAM ಮತ್ತು PAM ದೃಢೀಕರಣವನ್ನು ಬಯಸಿದ್ದೇವೆ.
- ನಾವು ಓದುವ ವಿನಂತಿಗಳನ್ನು ಸ್ಟ್ಯಾಂಡ್‌ಬೈಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಬಯಸಿದ್ದೇವೆ.
- ನಾನು ಆನ್‌ಲೈನ್ ಮರುಪ್ರಾರಂಭಿಸಲು ಬಯಸುತ್ತೇನೆ.
- ಮತ್ತು ಸರ್ವರ್‌ನಲ್ಲಿ ವಿರಾಮಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯ.
ಈ ಮಾರ್ಗಸೂಚಿಯ ಅರ್ಧದಷ್ಟು ಪೂರ್ಣಗೊಂಡಿದೆ ಮತ್ತು ನಮ್ಮಿಂದಲ್ಲ. ಮತ್ತು ಇದು ಒಳ್ಳೆಯದು. ಆದ್ದರಿಂದ ಉಳಿದಿರುವದನ್ನು ಚರ್ಚಿಸೋಣ ಮತ್ತು ಹೆಚ್ಚಿನದನ್ನು ಸೇರಿಸೋಣ.
? ವಿನಂತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸದೆಯೇ ಗಾಳಿಯನ್ನು ಬಿಸಿಮಾಡುವ ಪ್ರತಿಕೃತಿಗಳನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ಫೇಲ್‌ಓವರ್ ಮತ್ತು ಸ್ವಿಚ್‌ಓವರ್ ಒದಗಿಸಲು ನಮಗೆ ಅವರ ಅಗತ್ಯವಿದೆ. ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿದ್ದಲ್ಲಿ, ನಾನು ಅವುಗಳನ್ನು ಕೆಲವು ಉಪಯುಕ್ತ ಕೆಲಸಗಳೊಂದಿಗೆ ಆಕ್ರಮಿಸಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇನೆ. ಏಕೆಂದರೆ ನಾವು ಒಂದೇ ಸೆಂಟ್ರಲ್ ಪ್ರೊಸೆಸರ್‌ಗಳನ್ನು, ಅದೇ ಮೆಮೊರಿಯನ್ನು ವಿಭಿನ್ನವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಇಲ್ಲದಿದ್ದರೆ ಪ್ರತಿಕೃತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ.
ತಾತ್ವಿಕವಾಗಿ, ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ, 10 ರಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಸಂಪರ್ಕಿಸುವಾಗ ಸೆಷನ್_ಅಟ್ರಸ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಸಾಧ್ಯವಿದೆ. ನೀವು ಸಂಪರ್ಕದಲ್ಲಿರುವ ಎಲ್ಲಾ ಡೇಟಾಬೇಸ್ ಹೋಸ್ಟ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಬಹುದು ಮತ್ತು ನೀವು ಡೇಟಾಬೇಸ್‌ಗೆ ಏಕೆ ಹೋಗುತ್ತಿದ್ದೀರಿ ಎಂದು ಹೇಳಬಹುದು: ಬರೆಯಿರಿ ಅಥವಾ ಓದಲು ಮಾತ್ರ. ಮತ್ತು ಡ್ರೈವರ್ ಸ್ವತಃ ತಾನು ಇಷ್ಟಪಡುವ ಪಟ್ಟಿಯಲ್ಲಿ ಮೊದಲ ಹೋಸ್ಟ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತಾನೆ, ಇದು ಸೆಷನ್_ಅಟ್ರಸ್ನ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ.
ಆದರೆ ಈ ವಿಧಾನದ ಸಮಸ್ಯೆಯೆಂದರೆ ಅದು ಪುನರಾವರ್ತನೆಯ ವಿಳಂಬವನ್ನು ನಿಯಂತ್ರಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ಸೇವೆಗಾಗಿ ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲದ ಸಮಯದವರೆಗೆ ಹಿಂದುಳಿದಿರುವ ಕೆಲವು ಪ್ರತಿಕೃತಿಗಳನ್ನು ನೀವು ಹೊಂದಿರಬಹುದು. ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ಓದುವ ಪ್ರಶ್ನೆಗಳ ಪೂರ್ಣ-ವೈಶಿಷ್ಟ್ಯದ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು, ಓದಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ಓಡಿಸದಿರುವ ಒಡಿಸ್ಸಿಯ ಸಾಮರ್ಥ್ಯವನ್ನು ನಾವು ಮೂಲಭೂತವಾಗಿ ಬೆಂಬಲಿಸಬೇಕಾಗಿದೆ.
ಒಡಿಸ್ಸಿ ಕಾಲಕಾಲಕ್ಕೆ ಡೇಟಾಬೇಸ್‌ಗೆ ಹೋಗಬೇಕು ಮತ್ತು ಪ್ರಾಥಮಿಕದಿಂದ ಪ್ರತಿಕೃತಿ ದೂರವನ್ನು ಕೇಳಬೇಕು. ಮತ್ತು ಅದು ಮಿತಿ ಮೌಲ್ಯವನ್ನು ತಲುಪಿದ್ದರೆ, ಡೇಟಾಬೇಸ್‌ಗೆ ಹೊಸ ವಿನಂತಿಗಳನ್ನು ಅನುಮತಿಸಬೇಡಿ, ಅದು ಸಂಪರ್ಕಗಳನ್ನು ಮರು-ಪ್ರಾರಂಭಿಸಬೇಕಾಗಿದೆ ಎಂದು ಕ್ಲೈಂಟ್‌ಗೆ ತಿಳಿಸಿ ಮತ್ತು ವಿನಂತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮತ್ತೊಂದು ಹೋಸ್ಟ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿ. ಇದು ಡೇಟಾಬೇಸ್ ಪುನರಾವರ್ತನೆಯ ವಿಳಂಬವನ್ನು ತ್ವರಿತವಾಗಿ ಮರುಸ್ಥಾಪಿಸಲು ಮತ್ತು ವಿನಂತಿಯೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಮತ್ತೆ ಹಿಂತಿರುಗಲು ಅನುಮತಿಸುತ್ತದೆ.
ಅನುಷ್ಠಾನಕ್ಕೆ ಸಮಯ ಚೌಕಟ್ಟನ್ನು ನೀಡುವುದು ಕಷ್ಟ, ಏಕೆಂದರೆ ಅದು ತೆರೆದ ಮೂಲವಾಗಿದೆ. ಆದರೆ, PgBouncer ನ ನನ್ನ ಸಹೋದ್ಯೋಗಿಗಳಂತೆ 2,5 ವರ್ಷಗಳಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಒಡಿಸ್ಸಿಯಲ್ಲಿ ನಾನು ನೋಡಲು ಬಯಸುವ ವೈಶಿಷ್ಟ್ಯ ಇದು.
. ಈಗ ನೀವು ಸಿದ್ಧಪಡಿಸಿದ ಹೇಳಿಕೆಯನ್ನು ಎರಡು ರೀತಿಯಲ್ಲಿ ರಚಿಸಬಹುದು. ಮೊದಲಿಗೆ, ನೀವು SQL ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು, ಅವುಗಳೆಂದರೆ "ತಯಾರಿಸಲಾಗಿದೆ". ಈ SQL ಆಜ್ಞೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಬೌನ್ಸರ್ ಬದಿಯಲ್ಲಿರುವ SQL ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಾವು ಕಲಿಯಬೇಕಾಗಿದೆ. ಇದು ಓವರ್‌ಕಿಲ್ ಆಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಇದು ಓವರ್‌ಕಿಲ್ ಆಗಿದೆ, ಏಕೆಂದರೆ ನಮಗೆ ಸಂಪೂರ್ಣ ಪಾರ್ಸರ್ ಅಗತ್ಯವಿದೆ. ನಾವು ಪ್ರತಿ SQL ಆಜ್ಞೆಯನ್ನು ಪಾರ್ಸ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಆದರೆ ಪ್ರೋಟೋ 3 ನಲ್ಲಿ ಸಂದೇಶ ಪ್ರೋಟೋಕಾಲ್ ಮಟ್ಟದಲ್ಲಿ ಸಿದ್ಧಪಡಿಸಿದ ಹೇಳಿಕೆ ಇದೆ. ಮತ್ತು ಸಿದ್ಧಪಡಿಸಿದ ಹೇಳಿಕೆಯನ್ನು ರಚಿಸಲಾಗುತ್ತಿದೆ ಎಂಬ ಮಾಹಿತಿಯು ರಚನಾತ್ಮಕ ರೂಪದಲ್ಲಿ ಬಂದಾಗ ಇದು ಸ್ಥಳವಾಗಿದೆ. ಮತ್ತು ಕೆಲವು ಸರ್ವರ್ ಸಂಪರ್ಕದಲ್ಲಿ ಕ್ಲೈಂಟ್ ಸಿದ್ಧಪಡಿಸಿದ ಹೇಳಿಕೆಗಳನ್ನು ರಚಿಸಲು ಕೇಳಿದ ತಿಳುವಳಿಕೆಯನ್ನು ನಾವು ಬೆಂಬಲಿಸಬಹುದು. ಮತ್ತು ವಹಿವಾಟು ಮುಚ್ಚಿದ್ದರೂ ಸಹ, ನಾವು ಇನ್ನೂ ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ನಡುವೆ ಸಂಪರ್ಕವನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗಿದೆ.
ಆದರೆ ಇಲ್ಲಿ ಸಂವಾದದಲ್ಲಿ ವ್ಯತ್ಯಾಸವು ಉದ್ಭವಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಯಾವ ರೀತಿಯ ಸಿದ್ಧಪಡಿಸಿದ ಹೇಳಿಕೆಗಳನ್ನು ರಚಿಸಿದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಈ ಸರ್ವರ್ ಸಂಪರ್ಕವನ್ನು ರಚಿಸಿದ ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳ ನಡುವೆ ಸರ್ವರ್ ಸಂಪರ್ಕವನ್ನು ಹಂಚಿಕೊಳ್ಳಬೇಕು ಎಂದು ಯಾರಾದರೂ ಹೇಳುತ್ತಾರೆ, ಅಂದರೆ, ಅಂತಹ ಸಿದ್ಧಪಡಿಸಿದ ಹೇಳಿಕೆಯನ್ನು ಯಾರು ರಚಿಸಿದ್ದಾರೆ.
ಮತ್ತೊಂದು ಸರ್ವರ್ ಸಂಪರ್ಕದಲ್ಲಿ ಈಗಾಗಲೇ ಅಂತಹ ಸಿದ್ಧಪಡಿಸಿದ ಹೇಳಿಕೆಯನ್ನು ರಚಿಸಿದ ಕ್ಲೈಂಟ್ ನಿಮ್ಮ ಬಳಿಗೆ ಬಂದರೆ, ಅದನ್ನು ಅವನಿಗೆ ರಚಿಸಿ ಎಂದು ಆಂಡ್ರೆಸ್ ಫ್ರೆಂಡ್ ಹೇಳಿದರು. ಆದರೆ ಕ್ಲೈಂಟ್ ಬದಲಿಗೆ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಸ್ವಲ್ಪ ತಪ್ಪಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬರೆಯುವ ಡೆವಲಪರ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ, ಅವನಿಗೆ ಸರಳವಾಗಿ ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕವನ್ನು ನೀಡಿದರೆ ಅದು ಅನುಕೂಲಕರವಾಗಿರುತ್ತದೆ. ಅಂತಹ ಸಿದ್ಧಪಡಿಸಿದ ಪ್ರಶ್ನೆ ಇದೆ.
ಮತ್ತು ನಾವು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾದ ಇನ್ನೊಂದು ವೈಶಿಷ್ಟ್ಯ. ನಾವು ಈಗ PgBouncer ನೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಸರಾಸರಿ ಪ್ರಶ್ನೆ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು. ಆದರೆ ಸರಾಸರಿ ಸಮಯ ಆಸ್ಪತ್ರೆಯಲ್ಲಿ ಸರಾಸರಿ ತಾಪಮಾನ: ಕೆಲವು ಶೀತ, ಕೆಲವು ಬೆಚ್ಚಗಿರುತ್ತದೆ - ಸರಾಸರಿ, ಎಲ್ಲರೂ ಆರೋಗ್ಯಕರ. ಇದು ಸತ್ಯವಲ್ಲ.
ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುವ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಹೆಚ್ಚು ಸ್ವೀಕಾರಾರ್ಹವಾಗಿಸುವ ನಿಧಾನ ಪ್ರಶ್ನೆಗಳಿವೆ ಎಂದು ಸೂಚಿಸುವ ಶೇಕಡಾವಾರುಗಳಿಗೆ ನಾವು ಬೆಂಬಲವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗಿದೆ.
ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ ನನಗೆ ಆವೃತ್ತಿ 1.0 ಬೇಕು (ಆವೃತ್ತಿ 1.1 ಈಗಾಗಲೇ ಬಿಡುಗಡೆಯಾಗಿದೆ). ವಾಸ್ತವವಾಗಿ ಒಡಿಸ್ಸಿ ಈಗ ಆವೃತ್ತಿ 1.0rc ನಲ್ಲಿದೆ, ಅಂದರೆ ಬಿಡುಗಡೆ ಅಭ್ಯರ್ಥಿ. ಮತ್ತು ನಾನು ಪಟ್ಟಿ ಮಾಡಿದ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಮೆಮೊರಿ ಸೋರಿಕೆ ಹೊರತುಪಡಿಸಿ, ಅದೇ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಸರಿಪಡಿಸಲಾಗಿದೆ.
ಆವೃತ್ತಿ 1.0 ನಮಗೆ ಅರ್ಥವೇನು? ನಾವು ಒಡಿಸ್ಸಿಯನ್ನು ನಮ್ಮ ನೆಲೆಗಳಿಗೆ ಹೊರತರುತ್ತಿದ್ದೇವೆ. ಇದು ಈಗಾಗಲೇ ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿದೆ, ಆದರೆ ಅದು ಸೆಕೆಂಡಿಗೆ 1 ವಿನಂತಿಗಳ ಹಂತವನ್ನು ತಲುಪಿದಾಗ, ಇದು ಬಿಡುಗಡೆಯ ಆವೃತ್ತಿಯಾಗಿದೆ ಮತ್ತು ಇದು 000 ಎಂದು ಕರೆಯಬಹುದಾದ ಆವೃತ್ತಿಯಾಗಿದೆ ಎಂದು ನಾವು ಹೇಳಬಹುದು.
ಸಮುದಾಯದ ಹಲವಾರು ಜನರು ಆವೃತ್ತಿ 1.0 ನಲ್ಲಿ ವಿರಾಮ ಮತ್ತು SCRAM ಸೇರಿವೆ ಎಂದು ಕೇಳಿದ್ದಾರೆ. ಆದರೆ ಇದರರ್ಥ ನಾವು ಮುಂದಿನ ಆವೃತ್ತಿಯನ್ನು ಉತ್ಪಾದನೆಗೆ ಹೊರತರಬೇಕಾಗಿದೆ, ಏಕೆಂದರೆ SCRAM ಅಥವಾ ವಿರಾಮವನ್ನು ಇನ್ನೂ ಕೊಲ್ಲಲಾಗಿಲ್ಲ. ಆದರೆ, ಹೆಚ್ಚಾಗಿ, ಈ ಸಮಸ್ಯೆಯನ್ನು ತ್ವರಿತವಾಗಿ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ.
ನಿಮ್ಮ ಪುಲ್ ವಿನಂತಿಗಾಗಿ ನಾನು ಕಾಯುತ್ತಿದ್ದೇನೆ. ಬೌನ್ಸರ್ನಲ್ಲಿ ನಿಮಗೆ ಯಾವ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂದು ಕೇಳಲು ನಾನು ಬಯಸುತ್ತೇನೆ. ಅವುಗಳನ್ನು ಚರ್ಚಿಸೋಣ. ಬಹುಶಃ ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ನಾವು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು.
ಇದು ನನ್ನ ಭಾಗದ ಅಂತ್ಯ, ನಾನು ನಿಮ್ಮ ಮಾತನ್ನು ಕೇಳಲು ಬಯಸುತ್ತೇನೆ. ಧನ್ಯವಾದ!
ಪ್ರಶ್ನೆಗಳು
ನಾನು ನನ್ನದೇ ಅಪ್ಲಿಕೇಶನ್_ಹೆಸರನ್ನು ಹೊಂದಿಸಿದರೆ, ಒಡಿಸ್ಸಿಯಲ್ಲಿನ ವಹಿವಾಟು ಪೂಲಿಂಗ್ ಸೇರಿದಂತೆ ಅದನ್ನು ಸರಿಯಾಗಿ ಫಾರ್ವರ್ಡ್ ಮಾಡಲಾಗುತ್ತದೆಯೇ?
ಒಡಿಸ್ಸಿ ಅಥವಾ ಬೌನ್ಸರ್?
ಒಡಿಸ್ಸಿಯಲ್ಲಿ. ಬೌನ್ಸರ್ನಲ್ಲಿ ಅದನ್ನು ಎಸೆಯಲಾಗುತ್ತದೆ.
ನಾವು ಒಂದು ಸೆಟ್ ಮಾಡುತ್ತೇವೆ.
ಮತ್ತು ನನ್ನ ನಿಜವಾದ ಸಂಪರ್ಕವು ಇತರ ಸಂಪರ್ಕಗಳ ಮೇಲೆ ಹಾರಿದರೆ, ಅದು ರವಾನೆಯಾಗುತ್ತದೆಯೇ?
ಪಟ್ಟಿಯಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡಲಾದ ಎಲ್ಲಾ ನಿಯತಾಂಕಗಳ ಒಂದು ಸೆಟ್ ಅನ್ನು ನಾವು ಮಾಡುತ್ತೇವೆ. ಅಪ್ಲಿಕೇಶನ್_ಹೆಸರು ಈ ಪಟ್ಟಿಯಲ್ಲಿದೆಯೇ ಎಂದು ನನಗೆ ಹೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಾನು ಅವನನ್ನು ಅಲ್ಲಿ ನೋಡಿದ್ದೇನೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನಾವು ಒಂದೇ ರೀತಿಯ ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ. ಒಂದು ವಿನಂತಿಯೊಂದಿಗೆ, ಪ್ರಾರಂಭದ ಸಮಯದಲ್ಲಿ ಕ್ಲೈಂಟ್ ಸ್ಥಾಪಿಸಿದ ಎಲ್ಲವನ್ನೂ ಸೆಟ್ ಮಾಡುತ್ತದೆ.
ಆಂಡ್ರೇ, ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ಉತ್ತಮ ವರದಿ! ಒಡಿಸ್ಸಿ ಪ್ರತಿ ನಿಮಿಷವೂ ವೇಗವಾಗಿ ಮತ್ತು ವೇಗವಾಗಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿದೆ ಎಂದು ನನಗೆ ಖುಷಿಯಾಗಿದೆ. ನಾನು ಹೀಗೆಯೇ ಮುಂದುವರಿಯಲು ಬಯಸುತ್ತೇನೆ. ಬಹು ಡೇಟಾ-ಮೂಲ ಸಂಪರ್ಕವನ್ನು ಹೊಂದಲು ನಾವು ಈಗಾಗಲೇ ನಿಮ್ಮನ್ನು ಕೇಳಿದ್ದೇವೆ ಇದರಿಂದ ಒಡಿಸ್ಸಿಯು ವಿವಿಧ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಸಂಪರ್ಕಿಸಬಹುದು, ಅಂದರೆ ಮಾಸ್ಟರ್ ಸ್ಲೇವ್, ಮತ್ತು ವಿಫಲವಾದ ನಂತರ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊಸ ಮಾಸ್ಟರ್‌ಗೆ ಸಂಪರ್ಕಿಸಬಹುದು.
ಹೌದು, ನಾನು ಈ ಚರ್ಚೆಯನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತೇನೆ. ಈಗ ಹಲವಾರು ಸಂಗ್ರಹಣೆಗಳಿವೆ. ಆದರೆ ಅವುಗಳ ನಡುವೆ ಯಾವುದೇ ಬದಲಾವಣೆ ಇಲ್ಲ. ನಮ್ಮ ಕಡೆಯಲ್ಲಿ, ಸರ್ವರ್ ಇನ್ನೂ ಜೀವಂತವಾಗಿದೆ ಎಂದು ನಾವು ಸಮೀಕ್ಷೆ ಮಾಡಬೇಕು ಮತ್ತು ವೈಫಲ್ಯ ಸಂಭವಿಸಿದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು, ಅವರು pg_recovery ಎಂದು ಕರೆಯುತ್ತಾರೆ. ನಾವು ಯಜಮಾನನ ಬಳಿಗೆ ಬಂದಿಲ್ಲ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಪ್ರಮಾಣಿತ ಮಾರ್ಗವಿದೆ. ಮತ್ತು ನಾವು ತಪ್ಪುಗಳಿಂದ ಹೇಗಾದರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು ಅಥವಾ ಏನು? ಅಂದರೆ, ಕಲ್ಪನೆಯು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ಅದನ್ನು ಚರ್ಚಿಸಲಾಗುತ್ತಿದೆ. ಹೆಚ್ಚಿನ ಕಾಮೆಂಟ್‌ಗಳನ್ನು ಬರೆಯಿರಿ. ನೀವು ಸಿ ತಿಳಿದಿರುವ ಕೆಲಸಗಾರರನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ಅದ್ಭುತವಾಗಿದೆ.
ಪ್ರತಿಕೃತಿಗಳಾದ್ಯಂತ ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವ ವಿಷಯವು ನಮಗೆ ಆಸಕ್ತಿಯನ್ನು ಹೊಂದಿದೆ, ಏಕೆಂದರೆ ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಪ್ರತಿಕೃತಿಯ ಕ್ಲಸ್ಟರ್‌ಗಳ ಅಳವಡಿಕೆಯನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳಗೊಳಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ. ಆದರೆ ಇಲ್ಲಿ ನಾನು ಹೆಚ್ಚಿನ ಕಾಮೆಂಟ್‌ಗಳನ್ನು ಬಯಸುತ್ತೇನೆ, ಅಂದರೆ ಅದನ್ನು ಹೇಗೆ ಮಾಡುವುದು, ಅದನ್ನು ಹೇಗೆ ಉತ್ತಮವಾಗಿ ಮಾಡುವುದು.
ಪ್ರಶ್ನೆಯು ಪ್ರತಿಕೃತಿಗಳ ಬಗ್ಗೆಯೂ ಇದೆ. ನೀವು ಮಾಸ್ಟರ್ ಮತ್ತು ಹಲವಾರು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಮತ್ತು ಅವರು ಸಂಪರ್ಕಗಳಿಗಾಗಿ ಮಾಸ್ಟರ್ಗಿಂತ ಕಡಿಮೆ ಬಾರಿ ಪ್ರತಿಕೃತಿಗೆ ಹೋಗುತ್ತಾರೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಏಕೆಂದರೆ ಅವುಗಳು ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಡೇಟಾದಲ್ಲಿನ ವ್ಯತ್ಯಾಸವು ನಿಮ್ಮ ವ್ಯವಹಾರವನ್ನು ತೃಪ್ತಿಪಡಿಸದಿರಬಹುದು ಮತ್ತು ಅದನ್ನು ಪುನರಾವರ್ತಿಸುವವರೆಗೆ ನೀವು ಅಲ್ಲಿಗೆ ಹೋಗುವುದಿಲ್ಲ ಎಂದು ನೀವು ಹೇಳಿದ್ದೀರಿ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನೀವು ದೀರ್ಘಕಾಲದವರೆಗೆ ಅಲ್ಲಿಗೆ ಹೋಗದಿದ್ದರೆ ಮತ್ತು ನಂತರ ಹೋಗಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಅಗತ್ಯವಿರುವ ಡೇಟಾ ತಕ್ಷಣವೇ ಲಭ್ಯವಿರುವುದಿಲ್ಲ. ಅಂದರೆ, ನಾವು ನಿರಂತರವಾಗಿ ಮಾಸ್ಟರ್‌ಗೆ ಹೋದರೆ, ಅಲ್ಲಿ ಸಂಗ್ರಹವು ಬೆಚ್ಚಗಾಗುತ್ತದೆ, ಆದರೆ ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ಸಂಗ್ರಹವು ಸ್ವಲ್ಪ ವಿಳಂಬವಾಗುತ್ತದೆ.
ಹೌದು ಇದು ನಿಜ. pcache ನಿಮಗೆ ಬೇಕಾದ ಡೇಟಾ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ, ನಿಜವಾದ ಸಂಗ್ರಹವು ನಿಮಗೆ ಬೇಕಾದ ಕೋಷ್ಟಕಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ, ಯೋಜನೆಗಳು ಪಾರ್ಸ್ ಮಾಡಿದ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ, ಏನೂ ಇರುವುದಿಲ್ಲ.
ಮತ್ತು ನೀವು ಕೆಲವು ರೀತಿಯ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿರುವಾಗ, ಮತ್ತು ನೀವು ಅಲ್ಲಿ ಹೊಸ ಪ್ರತಿಕೃತಿಯನ್ನು ಸೇರಿಸಿದಾಗ, ಅದು ಪ್ರಾರಂಭವಾದಾಗ, ಅದರಲ್ಲಿ ಎಲ್ಲವೂ ಕೆಟ್ಟದಾಗಿದೆ, ಅಂದರೆ ಅದು ಅದರ ಸಂಗ್ರಹವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
ನನಗೆ ಉಪಾಯ ಸಿಕ್ಕಿತು. ಮೊದಲ ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ಸಣ್ಣ ಶೇಕಡಾವಾರು ಪ್ರಶ್ನೆಗಳನ್ನು ಚಲಾಯಿಸುವುದು ಸರಿಯಾದ ವಿಧಾನವಾಗಿದೆ, ಇದು ಸಂಗ್ರಹವನ್ನು ಬೆಚ್ಚಗಾಗಿಸುತ್ತದೆ. ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಾವು ಮಾಸ್ಟರ್ಗಿಂತ 10 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚು ಹಿಂದುಳಿದಿರಬಾರದು ಎಂಬ ಸ್ಥಿತಿಯನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ಈ ಸ್ಥಿತಿಯನ್ನು ಒಂದು ತರಂಗದಲ್ಲಿ ಸೇರಿಸಲಾಗಿಲ್ಲ, ಆದರೆ ಕೆಲವು ಗ್ರಾಹಕರಿಗೆ ಸರಾಗವಾಗಿ.
ಹೌದು, ತೂಕವನ್ನು ಹೆಚ್ಚಿಸಿ.
ಇದು ಒಳ್ಳೆಯ ಉಪಾಯ. ಆದರೆ ಮೊದಲು ನಾವು ಈ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗಿದೆ. ಮೊದಲು ನಾವು ಆಫ್ ಮಾಡಬೇಕಾಗಿದೆ, ಮತ್ತು ನಂತರ ನಾವು ಹೇಗೆ ಆನ್ ಮಾಡಬೇಕೆಂದು ಯೋಚಿಸುತ್ತೇವೆ. ಸರಾಗವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಲು ಇದು ಉತ್ತಮ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ.
Nginx ಈ ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿದೆ slowly start ಸರ್ವರ್‌ಗಾಗಿ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ. ಮತ್ತು ಅವನು ಕ್ರಮೇಣ ಲೋಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತಾನೆ.
ಹೌದು, ಉತ್ತಮ ಉಪಾಯ, ನಾವು ಅದರ ಸುತ್ತಲೂ ಬಂದಾಗ ನಾವು ಅದನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ.
ಮೂಲ: www.habr.com