PostgreSQL ಗೆ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯನ್ನು ಒದಗಿಸುವುದು ಪ್ಯಾಟ್ರೋನಿಯ ಮುಖ್ಯ ಗುರಿಯಾಗಿದೆ. ಆದರೆ ಪತ್ರೋನಿ ಕೇವಲ ಟೆಂಪ್ಲೇಟ್ ಆಗಿದೆ, ಸಿದ್ಧ ಸಾಧನವಲ್ಲ (ಸಾಮಾನ್ಯವಾಗಿ, ದಸ್ತಾವೇಜನ್ನು ಹೇಳಲಾಗುತ್ತದೆ). ಮೊದಲ ನೋಟದಲ್ಲಿ, ಪರೀಕ್ಷಾ ಪ್ರಯೋಗಾಲಯದಲ್ಲಿ ಪ್ಯಾಟ್ರೋನಿಯನ್ನು ಸ್ಥಾಪಿಸಿದ ನಂತರ, ಅದು ಎಂತಹ ಉತ್ತಮ ಸಾಧನವಾಗಿದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮುರಿಯಲು ನಮ್ಮ ಪ್ರಯತ್ನಗಳನ್ನು ಎಷ್ಟು ಸುಲಭವಾಗಿ ನಿಭಾಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು. ಆದಾಗ್ಯೂ, ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ, ಎಲ್ಲವೂ ಯಾವಾಗಲೂ ಪರೀಕ್ಷಾ ಪ್ರಯೋಗಾಲಯದಲ್ಲಿ ಸುಂದರವಾಗಿ ಮತ್ತು ಸೊಗಸಾಗಿ ನಡೆಯುವುದಿಲ್ಲ.
ನಾನು ನನ್ನ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಹೇಳುತ್ತೇನೆ. ನಾನು ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಆಗಿ ಪ್ರಾರಂಭಿಸಿದೆ. ವೆಬ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದೆ. ನಾನು 2014 ರಿಂದ ಡೇಟಾ ಎಗ್ರೆಟ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ. ಕಂಪನಿಯು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಕ್ಷೇತ್ರದಲ್ಲಿ ಸಮಾಲೋಚನೆಯಲ್ಲಿ ತೊಡಗಿದೆ. ಮತ್ತು ನಾವು ನಿಖರವಾಗಿ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ಪ್ರತಿದಿನ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ, ಆದ್ದರಿಂದ ನಾವು ಕಾರ್ಯಾಚರಣೆಗೆ ಸಂಬಂಧಿಸಿದ ವಿಭಿನ್ನ ಪರಿಣತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಮತ್ತು 2018 ರ ಕೊನೆಯಲ್ಲಿ, ನಾವು ನಿಧಾನವಾಗಿ ಪತ್ರೋನಿಯನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಮತ್ತು ಕೆಲವು ಅನುಭವವನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ನಾವು ಅದನ್ನು ಹೇಗಾದರೂ ರೋಗನಿರ್ಣಯ ಮಾಡಿದ್ದೇವೆ, ಅದನ್ನು ಟ್ಯೂನ್ ಮಾಡಿದ್ದೇವೆ, ನಮ್ಮ ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳಿಗೆ ಬಂದಿದ್ದೇವೆ. ಮತ್ತು ಈ ವರದಿಯಲ್ಲಿ ನಾನು ಅವರ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ.
Postgres ಹೊರತುಪಡಿಸಿ, ನಾನು Linux ಅನ್ನು ಪ್ರೀತಿಸುತ್ತೇನೆ. ನಾನು ಅದರ ಸುತ್ತಲೂ ಇರಿ ಮತ್ತು ಅನ್ವೇಷಿಸಲು ಇಷ್ಟಪಡುತ್ತೇನೆ, ನಾನು ಕೋರ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಇಷ್ಟಪಡುತ್ತೇನೆ. ನಾನು ವರ್ಚುವಲೈಸೇಶನ್, ಕಂಟೈನರ್‌ಗಳು, ಡಾಕರ್, ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಪ್ರೀತಿಸುತ್ತೇನೆ. ಇದೆಲ್ಲವೂ ನನಗೆ ಆಸಕ್ತಿಯನ್ನುಂಟುಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಹಳೆಯ ನಿರ್ವಾಹಕರ ಅಭ್ಯಾಸಗಳು ಪರಿಣಾಮ ಬೀರುತ್ತವೆ. ನಾನು ಮೇಲ್ವಿಚಾರಣೆಯೊಂದಿಗೆ ವ್ಯವಹರಿಸಲು ಇಷ್ಟಪಡುತ್ತೇನೆ. ಮತ್ತು ನಾನು ಆಡಳಿತಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಪೋಸ್ಟ್ಗ್ರೆಸ್ ವಿಷಯಗಳನ್ನು ಪ್ರೀತಿಸುತ್ತೇನೆ, ಅಂದರೆ ಪ್ರತಿಕೃತಿ, ಬ್ಯಾಕಪ್. ಮತ್ತು ನನ್ನ ಬಿಡುವಿನ ವೇಳೆಯಲ್ಲಿ ನಾನು ಗೋದಲ್ಲಿ ಬರೆಯುತ್ತೇನೆ. ನಾನು ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರ್ ಅಲ್ಲ, ನಾನು ಗೋದಲ್ಲಿ ನನಗಾಗಿ ಬರೆಯುತ್ತೇನೆ. ಮತ್ತು ಇದು ನನಗೆ ಸಂತೋಷವನ್ನು ನೀಡುತ್ತದೆ.
- ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ HA (ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ) ಹೊಂದಿಲ್ಲ ಎಂದು ನಿಮ್ಮಲ್ಲಿ ಅನೇಕರಿಗೆ ತಿಳಿದಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. HA ಪಡೆಯಲು, ನೀವು ಏನನ್ನಾದರೂ ಸ್ಥಾಪಿಸಬೇಕು, ಅದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ, ಪ್ರಯತ್ನ ಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಪಡೆದುಕೊಳ್ಳಿ.
- ಹಲವಾರು ಉಪಕರಣಗಳು ಇವೆ ಮತ್ತು ಪಾಟ್ರೋನಿ ಅವುಗಳಲ್ಲಿ ಒಂದು HA ಅನ್ನು ಬಹಳ ತಂಪಾಗಿ ಮತ್ತು ಚೆನ್ನಾಗಿ ಪರಿಹರಿಸುತ್ತದೆ. ಆದರೆ ಎಲ್ಲವನ್ನೂ ಪರೀಕ್ಷಾ ಪ್ರಯೋಗಾಲಯದಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಅದನ್ನು ಚಲಾಯಿಸುವ ಮೂಲಕ, ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಾವು ನೋಡಬಹುದು, ನಾವು ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ಪುನರುತ್ಪಾದಿಸಬಹುದು, ಪತ್ರೋನಿ ಅವುಗಳನ್ನು ಹೇಗೆ ಪೂರೈಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ. ಮತ್ತು ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ.
- ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ, ನಾವು ವಿಭಿನ್ನ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ. ಮತ್ತು ನಾನು ಈ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ.
- ನಾವು ಅದನ್ನು ಹೇಗೆ ರೋಗನಿರ್ಣಯ ಮಾಡಿದ್ದೇವೆ, ನಾವು ಏನು ತಿರುಚಿದ್ದೇವೆ - ಅದು ನಮಗೆ ಸಹಾಯ ಮಾಡಿದೆಯೋ ಇಲ್ಲವೋ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
- Patroni ಅನ್ನು ಹೇಗೆ ಸ್ಥಾಪಿಸಬೇಕು ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ನೀವು ಇಂಟರ್ನೆಟ್ನಲ್ಲಿ Google ಮಾಡಬಹುದು, ಅದು ಹೇಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಅದನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನೀವು ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ಗಳನ್ನು ನೋಡಬಹುದು. ನೀವು ಯೋಜನೆಗಳು, ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು, ಇಂಟರ್ನೆಟ್ನಲ್ಲಿ ಅದರ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದು.
- ಬೇರೆಯವರ ಅನುಭವದ ಬಗ್ಗೆ ನಾನು ಮಾತನಾಡುವುದಿಲ್ಲ. ನಾವು ಎದುರಿಸಿದ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಮಾತ್ರ ನಾನು ಮಾತನಾಡುತ್ತೇನೆ.
- ಮತ್ತು ನಾನು Patroni ಮತ್ತು PostgreSQL ನ ಹೊರಗಿನ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಸಮತೋಲನಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಸಮಸ್ಯೆಗಳಿದ್ದರೆ, ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಕುಸಿದಾಗ, ನಾನು ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ.
ಮತ್ತು ನಾವು ನಮ್ಮ ವರದಿಯನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಒಂದು ಸಣ್ಣ ಹಕ್ಕು ನಿರಾಕರಣೆ.
ನಾವು ಎದುರಿಸಿದ ಈ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳು, ಕಾರ್ಯಾಚರಣೆಯ ಮೊದಲ 6-7-8 ತಿಂಗಳುಗಳಲ್ಲಿ ನಾವು ಅವುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಕಾಲಾನಂತರದಲ್ಲಿ, ನಾವು ನಮ್ಮ ಆಂತರಿಕ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳಿಗೆ ಬಂದಿದ್ದೇವೆ. ಮತ್ತು ನಮ್ಮ ಸಮಸ್ಯೆಗಳು ಕಣ್ಮರೆಯಾಯಿತು. ಆದ್ದರಿಂದ, ವರದಿಯನ್ನು ಸುಮಾರು ಆರು ತಿಂಗಳ ಹಿಂದೆ ಘೋಷಿಸಲಾಯಿತು, ಅದು ನನ್ನ ತಲೆಯಲ್ಲಿ ತಾಜಾವಾಗಿದ್ದಾಗ ಮತ್ತು ನಾನು ಎಲ್ಲವನ್ನೂ ಸಂಪೂರ್ಣವಾಗಿ ನೆನಪಿಸಿಕೊಂಡಿದ್ದೇನೆ.
ವರದಿಯನ್ನು ಸಿದ್ಧಪಡಿಸುವ ಸಂದರ್ಭದಲ್ಲಿ, ನಾನು ಈಗಾಗಲೇ ಹಳೆಯ ಮರಣೋತ್ತರ ಪರೀಕ್ಷೆಗಳನ್ನು ಎತ್ತಿದ್ದೇನೆ, ದಾಖಲೆಗಳನ್ನು ನೋಡಿದೆ. ಮತ್ತು ಸಮಸ್ಯೆಗಳ ವಿಶ್ಲೇಷಣೆಯ ಸಮಯದಲ್ಲಿ ಕೆಲವು ವಿವರಗಳನ್ನು ಮರೆತುಬಿಡಬಹುದು ಅಥವಾ ಕೆಲವು ವಿವರಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತನಿಖೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಕೆಲವು ಹಂತಗಳಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಗಣಿಸಲಾಗಿಲ್ಲ ಅಥವಾ ಕೆಲವು ಮಾಹಿತಿಯ ಕೊರತೆಯಿದೆ ಎಂದು ತೋರುತ್ತದೆ. ಹಾಗಾಗಿ ಈ ಕ್ಷಣಕ್ಕೆ ನನ್ನನ್ನು ಕ್ಷಮಿಸಲು ನಾನು ನಿಮ್ಮನ್ನು ಕೇಳುತ್ತೇನೆ.
ಪತ್ರೋನಿ ಎಂದರೇನು?
- ಇದು HA ಅನ್ನು ನಿರ್ಮಿಸಲು ಒಂದು ಟೆಂಪ್ಲೇಟ್ ಆಗಿದೆ. ಅದು ದಸ್ತಾವೇಜನ್ನು ಹೇಳುತ್ತದೆ. ಮತ್ತು ನನ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ, ಇದು ಅತ್ಯಂತ ಸರಿಯಾದ ಸ್ಪಷ್ಟೀಕರಣವಾಗಿದೆ. ಪತ್ರೋನಿ ನಿಮ್ಮ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಬೆಳ್ಳಿ ಗುಂಡು ಅಲ್ಲ, ಅಂದರೆ, ಅದನ್ನು ಕೆಲಸ ಮಾಡಲು ಮತ್ತು ಪ್ರಯೋಜನಗಳನ್ನು ತರಲು ನೀವು ಪ್ರಯತ್ನವನ್ನು ಮಾಡಬೇಕಾಗಿದೆ.
- ಇದು ಪ್ರತಿ ಡೇಟಾಬೇಸ್ ಸೇವೆಯಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾದ ಏಜೆಂಟ್ ಸೇವೆಯಾಗಿದೆ ಮತ್ತು ನಿಮ್ಮ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ಗಾಗಿ ಒಂದು ರೀತಿಯ init ಸಿಸ್ಟಮ್ ಆಗಿದೆ. ಇದು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ನಿಲ್ಲಿಸುತ್ತದೆ, ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಮರುಸಂರಚಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್ನ ಟೋಪೋಲಜಿಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ.
- ಅಂತೆಯೇ, ಕ್ಲಸ್ಟರ್ನ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು, ಅದರ ಪ್ರಸ್ತುತ ಪ್ರಾತಿನಿಧ್ಯವು ತೋರುತ್ತಿರುವಂತೆ, ಕೆಲವು ರೀತಿಯ ಸಂಗ್ರಹಣೆಯ ಅಗತ್ಯವಿದೆ. ಮತ್ತು ಈ ದೃಷ್ಟಿಕೋನದಿಂದ, ಪತ್ರೋನಿ ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುವ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಂಡರು. ಇದು ವಿತರಣಾ ಸಂರಚನಾ ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ಇದು Etcd, ಕಾನ್ಸುಲ್, ZooKeeper, ಅಥವಾ kubernetes Etcd ಆಗಿರಬಹುದು, ಅಂದರೆ ಈ ಆಯ್ಕೆಗಳಲ್ಲಿ ಒಂದಾಗಿರಬಹುದು.
- ಮತ್ತು ಪ್ಯಾಟ್ರೋನಿಯ ಒಂದು ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ ನೀವು ಬಾಕ್ಸ್‌ನಿಂದ ಆಟೋಫೈಲರ್ ಅನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಮಾತ್ರ ಪಡೆಯುತ್ತೀರಿ. ನಾವು ಹೋಲಿಕೆಗಾಗಿ Repmgr ಅನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ನಂತರ ಫೈಲರ್ ಅನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ. Repmgr ನೊಂದಿಗೆ, ನಾವು ಸ್ವಿಚ್ಓವರ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಆದರೆ ನಾವು ಆಟೋಫೈಲರ್ ಅನ್ನು ಬಯಸಿದರೆ, ನಾವು ಅದನ್ನು ಹೆಚ್ಚುವರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. Patroni ಈಗಾಗಲೇ ಬಾಕ್ಸ್ ಹೊರಗೆ ಆಟೋಫೈಲರ್ ಹೊಂದಿದೆ.
- ಮತ್ತು ಇನ್ನೂ ಅನೇಕ ವಿಷಯಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, ಸಂರಚನೆಗಳ ನಿರ್ವಹಣೆ, ಹೊಸ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಸುರಿಯುವುದು, ಬ್ಯಾಕ್ಅಪ್, ಇತ್ಯಾದಿ. ಆದರೆ ಇದು ವರದಿಯ ವ್ಯಾಪ್ತಿಯನ್ನು ಮೀರಿದೆ, ನಾನು ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ.
ಮತ್ತು ಒಂದು ಸಣ್ಣ ಫಲಿತಾಂಶವೆಂದರೆ ಪ್ಯಾಟ್ರೋನಿಯ ಮುಖ್ಯ ಕಾರ್ಯವು ಆಟೋಫೈಲ್ ಅನ್ನು ಉತ್ತಮವಾಗಿ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಮಾಡುವುದು ಇದರಿಂದ ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಕ್ಲಸ್ಟರ್ ಟೋಪೋಲಜಿಯಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ.
ಆದರೆ ನಾವು ಪತ್ರೋನಿಯನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನಮ್ಮ ವ್ಯವಸ್ಥೆಯು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತದೆ. ನಾವು ಮೊದಲು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಹೊಂದಿದ್ದರೆ, ನಂತರ ಪ್ಯಾಟ್ರೋನಿಯನ್ನು ಬಳಸುವಾಗ ನಾವು ಪ್ಯಾಟ್ರೋನಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಅಲ್ಲಿ ರಾಜ್ಯವನ್ನು ಸಂಗ್ರಹಿಸಿರುವ ಡಿಸಿಎಸ್ ಅನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ. ಮತ್ತು ಇದು ಹೇಗಾದರೂ ಕೆಲಸ ಮಾಡಬೇಕು. ಹಾಗಾದರೆ ಏನು ತಪ್ಪಾಗಬಹುದು?
ಮುರಿಯಬಹುದು:
- ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಮುರಿಯಬಹುದು. ಇದು ಮಾಸ್ಟರ್ ಅಥವಾ ಪ್ರತಿಕೃತಿಯಾಗಿರಬಹುದು, ಅವುಗಳಲ್ಲಿ ಒಂದು ವಿಫಲವಾಗಬಹುದು.
- ಪಾಟ್ರೋನಿ ಸ್ವತಃ ಮುರಿಯಬಹುದು.
- ರಾಜ್ಯವನ್ನು ಸಂಗ್ರಹಿಸಿರುವ DCS ಮುರಿಯಬಹುದು.
- ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಮುರಿಯಬಹುದು.
ಈ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ನಾನು ವರದಿಯಲ್ಲಿ ಪರಿಗಣಿಸುತ್ತೇನೆ.
ಪ್ರಕರಣಗಳು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದಂತೆ ನಾನು ಅವುಗಳನ್ನು ಪರಿಗಣಿಸುತ್ತೇನೆ, ಪ್ರಕರಣವು ಅನೇಕ ಅಂಶಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಎಂಬ ದೃಷ್ಟಿಕೋನದಿಂದ ಅಲ್ಲ. ಮತ್ತು ವ್ಯಕ್ತಿನಿಷ್ಠ ಭಾವನೆಗಳ ದೃಷ್ಟಿಕೋನದಿಂದ, ಈ ಪ್ರಕರಣವು ನನಗೆ ಕಷ್ಟಕರವಾಗಿತ್ತು, ಅದನ್ನು ಡಿಸ್ಅಸೆಂಬಲ್ ಮಾಡುವುದು ಕಷ್ಟಕರವಾಗಿತ್ತು ... ಮತ್ತು ಪ್ರತಿಯಾಗಿ, ಕೆಲವು ಪ್ರಕರಣವು ಹಗುರವಾಗಿತ್ತು ಮತ್ತು ಅದನ್ನು ಡಿಸ್ಅಸೆಂಬಲ್ ಮಾಡುವುದು ಸುಲಭವಾಗಿದೆ.
ಮತ್ತು ಮೊದಲ ಪ್ರಕರಣವು ಸುಲಭವಾಗಿದೆ. ನಾವು ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡಾಗ ಮತ್ತು ಅದೇ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಮ್ಮ DCS ಸಂಗ್ರಹಣೆಯನ್ನು ನಿಯೋಜಿಸಿದಾಗ ಇದು ಸಂಭವಿಸುತ್ತದೆ. ಇದು ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪು. ವಾಸ್ತುಶಿಲ್ಪಗಳನ್ನು ನಿರ್ಮಿಸುವಲ್ಲಿ ಇದು ತಪ್ಪು, ಅಂದರೆ, ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ವಿಭಿನ್ನ ಘಟಕಗಳನ್ನು ಸಂಯೋಜಿಸುವುದು.
ಆದ್ದರಿಂದ, ಒಂದು ಫೈಲರ್ ಇತ್ತು, ಏನಾಯಿತು ಎಂಬುದನ್ನು ನಿಭಾಯಿಸಲು ಹೋಗೋಣ.
ಮತ್ತು ಇಲ್ಲಿ ನಾವು ಫೈಲರ್ ಸಂಭವಿಸಿದಾಗ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇವೆ. ಅಂದರೆ, ಕ್ಲಸ್ಟರ್ ಸ್ಥಿತಿಯು ಬದಲಾದ ಸಮಯದಲ್ಲಿ ನಾವು ಈ ಕ್ಷಣದಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇವೆ.
ಆದರೆ ಫೈಲರ್ ಯಾವಾಗಲೂ ತತ್‌ಕ್ಷಣವಲ್ಲ, ಅಂದರೆ ಇದು ಯಾವುದೇ ಯೂನಿಟ್ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ, ಅದು ವಿಳಂಬವಾಗಬಹುದು. ಇದು ದೀರ್ಘಕಾಲ ಉಳಿಯಬಹುದು.
ಆದ್ದರಿಂದ, ಇದು ಪ್ರಾರಂಭದ ಸಮಯ ಮತ್ತು ಅಂತ್ಯದ ಸಮಯವನ್ನು ಹೊಂದಿದೆ, ಅಂದರೆ ಇದು ನಿರಂತರ ಘಟನೆಯಾಗಿದೆ. ಮತ್ತು ನಾವು ಎಲ್ಲಾ ಈವೆಂಟ್‌ಗಳನ್ನು ಮೂರು ಮಧ್ಯಂತರಗಳಾಗಿ ವಿಭಜಿಸುತ್ತೇವೆ: ನಾವು ಫೈಲರ್ ಮೊದಲು, ಫೈಲರ್ ಸಮಯದಲ್ಲಿ ಮತ್ತು ಫೈಲರ್ ನಂತರ ಸಮಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅಂದರೆ, ಈ ಟೈಮ್‌ಲೈನ್‌ನಲ್ಲಿ ನಾವು ಎಲ್ಲಾ ಘಟನೆಗಳನ್ನು ಪರಿಗಣಿಸುತ್ತೇವೆ.
ಮತ್ತು ಮೊದಲನೆಯದು, ಫೈಲರ್ ಸಂಭವಿಸಿದಾಗ, ಏನಾಯಿತು ಎಂಬುದರ ಕಾರಣವನ್ನು ನಾವು ಹುಡುಕುತ್ತೇವೆ, ಫೈಲರ್‌ಗೆ ಕಾರಣವಾದ ಕಾರಣ ಏನು.
ನಾವು ಲಾಗ್‌ಗಳನ್ನು ನೋಡಿದರೆ, ಅವು ಕ್ಲಾಸಿಕ್ ಪತ್ರೋನಿ ಲಾಗ್‌ಗಳಾಗಿರುತ್ತವೆ. ಸರ್ವರು ಯಜಮಾನರಾದರು, ಮತ್ತು ಯಜಮಾನನ ಪಾತ್ರವು ಈ ನೋಡ್‌ಗೆ ಹಾದುಹೋಗಿದೆ ಎಂದು ಅವರು ನಮಗೆ ಹೇಳುತ್ತಾರೆ. ಇಲ್ಲಿ ಅದನ್ನು ಹೈಲೈಟ್ ಮಾಡಲಾಗಿದೆ.
ಮುಂದೆ, ಫೈಲರ್ ಏಕೆ ಸಂಭವಿಸಿತು ಎಂಬುದನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು, ಅಂದರೆ ಮಾಸ್ಟರ್ ಪಾತ್ರವು ಒಂದು ನೋಡ್‌ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಚಲಿಸಲು ಕಾರಣವಾದ ಘಟನೆಗಳು ಸಂಭವಿಸಿದವು. ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ. ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವಲ್ಲಿ ನಾವು ದೋಷವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅವರು DCS ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಮಾಸ್ಟರ್ ಅರಿತುಕೊಂಡರು, ಅಂದರೆ, ಸಂವಹನದಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ಸಮಸ್ಯೆ ಇದೆ. ಮತ್ತು ಅವರು ಇನ್ನು ಮುಂದೆ ಮಾಸ್ಟರ್ ಆಗಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಹೇಳಿದರು ಮತ್ತು ರಾಜೀನಾಮೆ ನೀಡುತ್ತಾರೆ. ಈ ಸಾಲು "ತನ್ನನ್ನು ಕೆಳಗಿಳಿಸಿ" ನಿಖರವಾಗಿ ಹೇಳುತ್ತದೆ.
ಫೈಲರ್‌ನ ಹಿಂದಿನ ಘಟನೆಗಳನ್ನು ನಾವು ನೋಡಿದರೆ, ಮಾಂತ್ರಿಕನ ಮುಂದುವರಿಕೆಗೆ ಸಮಸ್ಯೆಯಾಗಿರುವ ಕಾರಣಗಳನ್ನು ನಾವು ಅಲ್ಲಿ ನೋಡಬಹುದು.
ನಾವು Patroni ಲಾಗ್‌ಗಳನ್ನು ನೋಡಿದರೆ, ನಮ್ಮಲ್ಲಿ ಬಹಳಷ್ಟು ದೋಷಗಳು, ಸಮಯ ಮೀರಿದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ, ಅಂದರೆ Patroni ಏಜೆಂಟ್ DCS ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಕಾನ್ಸುಲ್ ಏಜೆಂಟ್, ಇದು ಪೋರ್ಟ್ 8500 ನಲ್ಲಿ ಸಂವಹನ ನಡೆಸುತ್ತಿದೆ.
ಮತ್ತು ಇಲ್ಲಿರುವ ಸಮಸ್ಯೆಯೆಂದರೆ ಪ್ಯಾಟ್ರೋನಿ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಒಂದೇ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿದೆ. ಮತ್ತು ಕಾನ್ಸಲ್ ಸರ್ವರ್‌ಗಳನ್ನು ಅದೇ ನೋಡ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಯಿತು. ಸರ್ವರ್‌ನಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ರಚಿಸುವ ಮೂಲಕ, ನಾವು ಕಾನ್ಸುಲ್ ಸರ್ವರ್‌ಗಳಿಗೂ ಸಮಸ್ಯೆಗಳನ್ನು ಸೃಷ್ಟಿಸಿದ್ದೇವೆ. ಅವರು ಸರಿಯಾಗಿ ಸಂವಹನ ನಡೆಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.
ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ಹೊರೆ ಕಡಿಮೆಯಾದಾಗ, ನಮ್ಮ ಪತ್ರೋನಿ ಮತ್ತೆ ಏಜೆಂಟ್ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಸಾಧ್ಯವಾಯಿತು. ಸಾಮಾನ್ಯ ಕೆಲಸ ಪುನರಾರಂಭವಾಯಿತು. ಮತ್ತು ಅದೇ Pgdb-2 ಸರ್ವರ್ ಮತ್ತೆ ಮಾಸ್ಟರ್ ಆಯಿತು. ಅಂದರೆ, ಒಂದು ಸಣ್ಣ ಫ್ಲಿಪ್ ಇತ್ತು, ಅದರ ಕಾರಣದಿಂದಾಗಿ ನೋಡ್ ಮಾಸ್ಟರ್ನ ಅಧಿಕಾರವನ್ನು ತ್ಯಜಿಸಿತು, ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಮತ್ತೆ ತೆಗೆದುಕೊಂಡಿತು, ಅಂದರೆ, ಎಲ್ಲವೂ ಇದ್ದಂತೆ ಮರಳಿತು.
ಮತ್ತು ಇದನ್ನು ತಪ್ಪು ಎಚ್ಚರಿಕೆ ಎಂದು ಪರಿಗಣಿಸಬಹುದು ಅಥವಾ ಪತ್ರೋನಿ ಎಲ್ಲವನ್ನೂ ಸರಿಯಾಗಿ ಮಾಡಿದ್ದಾರೆ ಎಂದು ಪರಿಗಣಿಸಬಹುದು. ಅಂದರೆ, ಅವರು ಕ್ಲಸ್ಟರ್ ಸ್ಥಿತಿಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಅವರು ಅರಿತುಕೊಂಡರು ಮತ್ತು ಅವರ ಅಧಿಕಾರವನ್ನು ತೆಗೆದುಹಾಕಿದರು.
ಮತ್ತು ಇಲ್ಲಿ ಕಾನ್ಸುಲ್ ಸರ್ವರ್‌ಗಳು ಬೇಸ್‌ಗಳಂತೆಯೇ ಅದೇ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿರುವುದರಿಂದ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸಿದೆ. ಅಂತೆಯೇ, ಯಾವುದೇ ಲೋಡ್: ಇದು ಡಿಸ್ಕ್ ಅಥವಾ ಪ್ರೊಸೆಸರ್ಗಳ ಮೇಲಿನ ಲೋಡ್ ಆಗಿರಲಿ, ಇದು ಕಾನ್ಸುಲ್ ಕ್ಲಸ್ಟರ್ನೊಂದಿಗಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.
ಮತ್ತು ಅದು ಒಟ್ಟಿಗೆ ವಾಸಿಸಬಾರದು ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ನಾವು ಕಾನ್ಸುಲ್ಗಾಗಿ ಪ್ರತ್ಯೇಕ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ. ಮತ್ತು ಪತ್ರೋನಿ ಈಗಾಗಲೇ ಪ್ರತ್ಯೇಕ ಕಾನ್ಸುಲ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರು, ಅಂದರೆ, ಪ್ರತ್ಯೇಕ ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಕ್ಲಸ್ಟರ್, ಪ್ರತ್ಯೇಕ ಕಾನ್ಸುಲ್ ಕ್ಲಸ್ಟರ್ ಇತ್ತು. ಈ ಎಲ್ಲಾ ವಸ್ತುಗಳನ್ನು ಒಯ್ಯುವುದು ಮತ್ತು ಇಟ್ಟುಕೊಳ್ಳುವುದು ಹೇಗೆ ಎಂಬುದಕ್ಕೆ ಇದು ಮೂಲಭೂತ ಸೂಚನೆಯಾಗಿದೆ ಇದರಿಂದ ಅದು ಒಟ್ಟಿಗೆ ವಾಸಿಸುವುದಿಲ್ಲ.
ಒಂದು ಆಯ್ಕೆಯಾಗಿ, ನೀವು ttl, loop_wait, retry_timeout ನಿಯತಾಂಕಗಳನ್ನು ಟ್ವಿಸ್ಟ್ ಮಾಡಬಹುದು, ಅಂದರೆ ಈ ನಿಯತಾಂಕಗಳನ್ನು ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ಈ ಅಲ್ಪಾವಧಿಯ ಲೋಡ್ ಪೀಕ್‌ಗಳನ್ನು ಬದುಕಲು ಪ್ರಯತ್ನಿಸಿ. ಆದರೆ ಇದು ಅತ್ಯಂತ ಸೂಕ್ತವಾದ ಆಯ್ಕೆಯಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ಈ ಲೋಡ್ ಸಮಯಕ್ಕೆ ದೀರ್ಘವಾಗಿರುತ್ತದೆ. ಮತ್ತು ನಾವು ಈ ನಿಯತಾಂಕಗಳ ಈ ಮಿತಿಗಳನ್ನು ಮೀರಿ ಹೋಗುತ್ತೇವೆ. ಮತ್ತು ಅದು ನಿಜವಾಗಿಯೂ ಸಹಾಯ ಮಾಡದಿರಬಹುದು.
ಮೊದಲ ಸಮಸ್ಯೆ, ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಸರಳವಾಗಿದೆ. ನಾವು ತೆಗೆದುಕೊಂಡು ಡಿಸಿಎಸ್ ಅನ್ನು ಬೇಸ್ನೊಂದಿಗೆ ಹಾಕಿದ್ದೇವೆ, ನಮಗೆ ಸಮಸ್ಯೆ ಸಿಕ್ಕಿತು.
ಎರಡನೆಯ ಸಮಸ್ಯೆ ಮೊದಲನೆಯದಕ್ಕೆ ಹೋಲುತ್ತದೆ. ಡಿಸಿಎಸ್ ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ನಾವು ಮತ್ತೆ ಇಂಟರ್‌ಆಪರೇಬಿಲಿಟಿ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದಕ್ಕೆ ಇದು ಹೋಲುತ್ತದೆ.
ನಾವು ಲಾಗ್‌ಗಳನ್ನು ನೋಡಿದರೆ, ನಮಗೆ ಮತ್ತೆ ಸಂವಹನ ದೋಷವಿದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಮತ್ತು ನಾನು DCS ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಪತ್ರೋನಿ ಹೇಳುತ್ತಾರೆ ಆದ್ದರಿಂದ ಪ್ರಸ್ತುತ ಮಾಸ್ಟರ್ ಪ್ರತಿಕೃತಿ ಮೋಡ್‌ಗೆ ಹೋಗುತ್ತಾರೆ.
ಹಳೆಯ ಮಾಸ್ಟರ್ ಪ್ರತಿಕೃತಿಯಾಗುತ್ತಾನೆ, ಇಲ್ಲಿ ಪಾತ್ರೋನಿ ಕೆಲಸ ಮಾಡುತ್ತಾನೆ. ಇದು ವಹಿವಾಟು ಲಾಗ್ ಅನ್ನು ರಿವೈಂಡ್ ಮಾಡಲು pg_rewind ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಂತರ ಹೊಸ ಮಾಸ್ಟರ್ ಅನ್ನು ಹಿಡಿಯಲು ಹೊಸ ಮಾಸ್ಟರ್ಗೆ ಸಂಪರ್ಕಪಡಿಸುತ್ತದೆ. ಇಲ್ಲಿ ಪಾತ್ರೋನಿ ಅವರು ಮಾಡಬೇಕಾದಂತೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ.
ಇಲ್ಲಿ ನಾವು ಫೈಲರ್‌ನ ಹಿಂದಿನ ಸ್ಥಳವನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು, ಅಂದರೆ ನಮಗೆ ಫೈಲರ್ ಹೊಂದಲು ಕಾರಣವಾದ ದೋಷಗಳು. ಮತ್ತು ಈ ನಿಟ್ಟಿನಲ್ಲಿ, ಪ್ಯಾಟ್ರೋನಿ ಲಾಗ್ಗಳು ಕೆಲಸ ಮಾಡಲು ಸಾಕಷ್ಟು ಅನುಕೂಲಕರವಾಗಿದೆ. ಅವರು ಅದೇ ಸಂದೇಶಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ಮಧ್ಯಂತರದಲ್ಲಿ ಬರೆಯುತ್ತಾರೆ. ಮತ್ತು ನಾವು ಈ ಲಾಗ್‌ಗಳ ಮೂಲಕ ತ್ವರಿತವಾಗಿ ಸ್ಕ್ರಾಲ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಲಾಗ್ಗಳು ಬದಲಾಗಿವೆ ಎಂದು ಲಾಗ್‌ಗಳಿಂದ ನಾವು ನೋಡುತ್ತೇವೆ, ಅಂದರೆ ಕೆಲವು ಸಮಸ್ಯೆಗಳು ಪ್ರಾರಂಭವಾಗಿದೆ. ನಾವು ತ್ವರಿತವಾಗಿ ಈ ಸ್ಥಳಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತೇವೆ, ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡಿ.
ಮತ್ತು ಸಾಮಾನ್ಯ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಲಾಗ್ಗಳು ಈ ರೀತಿ ಕಾಣುತ್ತವೆ. ಬೀಗದ ಮಾಲೀಕರನ್ನು ಪರಿಶೀಲಿಸಲಾಗಿದೆ. ಮತ್ತು ಮಾಲೀಕರು, ಉದಾಹರಣೆಗೆ, ಬದಲಾಗಿದ್ದರೆ, ಕೆಲವು ಘಟನೆಗಳು ಸಂಭವಿಸಬಹುದು, ಅದು ಪ್ಯಾಟ್ರೋನಿ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು. ಆದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಚೆನ್ನಾಗಿದ್ದೇವೆ. ದೋಷಗಳು ಪ್ರಾರಂಭವಾದ ಸ್ಥಳವನ್ನು ನಾವು ಹುಡುಕುತ್ತಿದ್ದೇವೆ.
ಮತ್ತು ದೋಷಗಳು ಕಾಣಿಸಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದ ಹಂತಕ್ಕೆ ಸ್ಕ್ರಾಲ್ ಮಾಡಿದ ನಂತರ, ನಾವು ಸ್ವಯಂ-ಫೈಲ್ಓವರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಮತ್ತು ನಮ್ಮ ದೋಷಗಳು DCS ನೊಂದಿಗೆ ಸಂವಹನಕ್ಕೆ ಸಂಬಂಧಿಸಿರುವುದರಿಂದ ಮತ್ತು ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಕಾನ್ಸುಲ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ, ನಾವು ಕಾನ್ಸುಲ್ ಲಾಗ್‌ಗಳನ್ನು ಸಹ ನೋಡುತ್ತೇವೆ, ಅಲ್ಲಿ ಏನಾಯಿತು.
ಫೈಲರ್‌ನ ಸಮಯ ಮತ್ತು ಕಾನ್ಸುಲ್ ಲಾಗ್‌ಗಳಲ್ಲಿನ ಸಮಯವನ್ನು ಸರಿಸುಮಾರಾಗಿ ಹೋಲಿಸಿದಾಗ, ಕಾನ್ಸುಲ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ನಮ್ಮ ನೆರೆಹೊರೆಯವರು ಕಾನ್ಸುಲ್ ಕ್ಲಸ್ಟರ್ನ ಇತರ ಸದಸ್ಯರ ಅಸ್ತಿತ್ವವನ್ನು ಅನುಮಾನಿಸಲು ಪ್ರಾರಂಭಿಸಿರುವುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ.
ಮತ್ತು ನೀವು ಇತರ ಕಾನ್ಸುಲ್ ಏಜೆಂಟ್‌ಗಳ ಲಾಗ್‌ಗಳನ್ನು ನೋಡಿದರೆ, ಅಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ನೆಟ್ವರ್ಕ್ ಕುಸಿತವು ನಡೆಯುತ್ತಿದೆ ಎಂದು ನೀವು ನೋಡಬಹುದು. ಮತ್ತು ಕಾನ್ಸಲ್ ಕ್ಲಸ್ಟರ್ನ ಎಲ್ಲಾ ಸದಸ್ಯರು ಪರಸ್ಪರರ ಅಸ್ತಿತ್ವವನ್ನು ಅನುಮಾನಿಸುತ್ತಾರೆ. ಮತ್ತು ಇದು ಫೈಲರ್‌ಗೆ ಪ್ರಚೋದನೆಯಾಗಿತ್ತು.
ಈ ದೋಷಗಳ ಮೊದಲು ಏನಾಯಿತು ಎಂಬುದನ್ನು ನೀವು ನೋಡಿದರೆ, ಎಲ್ಲಾ ರೀತಿಯ ದೋಷಗಳಿವೆ ಎಂದು ನೀವು ನೋಡಬಹುದು, ಉದಾಹರಣೆಗೆ, ಗಡುವು, ಆರ್ಪಿಸಿ ಬಿದ್ದಿದೆ, ಅಂದರೆ, ಕಾನ್ಸುಲ್ ಕ್ಲಸ್ಟರ್ ಸದಸ್ಯರ ಪರಸ್ಪರ ಸಂವಹನದಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿ ಕೆಲವು ರೀತಿಯ ಸಮಸ್ಯೆಗಳಿವೆ. .
ಸರಳವಾದ ಉತ್ತರವೆಂದರೆ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಸರಿಪಡಿಸುವುದು. ಆದರೆ ವೇದಿಕೆಯ ಮೇಲೆ ನಿಂತ ನನಗೆ ಇದನ್ನು ಹೇಳುವುದು ಸುಲಭ. ಆದರೆ ಸಂದರ್ಭಗಳು ಯಾವಾಗಲೂ ಗ್ರಾಹಕರು ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಸರಿಪಡಿಸಲು ಶಕ್ತರಾಗಿರುವುದಿಲ್ಲ. ಅವರು DC ಯಲ್ಲಿ ವಾಸಿಸಬಹುದು ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಾಗದಿರಬಹುದು, ಉಪಕರಣದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಮತ್ತು ಆದ್ದರಿಂದ ಕೆಲವು ಇತರ ಆಯ್ಕೆಗಳು ಅಗತ್ಯವಿದೆ.
ಆಯ್ಕೆಗಳಿವೆ:
- ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ದಸ್ತಾವೇಜನ್ನು ಸಹ ಬರೆಯಲಾದ ಸರಳವಾದ ಆಯ್ಕೆಯು ಕಾನ್ಸುಲ್ ಪರಿಶೀಲನೆಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು, ಅಂದರೆ ಖಾಲಿ ಶ್ರೇಣಿಯನ್ನು ರವಾನಿಸುವುದು. ಮತ್ತು ನಾವು ಯಾವುದೇ ಚೆಕ್‌ಗಳನ್ನು ಬಳಸದಂತೆ ಕಾನ್ಸುಲ್ ಏಜೆಂಟ್‌ಗೆ ಹೇಳುತ್ತೇವೆ. ಈ ತಪಾಸಣೆಗಳೊಂದಿಗೆ, ನಾವು ಈ ನೆಟ್ವರ್ಕ್ ಬಿರುಗಾಳಿಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು ಮತ್ತು ಫೈಲರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ.
- ರಾಫ್ಟ್_ಮಲ್ಟಿಪ್ಲೈಯರ್ ಅನ್ನು ಎರಡು ಬಾರಿ ಪರಿಶೀಲಿಸುವುದು ಮತ್ತೊಂದು ಆಯ್ಕೆಯಾಗಿದೆ. ಇದು ಕಾನ್ಸುಲ್ ಸರ್ವರ್ನ ಪ್ಯಾರಾಮೀಟರ್ ಆಗಿದೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಇದನ್ನು 5 ಕ್ಕೆ ಹೊಂದಿಸಲಾಗಿದೆ. ಈ ಮೌಲ್ಯವನ್ನು ಸ್ಟೇಜಿಂಗ್ ಪರಿಸರಕ್ಕಾಗಿ ದಸ್ತಾವೇಜನ್ನು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ, ಇದು ಕಾನ್ಸುಲ್ ನೆಟ್ವರ್ಕ್ನ ಸದಸ್ಯರ ನಡುವಿನ ಸಂದೇಶದ ಆವರ್ತನದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ವಾಸ್ತವವಾಗಿ, ಈ ನಿಯತಾಂಕವು ಕಾನ್ಸುಲ್ ಕ್ಲಸ್ಟರ್ನ ಸದಸ್ಯರ ನಡುವಿನ ಸೇವಾ ಸಂವಹನದ ವೇಗವನ್ನು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಮತ್ತು ಉತ್ಪಾದನೆಗೆ, ಅದನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಈಗಾಗಲೇ ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ, ಇದರಿಂದಾಗಿ ನೋಡ್ಗಳು ಹೆಚ್ಚಾಗಿ ಸಂದೇಶಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತವೆ.
- ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಪ್ರಕ್ರಿಯೆ ಶೆಡ್ಯೂಲರ್‌ಗಾಗಿ ಇತರ ಪ್ರಕ್ರಿಯೆಗಳ ನಡುವೆ ಕಾನ್ಸುಲ್ ಪ್ರಕ್ರಿಯೆಗಳ ಆದ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದು ನಾವು ತಂದಿರುವ ಇನ್ನೊಂದು ಆಯ್ಕೆಯಾಗಿದೆ. ಅಂತಹ "ಉತ್ತಮ" ಪ್ಯಾರಾಮೀಟರ್ ಇದೆ, ಇದು ವೇಳಾಪಟ್ಟಿ ಮಾಡುವಾಗ ಓಎಸ್ ಶೆಡ್ಯೂಲರ್ ಮೂಲಕ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವ ಪ್ರಕ್ರಿಯೆಗಳ ಆದ್ಯತೆಯನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ನಾವು ಕಾನ್ಸುಲ್ ಏಜೆಂಟ್‌ಗಳಿಗೆ ಉತ್ತಮ ಮೌಲ್ಯವನ್ನು ಕಡಿಮೆ ಮಾಡಿದ್ದೇವೆ, ಅಂದರೆ. ಆದ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸಿತು ಆದ್ದರಿಂದ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಕಾನ್ಸುಲ್ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಕೆಲಸ ಮಾಡಲು ಮತ್ತು ಅವರ ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ನೀಡುತ್ತದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ನಮ್ಮ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದೆ.
- ಕಾನ್ಸುಲ್ ಅನ್ನು ಬಳಸದಿರುವುದು ಮತ್ತೊಂದು ಆಯ್ಕೆಯಾಗಿದೆ. ನನಗೆ Etcd ನ ದೊಡ್ಡ ಬೆಂಬಲಿಗನ ಸ್ನೇಹಿತನಿದ್ದಾನೆ. ಮತ್ತು ನಾವು ನಿಯಮಿತವಾಗಿ ಅವರೊಂದಿಗೆ ವಾದಿಸುತ್ತೇವೆ ಯಾವುದು ಉತ್ತಮ Etcd ಅಥವಾ ಕಾನ್ಸುಲ್. ಆದರೆ ಯಾವುದು ಉತ್ತಮ ಎಂಬುದಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ, ದತ್ತಸಂಚಯದೊಂದಿಗೆ ಪ್ರತಿ ನೋಡ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಏಜೆಂಟ್ ಅನ್ನು ಕಾನ್ಸುಲ್ ಹೊಂದಿದ್ದಾರೆ ಎಂದು ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಒಪ್ಪಿಕೊಳ್ಳುತ್ತೇವೆ. ಅಂದರೆ, ಕಾನ್ಸಲ್ ಕ್ಲಸ್ಟರ್ನೊಂದಿಗಿನ ಪತ್ರೋನಿಯ ಪರಸ್ಪರ ಕ್ರಿಯೆಯು ಈ ಏಜೆಂಟ್ ಮೂಲಕ ಹೋಗುತ್ತದೆ. ಮತ್ತು ಈ ಏಜೆಂಟ್ ಒಂದು ಅಡಚಣೆಯಾಗುತ್ತದೆ. ಏಜೆಂಟ್‌ಗೆ ಏನಾದರೂ ಸಂಭವಿಸಿದರೆ, ನಂತರ ಪತ್ರೋನಿ ಇನ್ನು ಮುಂದೆ ಕಾನ್ಸಲ್ ಕ್ಲಸ್ಟರ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮತ್ತು ಇದು ಸಮಸ್ಯೆಯಾಗಿದೆ. Etcd ಯೋಜನೆಯಲ್ಲಿ ಯಾವುದೇ ಏಜೆಂಟ್ ಇಲ್ಲ. Patroni ನೇರವಾಗಿ Etcd ಸರ್ವರ್‌ಗಳ ಪಟ್ಟಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು ಮತ್ತು ಈಗಾಗಲೇ ಅವರೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಬಹುದು. ಈ ನಿಟ್ಟಿನಲ್ಲಿ, ನೀವು ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ Etcd ಅನ್ನು ಬಳಸಿದರೆ, Etcd ಬಹುಶಃ ಕಾನ್ಸುಲ್‌ಗಿಂತ ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ. ಆದರೆ ನಮ್ಮ ಗ್ರಾಹಕರಲ್ಲಿ ನಾವು ಯಾವಾಗಲೂ ಕ್ಲೈಂಟ್ ಆಯ್ಕೆಮಾಡಿದ ಮತ್ತು ಬಳಸುವುದರ ಮೂಲಕ ಸೀಮಿತವಾಗಿರುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಬಹುಪಾಲು ಕಾನ್ಸಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ.
- ಮತ್ತು ಕೊನೆಯ ಅಂಶವೆಂದರೆ ನಿಯತಾಂಕ ಮೌಲ್ಯಗಳನ್ನು ಪರಿಷ್ಕರಿಸುವುದು. ನಮ್ಮ ಅಲ್ಪಾವಧಿಯ ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆಗಳು ಚಿಕ್ಕದಾಗಿರುತ್ತವೆ ಮತ್ತು ಈ ನಿಯತಾಂಕಗಳ ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗುಳಿಯುವುದಿಲ್ಲ ಎಂಬ ಭರವಸೆಯಲ್ಲಿ ನಾವು ಈ ನಿಯತಾಂಕಗಳನ್ನು ಹೆಚ್ಚಿಸಬಹುದು. ಈ ರೀತಿಯಾಗಿ ನಾವು ಕೆಲವು ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆಗಳು ಉಂಟಾದರೆ ಆಟೋಫೈಲ್‌ಗೆ ಪ್ಯಾಟ್ರೋನಿಯ ಆಕ್ರಮಣಶೀಲತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.
ಪತ್ರೋನಿಯನ್ನು ಬಳಸುವ ಅನೇಕರು ಈ ಆಜ್ಞೆಯೊಂದಿಗೆ ಪರಿಚಿತರಾಗಿದ್ದಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ಈ ಆಜ್ಞೆಯು ಕ್ಲಸ್ಟರ್ನ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಮತ್ತು ಮೊದಲ ನೋಟದಲ್ಲಿ, ಈ ಚಿತ್ರವು ಸಾಮಾನ್ಯವೆಂದು ತೋರುತ್ತದೆ. ನಮ್ಮಲ್ಲಿ ಮಾಸ್ಟರ್ ಇದ್ದಾರೆ, ನಮ್ಮಲ್ಲಿ ಪ್ರತಿಕೃತಿ ಇದೆ, ಯಾವುದೇ ಪ್ರತಿಕೃತಿ ವಿಳಂಬವಿಲ್ಲ. ಆದರೆ ಈ ಕ್ಲಸ್ಟರ್ ಮೂರು ನೋಡ್ಗಳನ್ನು ಹೊಂದಿರಬೇಕು, ಎರಡಲ್ಲ ಎಂದು ನಮಗೆ ತಿಳಿಯುವವರೆಗೂ ಈ ಚಿತ್ರವು ಸಾಮಾನ್ಯವಾಗಿದೆ.
ಅದರಂತೆ, ಆಟೋಫೈಲ್ ಇತ್ತು. ಮತ್ತು ಈ ಸ್ವಯಂ ಫೈಲ್ ನಂತರ, ನಮ್ಮ ಪ್ರತಿಕೃತಿ ಕಣ್ಮರೆಯಾಯಿತು. ಅವಳು ಏಕೆ ಕಣ್ಮರೆಯಾದಳು ಮತ್ತು ಅವಳನ್ನು ಮರಳಿ ಕರೆತರಬೇಕು, ಪುನಃಸ್ಥಾಪಿಸಬೇಕು ಎಂದು ನಾವು ಕಂಡುಹಿಡಿಯಬೇಕು. ಮತ್ತು ನಾವು ಮತ್ತೆ ಲಾಗ್‌ಗಳಿಗೆ ಹೋಗಿ ಮತ್ತು ನಾವು ಸ್ವಯಂ-ಫೈಲ್ಓವರ್ ಅನ್ನು ಏಕೆ ಹೊಂದಿದ್ದೇವೆ ಎಂದು ನೋಡುತ್ತೇವೆ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಎರಡನೇ ಪ್ರತಿಕೃತಿ ಮಾಸ್ಟರ್ ಆಯಿತು. ಇಲ್ಲಿ ಎಲ್ಲಾ ಸರಿ.
ಮತ್ತು ನಾವು ಬಿದ್ದ ಪ್ರತಿಕೃತಿಯನ್ನು ನೋಡಬೇಕಾಗಿದೆ ಮತ್ತು ಅದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿಲ್ಲ. ನಾವು Patroni ಲಾಗ್‌ಗಳನ್ನು ತೆರೆಯುತ್ತೇವೆ ಮತ್ತು pg_rewind ಹಂತದಲ್ಲಿ ಕ್ಲಸ್ಟರ್‌ಗೆ ಸಂಪರ್ಕಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಾವು ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ನೋಡುತ್ತೇವೆ. ಕ್ಲಸ್ಟರ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು, ನೀವು ವಹಿವಾಟು ಲಾಗ್ ಅನ್ನು ರಿವೈಂಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಮಾಸ್ಟರ್‌ನಿಂದ ಅಗತ್ಯವಿರುವ ವಹಿವಾಟು ಲಾಗ್ ಅನ್ನು ವಿನಂತಿಸಿ ಮತ್ತು ಮಾಸ್ಟರ್‌ನೊಂದಿಗೆ ಹಿಡಿಯಲು ಅದನ್ನು ಬಳಸಬೇಕು.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ವಹಿವಾಟು ಲಾಗ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ ಮತ್ತು ಪ್ರತಿಕೃತಿಯನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುವುದಿಲ್ಲ. ಅದರಂತೆ, ನಾವು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಅನ್ನು ದೋಷದೊಂದಿಗೆ ನಿಲ್ಲಿಸುತ್ತೇವೆ. ಮತ್ತು ಆದ್ದರಿಂದ ಇದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿಲ್ಲ.
ಅದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಏಕೆ ಇಲ್ಲ ಮತ್ತು ಏಕೆ ಲಾಗ್ಗಳು ಇರಲಿಲ್ಲ ಎಂಬುದನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ನಾವು ಹೊಸ ಮಾಸ್ಟರ್ಗೆ ಹೋಗುತ್ತೇವೆ ಮತ್ತು ಅವರು ಲಾಗ್ಗಳಲ್ಲಿ ಏನನ್ನು ಹೊಂದಿದ್ದಾರೆಂದು ನೋಡುತ್ತೇವೆ. pg_rewind ಮಾಡಿದಾಗ, ಚೆಕ್‌ಪಾಯಿಂಟ್ ಸಂಭವಿಸಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಮತ್ತು ಕೆಲವು ಹಳೆಯ ವಹಿವಾಟು ಲಾಗ್‌ಗಳನ್ನು ಸರಳವಾಗಿ ಮರುಹೆಸರಿಸಲಾಗಿದೆ. ಹಳೆಯ ಮಾಸ್ಟರ್ ಹೊಸ ಮಾಸ್ಟರ್ಗೆ ಸಂಪರ್ಕಿಸಲು ಮತ್ತು ಈ ಲಾಗ್‌ಗಳನ್ನು ಪ್ರಶ್ನಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಅವುಗಳನ್ನು ಈಗಾಗಲೇ ಮರುಹೆಸರಿಸಲಾಗಿದೆ, ಅವು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ.
ಈ ಘಟನೆಗಳು ಸಂಭವಿಸಿದಾಗ ನಾನು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ಹೋಲಿಸಿದೆ. ಮತ್ತು ಅಲ್ಲಿ ವ್ಯತ್ಯಾಸವು ಅಕ್ಷರಶಃ 150 ಮಿಲಿಸೆಕೆಂಡುಗಳು, ಅಂದರೆ, ಚೆಕ್‌ಪಾಯಿಂಟ್ 369 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಪೂರ್ಣಗೊಂಡಿದೆ, WAL ವಿಭಾಗಗಳನ್ನು ಮರುಹೆಸರಿಸಲಾಗಿದೆ. ಮತ್ತು ಅಕ್ಷರಶಃ 517 ರಲ್ಲಿ, 150 ಮಿಲಿಸೆಕೆಂಡುಗಳ ನಂತರ, ಹಳೆಯ ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ರಿವೈಂಡ್ ಪ್ರಾರಂಭವಾಯಿತು. ಅಂದರೆ, ಅಕ್ಷರಶಃ 150 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳು ನಮಗೆ ಸಾಕಾಗಿದ್ದವು ಆದ್ದರಿಂದ ಪ್ರತಿಕೃತಿಯನ್ನು ಸಂಪರ್ಕಿಸಲು ಮತ್ತು ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.
ಆಯ್ಕೆಗಳು ಯಾವುವು?
ನಾವು ಆರಂಭದಲ್ಲಿ ಪ್ರತಿಕೃತಿ ಸ್ಲಾಟ್‌ಗಳನ್ನು ಬಳಸಿದ್ದೇವೆ. ಇದು ಒಳ್ಳೆಯದು ಎಂದು ನಾವು ಭಾವಿಸಿದ್ದೇವೆ. ಕಾರ್ಯಾಚರಣೆಯ ಮೊದಲ ಹಂತದಲ್ಲಿ ನಾವು ಸ್ಲಾಟ್‌ಗಳನ್ನು ಆಫ್ ಮಾಡಿದ್ದೇವೆ. ಸ್ಲಾಟ್‌ಗಳು ಬಹಳಷ್ಟು WAL ವಿಭಾಗಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ, ನಾವು ಮಾಸ್ಟರ್ ಅನ್ನು ಬಿಡಬಹುದು ಎಂದು ನಮಗೆ ತೋರುತ್ತದೆ. ಅವನು ಬೀಳುವನು. ನಾವು ಸ್ಲಾಟ್‌ಗಳಿಲ್ಲದೆ ಸ್ವಲ್ಪ ಸಮಯ ಅನುಭವಿಸಿದ್ದೇವೆ. ಮತ್ತು ನಮಗೆ ಸ್ಲಾಟ್‌ಗಳು ಬೇಕು ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ, ನಾವು ಸ್ಲಾಟ್‌ಗಳನ್ನು ಹಿಂತಿರುಗಿಸಿದ್ದೇವೆ.
ಆದರೆ ಇಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ, ಮಾಸ್ಟರ್ ಪ್ರತಿಕೃತಿಗೆ ಹೋದಾಗ, ಅದು ಸ್ಲಾಟ್‌ಗಳನ್ನು ಅಳಿಸುತ್ತದೆ ಮತ್ತು ಸ್ಲಾಟ್‌ಗಳ ಜೊತೆಗೆ WAL ವಿಭಾಗಗಳನ್ನು ಅಳಿಸುತ್ತದೆ. ಮತ್ತು ಈ ಸಮಸ್ಯೆಯನ್ನು ತೊಡೆದುಹಾಕಲು, ನಾವು wal_keep_segments ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಹೆಚ್ಚಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಇದು 8 ವಿಭಾಗಗಳಿಗೆ ಡಿಫಾಲ್ಟ್ ಆಗುತ್ತದೆ. ನಾವು ಅದನ್ನು 1 ಕ್ಕೆ ಏರಿಸಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮಲ್ಲಿ ಎಷ್ಟು ಉಚಿತ ಸ್ಥಳವಿದೆ ಎಂದು ನೋಡಿದೆವು. ಮತ್ತು ನಾವು ವಾಲ್_ಕೀಪ್_ಸೆಗ್‌ಮೆಂಟ್‌ಗಳಿಗಾಗಿ 000 ಗಿಗಾಬೈಟ್‌ಗಳನ್ನು ದಾನ ಮಾಡಿದ್ದೇವೆ. ಅಂದರೆ, ಬದಲಾಯಿಸುವಾಗ, ನಾವು ಯಾವಾಗಲೂ ಎಲ್ಲಾ ನೋಡ್‌ಗಳಲ್ಲಿ 16 ಗಿಗಾಬೈಟ್‌ಗಳ ವಹಿವಾಟು ಲಾಗ್‌ಗಳ ಮೀಸಲು ಹೊಂದಿದ್ದೇವೆ.
ಮತ್ತು ಜೊತೆಗೆ - ದೀರ್ಘಕಾಲೀನ ನಿರ್ವಹಣೆ ಕಾರ್ಯಗಳಿಗೆ ಇದು ಇನ್ನೂ ಪ್ರಸ್ತುತವಾಗಿದೆ. ನಾವು ಪ್ರತಿಕೃತಿಗಳಲ್ಲಿ ಒಂದನ್ನು ನವೀಕರಿಸಬೇಕಾಗಿದೆ ಎಂದು ಹೇಳೋಣ. ಮತ್ತು ನಾವು ಅದನ್ನು ಆಫ್ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ. ನಾವು ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ನವೀಕರಿಸಬೇಕಾಗಿದೆ, ಬಹುಶಃ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್, ಇನ್ನೇನಾದರೂ. ಮತ್ತು ನಾವು ಪ್ರತಿಕೃತಿಯನ್ನು ಆಫ್ ಮಾಡಿದಾಗ, ಆ ಪ್ರತಿಕೃತಿಯ ಸ್ಲಾಟ್ ಅನ್ನು ಸಹ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ. ಮತ್ತು ನಾವು ಸಣ್ಣ wal_keep_segments ಅನ್ನು ಬಳಸಿದರೆ, ನಂತರ ಪ್ರತಿಕೃತಿಯ ದೀರ್ಘ ಅನುಪಸ್ಥಿತಿಯಲ್ಲಿ, ವಹಿವಾಟು ಲಾಗ್ಗಳು ಕಳೆದುಹೋಗುತ್ತವೆ. ನಾವು ಪ್ರತಿಕೃತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ, ಅದು ಎಲ್ಲಿ ನಿಲ್ಲಿಸಿತ್ತೋ ಆ ವಹಿವಾಟು ಲಾಗ್‌ಗಳನ್ನು ಅದು ವಿನಂತಿಸುತ್ತದೆ, ಆದರೆ ಅವು ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಇಲ್ಲದಿರಬಹುದು. ಮತ್ತು ಪ್ರತಿಕೃತಿಯನ್ನು ಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ನಾವು ನಿಯತಕಾಲಿಕೆಗಳ ದೊಡ್ಡ ಸ್ಟಾಕ್ ಅನ್ನು ಇಡುತ್ತೇವೆ.
ನಾವು ಉತ್ಪಾದನಾ ನೆಲೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಈಗಾಗಲೇ ಯೋಜನೆಗಳು ಪ್ರಗತಿಯಲ್ಲಿವೆ.
ಒಬ್ಬ ಫೈಲರ್ ಇದ್ದ. ನಾವು ಒಳಗೆ ಹೋಗಿ ನೋಡಿದೆವು - ಎಲ್ಲವೂ ಕ್ರಮದಲ್ಲಿದೆ, ಪ್ರತಿಕೃತಿಗಳು ಸ್ಥಳದಲ್ಲಿವೆ, ಯಾವುದೇ ಪ್ರತಿಕೃತಿ ವಿಳಂಬವಿಲ್ಲ. ಲಾಗ್ಗಳಲ್ಲಿ ಯಾವುದೇ ದೋಷಗಳಿಲ್ಲ, ಎಲ್ಲವೂ ಕ್ರಮದಲ್ಲಿದೆ.
ಉತ್ಪನ್ನ ತಂಡವು ಕೆಲವು ಡೇಟಾ ಇರಬೇಕು ಎಂದು ಹೇಳುತ್ತದೆ, ಆದರೆ ನಾವು ಅದನ್ನು ಒಂದು ಮೂಲದಿಂದ ನೋಡುತ್ತೇವೆ, ಆದರೆ ನಾವು ಅದನ್ನು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನೋಡುವುದಿಲ್ಲ. ಮತ್ತು ಅವರಿಗೆ ಏನಾಯಿತು ಎಂಬುದನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.
pg_rewind ಅವರನ್ನು ತಪ್ಪಿಸಿಕೊಂಡಿರುವುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ನಾವು ತಕ್ಷಣ ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ, ಆದರೆ ಏನಾಗುತ್ತಿದೆ ಎಂದು ನೋಡಲು ಹೋದೆವು.
ಲಾಗ್ಗಳಲ್ಲಿ, ಫೈಲ್ ಮಾಡುವವರು ಯಾವಾಗ ಸಂಭವಿಸಿದರು, ಯಾರು ಮಾಸ್ಟರ್ ಆದರು, ಮತ್ತು ಹಳೆಯ ಮಾಸ್ಟರ್ ಯಾರು ಮತ್ತು ಅವರು ಯಾವಾಗ ಪ್ರತಿಕೃತಿಯಾಗಬೇಕೆಂದು ನಾವು ನಿರ್ಧರಿಸಬಹುದು, ಅಂದರೆ ವಹಿವಾಟು ಲಾಗ್‌ಗಳ ಮೊತ್ತವನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಮಗೆ ಈ ಲಾಗ್ಗಳು ಬೇಕಾಗುತ್ತವೆ. ಕಳೆದುಹೋಯಿತು.
ನಮ್ಮ ಹಳೆಯ ಮಾಸ್ಟರ್ ರೀಬೂಟ್ ಮಾಡಿದ್ದಾರೆ. ಮತ್ತು ಪತ್ರೋನಿಯನ್ನು ಆಟೋರನ್‌ನಲ್ಲಿ ನೋಂದಾಯಿಸಲಾಗಿದೆ. ಪತ್ರೋನಿಯನ್ನು ಪ್ರಾರಂಭಿಸಿದರು. ನಂತರ ಅವರು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದರು. ಹೆಚ್ಚು ನಿಖರವಾಗಿ ಹೇಳುವುದಾದರೆ, Postgres ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಮತ್ತು ಅದನ್ನು ಪ್ರತಿಕೃತಿ ಮಾಡುವ ಮೊದಲು, Patroni pg_rewind ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿತು. ಅದರಂತೆ, ಅವರು ವಹಿವಾಟಿನ ಲಾಗ್‌ಗಳ ಭಾಗವನ್ನು ಅಳಿಸಿಹಾಕಿದರು, ಹೊಸದನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದರು ಮತ್ತು ಸಂಪರ್ಕಿಸಿದರು. ಇಲ್ಲಿ ಪತ್ರೋನಿ ಚುರುಕಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ, ಅಂದರೆ, ನಿರೀಕ್ಷೆಯಂತೆ. ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲಾಗಿದೆ. ನಾವು 3 ನೋಡ್ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಫೈಲರ್ 3 ನೋಡ್ಗಳ ನಂತರ - ಎಲ್ಲವೂ ತಂಪಾಗಿದೆ.
ನಾವು ಕೆಲವು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ಎಷ್ಟು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ನಾವು ರಿವೈಂಡ್ ಹೊಂದಿರುವ ಕ್ಷಣಕ್ಕಾಗಿ ನಾವು ಹುಡುಕುತ್ತಿದ್ದೇವೆ. ಅಂತಹ ಜರ್ನಲ್ ನಮೂದುಗಳಲ್ಲಿ ನಾವು ಅದನ್ನು ಕಾಣಬಹುದು. ರಿವೈಂಡ್ ಶುರು ಮಾಡಿ, ಅಲ್ಲಿ ಏನೇನೋ ಮಾಡಿ ಮುಗಿಸಿದೆ.
ಹಳೆಯ ಮಾಸ್ಟರ್ ಬಿಟ್ಟುಹೋದ ವಹಿವಾಟಿನ ಲಾಗ್‌ನಲ್ಲಿ ನಾವು ಸ್ಥಾನವನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಗುರುತು. ಮತ್ತು ನಮಗೆ ಎರಡನೇ ಗುರುತು ಬೇಕು, ಅಂದರೆ, ಹಳೆಯ ಮಾಸ್ಟರ್ ಹೊಸದರಿಂದ ಭಿನ್ನವಾಗಿರುವ ಅಂತರ.
ನಾವು ಸಾಮಾನ್ಯ pg_wal_lsn_diff ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಈ ಎರಡು ಅಂಕಗಳನ್ನು ಹೋಲಿಕೆ ಮಾಡುತ್ತೇವೆ. ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು 17 ಮೆಗಾಬೈಟ್ಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಬಹಳಷ್ಟು ಅಥವಾ ಸ್ವಲ್ಪ, ಪ್ರತಿಯೊಬ್ಬರೂ ಸ್ವತಃ ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಏಕೆಂದರೆ ಯಾರಿಗಾದರೂ 17 ಮೆಗಾಬೈಟ್‌ಗಳು ಹೆಚ್ಚು ಅಲ್ಲ, ಯಾರಿಗಾದರೂ ಇದು ಬಹಳಷ್ಟು ಮತ್ತು ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ. ಇಲ್ಲಿ, ಪ್ರತಿಯೊಬ್ಬ ವ್ಯಕ್ತಿಯು ವ್ಯವಹಾರದ ಅಗತ್ಯತೆಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ಸ್ವತಃ ನಿರ್ಧರಿಸುತ್ತಾನೆ.
ಆದರೆ ನಾವು ನಮಗಾಗಿ ಏನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ?
ಮೊದಲಿಗೆ, ನಾವೇ ನಿರ್ಧರಿಸಬೇಕು - ಸಿಸ್ಟಮ್ ರೀಬೂಟ್ ಮಾಡಿದ ನಂತರ ಆಟೋಸ್ಟಾರ್ಟ್ ಮಾಡಲು ನಮಗೆ ಯಾವಾಗಲೂ ಪ್ಯಾಟ್ರೋನಿ ಅಗತ್ಯವಿದೆಯೇ? ನಾವು ಹಳೆಯ ಯಜಮಾನನ ಬಳಿಗೆ ಹೋಗಬೇಕು ಎಂದು ಆಗಾಗ್ಗೆ ಸಂಭವಿಸುತ್ತದೆ, ಅವರು ಎಷ್ಟು ದೂರ ಹೋಗಿದ್ದಾರೆಂದು ನೋಡಿ. ಬಹುಶಃ ವಹಿವಾಟು ಲಾಗ್‌ನ ವಿಭಾಗಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ, ಅಲ್ಲಿ ಏನಿದೆ ಎಂಬುದನ್ನು ನೋಡಿ. ಮತ್ತು ನಾವು ಈ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದೇ ಅಥವಾ ಈ ಡೇಟಾವನ್ನು ಹೊರತೆಗೆಯಲು ನಾವು ಹಳೆಯ ಮಾಸ್ಟರ್ ಅನ್ನು ಸ್ವತಂತ್ರ ಮೋಡ್‌ನಲ್ಲಿ ರನ್ ಮಾಡಬೇಕೇ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು.
ಮತ್ತು ಅದರ ನಂತರವೇ ನಾವು ಈ ಡೇಟಾವನ್ನು ತ್ಯಜಿಸಬಹುದೇ ಅಥವಾ ನಾವು ಅದನ್ನು ಮರುಸ್ಥಾಪಿಸಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸಬೇಕು, ಈ ನೋಡ್ ಅನ್ನು ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ಗೆ ಪ್ರತಿರೂಪವಾಗಿ ಸಂಪರ್ಕಿಸಿ.
ಜೊತೆಗೆ, "maximum_lag_on_failover" ಪ್ಯಾರಾಮೀಟರ್ ಇದೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ನನ್ನ ಮೆಮೊರಿ ನನಗೆ ಸೇವೆ ಸಲ್ಲಿಸಿದರೆ, ಈ ಪ್ಯಾರಾಮೀಟರ್ 1 ಮೆಗಾಬೈಟ್ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುತ್ತದೆ.
ಅವನು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾನೆ? ರೆಪ್ಲಿಕೇಶನ್ ಲ್ಯಾಗ್‌ನಲ್ಲಿ ನಮ್ಮ ಪ್ರತಿಕೃತಿಯು 1 ಮೆಗಾಬೈಟ್ ಡೇಟಾ ಹಿಂದೆ ಇದ್ದರೆ, ಈ ಪ್ರತಿಕೃತಿ ಚುನಾವಣೆಯಲ್ಲಿ ಭಾಗವಹಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಫೈಲ್ಓವರ್ ಇದ್ದರೆ, ಯಾವ ಪ್ರತಿಕೃತಿಗಳು ಹಿಂದುಳಿದಿವೆ ಎಂಬುದನ್ನು ಪತ್ರೋನಿ ನೋಡುತ್ತಾನೆ. ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವಹಿವಾಟು ಲಾಗ್‌ಗಳಿಂದ ಅವರು ಹಿಂದೆ ಇದ್ದರೆ, ಅವರು ಮಾಸ್ಟರ್ ಆಗಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇದು ಉತ್ತಮವಾದ ಭದ್ರತಾ ವೈಶಿಷ್ಟ್ಯವಾಗಿದ್ದು, ಬಹಳಷ್ಟು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳದಂತೆ ನಿಮ್ಮನ್ನು ತಡೆಯುತ್ತದೆ.
ಆದರೆ ಪ್ಯಾಟ್ರೋನಿ ಕ್ಲಸ್ಟರ್ ಮತ್ತು ಡಿಸಿಎಸ್‌ನಲ್ಲಿನ ಪುನರಾವರ್ತನೆಯ ಮಂದಗತಿಯನ್ನು ನಿರ್ದಿಷ್ಟ ಮಧ್ಯಂತರದಲ್ಲಿ ನವೀಕರಿಸಲಾಗುತ್ತದೆ ಎಂಬಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ. 30 ಸೆಕೆಂಡುಗಳು ಡೀಫಾಲ್ಟ್ ಟಿಟಿಎಲ್ ಮೌಲ್ಯ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ಅಂತೆಯೇ, DCS ನಲ್ಲಿ ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಒಂದು ಪುನರಾವರ್ತನೆಯ ಮಂದಗತಿ ಇರುವ ಪರಿಸ್ಥಿತಿ ಇರಬಹುದು, ಆದರೆ ವಾಸ್ತವವಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾದ ಮಂದಗತಿ ಇರಬಹುದು ಅಥವಾ ಯಾವುದೇ ವಿಳಂಬವಿಲ್ಲದಿರಬಹುದು, ಅಂದರೆ ಇದು ನೈಜ ಸಮಯವಲ್ಲ. ಮತ್ತು ಇದು ಯಾವಾಗಲೂ ನೈಜ ಚಿತ್ರವನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಅದರ ಮೇಲೆ ಅಲಂಕಾರಿಕ ತರ್ಕವನ್ನು ಮಾಡುವುದು ಯೋಗ್ಯವಾಗಿಲ್ಲ.
ಮತ್ತು ನಷ್ಟದ ಅಪಾಯ ಯಾವಾಗಲೂ ಉಳಿದಿದೆ. ಮತ್ತು ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ, ಒಂದು ಸೂತ್ರ, ಮತ್ತು ಸರಾಸರಿ ಸಂದರ್ಭದಲ್ಲಿ, ಇನ್ನೊಂದು ಸೂತ್ರ. ಅಂದರೆ, ನಾವು ಪ್ಯಾಟ್ರೋನಿಯ ಅನುಷ್ಠಾನವನ್ನು ಯೋಜಿಸಿದಾಗ ಮತ್ತು ನಾವು ಎಷ್ಟು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು ಎಂಬುದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವಾಗ, ನಾವು ಈ ಸೂತ್ರಗಳನ್ನು ಅವಲಂಬಿಸಬೇಕು ಮತ್ತು ನಾವು ಎಷ್ಟು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು ಎಂದು ಸ್ಥೂಲವಾಗಿ ಊಹಿಸಬೇಕು.
ಮತ್ತು ಒಳ್ಳೆಯ ಸುದ್ದಿ ಇದೆ. ಹಳೆಯ ಮಾಸ್ಟರ್ ಮುಂದೆ ಹೋದಾಗ, ಕೆಲವು ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಗಳಿಂದ ಅವನು ಮುಂದೆ ಹೋಗಬಹುದು. ಅಂದರೆ, ಕೆಲವು ರೀತಿಯ ಆಟೋವಾಕ್ಯೂಮ್ ಇತ್ತು, ಅವರು ಡೇಟಾವನ್ನು ಬರೆದರು, ಅವುಗಳನ್ನು ವಹಿವಾಟು ಲಾಗ್‌ಗೆ ಉಳಿಸಿದರು. ಮತ್ತು ನಾವು ಈ ಡೇಟಾವನ್ನು ಸುಲಭವಾಗಿ ನಿರ್ಲಕ್ಷಿಸಬಹುದು ಮತ್ತು ಕಳೆದುಕೊಳ್ಳಬಹುದು. ಇದರಲ್ಲಿ ಯಾವುದೇ ತೊಂದರೆ ಇಲ್ಲ.
ಮತ್ತು ಗರಿಷ್ಠ_lag_on_failover ಅನ್ನು ಹೊಂದಿಸಿದರೆ ಮತ್ತು ಫೈಲರ್ ಸಂಭವಿಸಿದಲ್ಲಿ ಲಾಗ್ಗಳು ಈ ರೀತಿ ಕಾಣುತ್ತವೆ ಮತ್ತು ನೀವು ಹೊಸ ಮಾಸ್ಟರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಪ್ರತಿಕೃತಿಯು ಚುನಾವಣೆಯಲ್ಲಿ ಭಾಗವಹಿಸಲು ಅಸಮರ್ಥನೆಂದು ನಿರ್ಣಯಿಸುತ್ತದೆ. ಮತ್ತು ಅವಳು ನಾಯಕನ ಓಟದಲ್ಲಿ ಭಾಗವಹಿಸಲು ನಿರಾಕರಿಸುತ್ತಾಳೆ. ಮತ್ತು ಅವಳು ಹೊಸ ಮಾಸ್ಟರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಕಾಯುತ್ತಾಳೆ, ಇದರಿಂದ ಅವಳು ಅದನ್ನು ಸಂಪರ್ಕಿಸಬಹುದು. ಡೇಟಾ ನಷ್ಟದ ವಿರುದ್ಧ ಇದು ಹೆಚ್ಚುವರಿ ಅಳತೆಯಾಗಿದೆ.
ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ ತಮ್ಮ ಉತ್ಪನ್ನವು ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತಿದೆ ಎಂದು ಬರೆದ ಉತ್ಪನ್ನ ತಂಡವನ್ನು ಇಲ್ಲಿ ನಾವು ಹೊಂದಿದ್ದೇವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಮಾಸ್ಟರ್ ಅನ್ನು ಸ್ವತಃ ಪ್ರವೇಶಿಸಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಇದು SSH ಮೂಲಕ ಲಭ್ಯವಿಲ್ಲ. ಮತ್ತು ಆಟೋಫೈಲ್ ಕೂಡ ಆಗುವುದಿಲ್ಲ.
ಈ ಹೋಸ್ಟ್ ಅನ್ನು ರೀಬೂಟ್ ಮಾಡಲು ಒತ್ತಾಯಿಸಲಾಗಿದೆ. ರೀಬೂಟ್‌ನಿಂದಾಗಿ, ಸ್ವಯಂ-ಫೈಲ್ ಸಂಭವಿಸಿದೆ, ಆದರೂ ನಾನು ಈಗ ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ ಹಸ್ತಚಾಲಿತ ಸ್ವಯಂ-ಫೈಲ್ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು. ಮತ್ತು ರೀಬೂಟ್ ಮಾಡಿದ ನಂತರ, ಪ್ರಸ್ತುತ ಮಾಸ್ಟರ್‌ನೊಂದಿಗೆ ನಾವು ಹೊಂದಿದ್ದನ್ನು ನಾವು ಈಗಾಗಲೇ ನೋಡಲಿದ್ದೇವೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ಡಿಸ್ಕ್ಗಳೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ನಮಗೆ ಮೊದಲೇ ತಿಳಿದಿತ್ತು, ಅಂದರೆ, ಎಲ್ಲಿ ಅಗೆಯಬೇಕು ಮತ್ತು ಯಾವುದನ್ನು ನೋಡಬೇಕು ಎಂಬುದನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದರಿಂದ ನಮಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿತ್ತು.
ನಾವು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಲಾಗ್‌ಗೆ ಬಂದೆವು, ಅಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂದು ನೋಡಲು ಪ್ರಾರಂಭಿಸಿದೆವು. ಒಂದು, ಎರಡು, ಮೂರು ಸೆಕೆಂಡ್‌ಗಳ ಕಾಲ ಇರುವುದನ್ನು ನಾವು ನೋಡಿದ್ದೇವೆ, ಅದು ಸಾಮಾನ್ಯವಲ್ಲ. ನಮ್ಮ ಆಟೋವ್ಯಾಕ್ಯೂಮ್ ತುಂಬಾ ನಿಧಾನವಾಗಿ ಮತ್ತು ವಿಚಿತ್ರವಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂದು ನಾವು ನೋಡಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ಡಿಸ್ಕ್ನಲ್ಲಿ ತಾತ್ಕಾಲಿಕ ಫೈಲ್ಗಳನ್ನು ನೋಡಿದ್ದೇವೆ. ಅಂದರೆ, ಇವುಗಳು ಡಿಸ್ಕ್ಗಳೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳ ಎಲ್ಲಾ ಸೂಚಕಗಳಾಗಿವೆ.
ನಾವು ಸಿಸ್ಟಮ್ dmesg (ಕರ್ನಲ್ ಲಾಗ್) ಅನ್ನು ನೋಡಿದ್ದೇವೆ. ಮತ್ತು ಡಿಸ್ಕ್ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ನಮಗೆ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂದು ನಾವು ನೋಡಿದ್ದೇವೆ. ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯು ಸಾಫ್ಟ್‌ವೇರ್ ರೈಡ್ ಆಗಿತ್ತು. ನಾವು /proc/mdstat ಅನ್ನು ನೋಡಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಒಂದು ಡ್ರೈವ್ ಅನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ ಎಂದು ನೋಡಿದೆವು. ಅಂದರೆ, 8 ಡಿಸ್ಕ್ಗಳ ರೈಡ್ ಇದೆ, ನಾವು ಒಂದನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ. ನೀವು ಸ್ಲೈಡ್ ಅನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ನೋಡಿದರೆ, ಔಟ್ಪುಟ್ನಲ್ಲಿ ನಾವು ಅಲ್ಲಿ sde ಹೊಂದಿಲ್ಲ ಎಂದು ನೀವು ನೋಡಬಹುದು. ನಮ್ಮಲ್ಲಿ, ಷರತ್ತುಬದ್ಧವಾಗಿ ಹೇಳುವುದಾದರೆ, ಡಿಸ್ಕ್ ಕೈಬಿಟ್ಟಿದೆ. ಇದು ಡಿಸ್ಕ್ ಸಮಸ್ಯೆಗಳನ್ನು ಪ್ರಚೋದಿಸಿತು ಮತ್ತು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಕ್ಲಸ್ಟರ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸಮಸ್ಯೆಗಳನ್ನು ಅನುಭವಿಸಿದವು.
ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪತ್ರೋನಿ ನಮಗೆ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಪ್ಯಾಟ್ರೋನಿ ಸರ್ವರ್ನ ಸ್ಥಿತಿಯನ್ನು, ಡಿಸ್ಕ್ನ ಸ್ಥಿತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಕೆಲಸವನ್ನು ಹೊಂದಿಲ್ಲ. ಮತ್ತು ನಾವು ಅಂತಹ ಸಂದರ್ಭಗಳನ್ನು ಬಾಹ್ಯ ಮೇಲ್ವಿಚಾರಣೆಯ ಮೂಲಕ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು. ನಾವು ತ್ವರಿತವಾಗಿ ಡಿಸ್ಕ್ ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಬಾಹ್ಯ ಮೇಲ್ವಿಚಾರಣೆಗೆ ಸೇರಿಸಿದ್ದೇವೆ.
ಮತ್ತು ಅಂತಹ ಆಲೋಚನೆ ಇತ್ತು - ಫೆನ್ಸಿಂಗ್ ಅಥವಾ ವಾಚ್‌ಡಾಗ್ ಸಾಫ್ಟ್‌ವೇರ್ ನಮಗೆ ಸಹಾಯ ಮಾಡಬಹುದೇ? ಈ ಸಂದರ್ಭದಲ್ಲಿ ಅವರು ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತಿರಲಿಲ್ಲ ಎಂದು ನಾವು ಭಾವಿಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಸಮಸ್ಯೆಗಳ ಸಮಯದಲ್ಲಿ ಪತ್ರೋನಿ DCS ಕ್ಲಸ್ಟರ್ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವುದನ್ನು ಮುಂದುವರೆಸಿದರು ಮತ್ತು ಯಾವುದೇ ಸಮಸ್ಯೆಯನ್ನು ನೋಡಲಿಲ್ಲ. ಅಂದರೆ, DCS ಮತ್ತು Patroni ದೃಷ್ಟಿಕೋನದಿಂದ, ಕ್ಲಸ್ಟರ್ನೊಂದಿಗೆ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ, ಆದಾಗ್ಯೂ ವಾಸ್ತವವಾಗಿ ಡಿಸ್ಕ್ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿದ್ದರೂ, ಡೇಟಾಬೇಸ್ನ ಲಭ್ಯತೆಯೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳಿವೆ.
ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ನಾನು ಬಹಳ ಸಮಯದಿಂದ ಸಂಶೋಧನೆ ಮಾಡಿದ ವಿಚಿತ್ರವಾದ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ನಾನು ಬಹಳಷ್ಟು ಲಾಗ್‌ಗಳನ್ನು ಓದಿದ್ದೇನೆ, ಪುನಃ ಆರಿಸಿದ್ದೇನೆ ಮತ್ತು ಅದನ್ನು ಕ್ಲಸ್ಟರ್ ಸಿಮ್ಯುಲೇಟರ್ ಎಂದು ಕರೆದಿದ್ದೇನೆ.
ಸಮಸ್ಯೆಯೆಂದರೆ ಹಳೆಯ ಮಾಸ್ಟರ್ ಸಾಮಾನ್ಯ ಪ್ರತಿರೂಪವಾಗಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಅಂದರೆ ಪತ್ರೋನಿ ಅದನ್ನು ಪ್ರಾರಂಭಿಸಿದರು, ಈ ನೋಡ್ ಪ್ರತಿರೂಪವಾಗಿ ಪ್ರಸ್ತುತವಾಗಿದೆ ಎಂದು ಪತ್ರೋನಿ ತೋರಿಸಿದರು, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಅದು ಸಾಮಾನ್ಯ ಪ್ರತಿಕೃತಿಯಾಗಿರಲಿಲ್ಲ. ಏಕೆ ಎಂದು ಈಗ ನೀವು ನೋಡುತ್ತೀರಿ. ಆ ಸಮಸ್ಯೆಯ ವಿಶ್ಲೇಷಣೆಯಿಂದ ನಾನು ಇಟ್ಟುಕೊಂಡಿರುವುದು ಇದನ್ನೇ.
ಮತ್ತು ಅದು ಹೇಗೆ ಪ್ರಾರಂಭವಾಯಿತು? ಇದು ಹಿಂದಿನ ಸಮಸ್ಯೆಯಂತೆ, ಡಿಸ್ಕ್ ಬ್ರೇಕ್‌ಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಯಿತು. ನಾವು ಎರಡನೇ, ಎರಡು ಬದ್ಧತೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಸಂಪರ್ಕಗಳಲ್ಲಿ ವಿರಾಮಗಳು ಇದ್ದವು, ಅಂದರೆ, ಗ್ರಾಹಕರು ಹರಿದಿದ್ದಾರೆ.
ವಿಭಿನ್ನ ತೀವ್ರತೆಯ ಅಡೆತಡೆಗಳು ಇದ್ದವು.
ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯು ಹೆಚ್ಚು ಸ್ಪಂದಿಸುವುದಿಲ್ಲ.
ಮತ್ತು ನನಗೆ ಅತ್ಯಂತ ನಿಗೂಢ ವಿಷಯವೆಂದರೆ ಬಂದ ತಕ್ಷಣದ ಸ್ಥಗಿತಗೊಳಿಸುವ ವಿನಂತಿ. Postgres ಮೂರು ಸ್ಥಗಿತಗೊಳಿಸುವ ವಿಧಾನಗಳನ್ನು ಹೊಂದಿದೆ:
- ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳು ತಮ್ಮದೇ ಆದ ಸಂಪರ್ಕ ಕಡಿತಗೊಳ್ಳಲು ನಾವು ಕಾಯುತ್ತಿರುವಾಗ ಇದು ಆಕರ್ಷಕವಾಗಿದೆ.
- ನಾವು ಸ್ಥಗಿತಗೊಳಿಸಲಿರುವ ಕಾರಣ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಡಿಸ್‌ಕನೆಕ್ಟ್ ಮಾಡಲು ಒತ್ತಾಯಿಸಿದಾಗ ವೇಗವಿದೆ.
- ಮತ್ತು ತಕ್ಷಣ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ತಕ್ಷಣವೇ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಮುಚ್ಚಲು ಹೇಳುವುದಿಲ್ಲ, ಅದು ಎಚ್ಚರಿಕೆಯಿಲ್ಲದೆ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ. ಮತ್ತು ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಈಗಾಗಲೇ RST ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುತ್ತದೆ (ಸಂಪರ್ಕವು ಅಡಚಣೆಯಾಗಿದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಹಿಡಿಯಲು ಹೆಚ್ಚಿನದನ್ನು ಹೊಂದಿಲ್ಲ ಎಂಬ TCP ಸಂದೇಶ).
ಈ ಸಂಕೇತವನ್ನು ಯಾರು ಕಳುಹಿಸಿದ್ದಾರೆ? ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಗಳು ಅಂತಹ ಸಂಕೇತಗಳನ್ನು ಪರಸ್ಪರ ಕಳುಹಿಸುವುದಿಲ್ಲ, ಅಂದರೆ ಇದು ಕಿಲ್ -9. ಅವರು ಅಂತಹ ವಿಷಯಗಳನ್ನು ಪರಸ್ಪರ ಕಳುಹಿಸುವುದಿಲ್ಲ, ಅವರು ಅಂತಹ ವಿಷಯಗಳಿಗೆ ಮಾತ್ರ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಾರೆ, ಅಂದರೆ ಇದು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನ ತುರ್ತು ಪುನರಾರಂಭವಾಗಿದೆ. ಯಾರು ಕಳುಹಿಸಿದ್ದಾರೆ, ನನಗೆ ಗೊತ್ತಿಲ್ಲ.
ನಾನು "ಕೊನೆಯ" ಆಜ್ಞೆಯನ್ನು ನೋಡಿದೆ ಮತ್ತು ನಮ್ಮೊಂದಿಗೆ ಈ ಸರ್ವರ್‌ಗೆ ಲಾಗ್ ಇನ್ ಮಾಡಿದ ಒಬ್ಬ ವ್ಯಕ್ತಿಯನ್ನು ನಾನು ನೋಡಿದೆ, ಆದರೆ ನಾನು ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಲು ತುಂಬಾ ನಾಚಿಕೆಪಡುತ್ತೇನೆ. ಬಹುಶಃ ಇದು ಕೊಲೆ -9. ನಾನು ಲಾಗ್ಗಳಲ್ಲಿ ಕಿಲ್ -9 ಅನ್ನು ನೋಡುತ್ತೇನೆ, ಏಕೆಂದರೆ ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಹೇಳುವಂತೆ ಇದು ಕಿಲ್ -9 ತೆಗೆದುಕೊಂಡಿತು, ಆದರೆ ನಾನು ಅದನ್ನು ಲಾಗ್ಗಳಲ್ಲಿ ನೋಡಲಿಲ್ಲ.
ಮುಂದೆ ನೋಡಿದಾಗ, ಪತ್ರೋನಿ ಲಾಗ್‌ಗೆ ಬಹಳ ಸಮಯದವರೆಗೆ ಬರೆಯಲಿಲ್ಲ ಎಂದು ನಾನು ನೋಡಿದೆ - 54 ಸೆಕೆಂಡುಗಳು. ಮತ್ತು ನಾವು ಎರಡು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ಹೋಲಿಸಿದರೆ, ಸುಮಾರು 54 ಸೆಕೆಂಡುಗಳವರೆಗೆ ಯಾವುದೇ ಸಂದೇಶಗಳಿಲ್ಲ.
ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ಆಟೋಫೈಲ್ ಇತ್ತು. ಪತ್ರೋನಿ ಇಲ್ಲಿ ಮತ್ತೊಮ್ಮೆ ಉತ್ತಮ ಕೆಲಸ ಮಾಡಿದರು. ನಮ್ಮ ಹಳೆಯ ಮೇಷ್ಟ್ರು ಲಭ್ಯವಿಲ್ಲ, ಅವರಿಗೆ ಏನಾದರೂ ಸಂಭವಿಸಿದೆ. ಮತ್ತು ಹೊಸ ಮಾಸ್ಟರ್ ಆಯ್ಕೆ ಪ್ರಾರಂಭವಾಯಿತು. ಇಲ್ಲಿ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ. ನಮ್ಮ pgsql01 ಹೊಸ ನಾಯಕರಾಗಿದ್ದಾರೆ.
ನಾವು ಮಾಸ್ಟರ್ ಆಗಿರುವ ಪ್ರತಿಕೃತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ಎರಡನೇ ಪ್ರತಿಕ್ರಿಯೆ ಇದೆ. ಮತ್ತು ಎರಡನೇ ಪ್ರತಿಕೃತಿಯೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳಿವೆ. ಅವಳು ಮರುಸಂರಚಿಸಲು ಪ್ರಯತ್ನಿಸಿದಳು. ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಅವರು recovery.conf ಅನ್ನು ಬದಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸಿದರು, ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಹೊಸ ಮಾಸ್ಟರ್ಗೆ ಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸಿದರು. ಅವಳು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಪ್ರತಿ 10 ಸೆಕೆಂಡಿಗೆ ಸಂದೇಶಗಳನ್ನು ಬರೆಯುತ್ತಾಳೆ, ಆದರೆ ಅವಳು ಯಶಸ್ವಿಯಾಗುತ್ತಿಲ್ಲ.
ಮತ್ತು ಈ ಪ್ರಯತ್ನಗಳ ಸಮಯದಲ್ಲಿ, ತಕ್ಷಣದ-ಸ್ಥಗಿತಗೊಳಿಸುವ ಸಂಕೇತವು ಹಳೆಯ ಮಾಸ್ಟರ್ಗೆ ಆಗಮಿಸುತ್ತದೆ. ಮಾಸ್ಟರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲಾಗಿದೆ. ಮತ್ತು ಹಳೆಯ ಮಾಸ್ಟರ್ ರೀಬೂಟ್‌ಗೆ ಹೋಗುವುದರಿಂದ ಚೇತರಿಕೆ ನಿಲ್ಲುತ್ತದೆ. ಅಂದರೆ, ಪ್ರತಿಕೃತಿಯು ಅದನ್ನು ಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಸ್ಥಗಿತಗೊಳಿಸುವ ಕ್ರಮದಲ್ಲಿದೆ.
ಕೆಲವು ಹಂತದಲ್ಲಿ, ಇದು ಕೆಲಸ ಮಾಡಿದೆ, ಆದರೆ ಪ್ರತಿಕೃತಿ ಪ್ರಾರಂಭವಾಗಲಿಲ್ಲ.
Recovery.conf ನಲ್ಲಿ ಹಳೆಯ ಮಾಸ್ಟರ್ ವಿಳಾಸವಿದೆ ಎಂಬುದು ನನ್ನ ಊಹೆ. ಮತ್ತು ಹೊಸ ಮಾಸ್ಟರ್ ಕಾಣಿಸಿಕೊಂಡಾಗ, ಎರಡನೇ ಪ್ರತಿಕೃತಿ ಇನ್ನೂ ಹಳೆಯ ಮಾಸ್ಟರ್ಗೆ ಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸಿತು.
ಪತ್ರೋನಿ ಎರಡನೇ ಪ್ರತಿಕೃತಿಯನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನೋಡ್ ಪ್ರಾರಂಭವಾಯಿತು ಆದರೆ ಪುನರಾವರ್ತಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಮತ್ತು ಪ್ರತಿಕೃತಿ ಮಂದಗತಿ ರೂಪುಗೊಂಡಿತು, ಅದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ. ಅಂದರೆ, ಎಲ್ಲಾ ಮೂರು ನೋಡ್ಗಳು ಸ್ಥಳದಲ್ಲಿವೆ, ಆದರೆ ಎರಡನೇ ನೋಡ್ ಹಿಂದುಳಿದಿದೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ನೀವು ಬರೆಯಲಾದ ಲಾಗ್‌ಗಳನ್ನು ನೋಡಿದರೆ, ವಹಿವಾಟಿನ ಲಾಗ್ಗಳು ವಿಭಿನ್ನವಾಗಿರುವ ಕಾರಣ ಪ್ರತಿಕೃತಿಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನೀವು ನೋಡಬಹುದು. ಮತ್ತು recovery.conf ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮಾಸ್ಟರ್ ನೀಡುವ ವಹಿವಾಟು ಲಾಗ್ಗಳು ನಮ್ಮ ಪ್ರಸ್ತುತ ನೋಡ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.
ಮತ್ತು ಇಲ್ಲಿ ನಾನು ತಪ್ಪು ಮಾಡಿದೆ. ನಾವು ತಪ್ಪಾದ ಮಾಸ್ಟರ್ಗೆ ಸಂಪರ್ಕಿಸುತ್ತಿದ್ದೇವೆ ಎಂಬ ನನ್ನ ಊಹೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ನಾನು ಬಂದು recovery.conf ನಲ್ಲಿ ಏನಿದೆ ಎಂದು ನೋಡಬೇಕಾಗಿತ್ತು. ಆದರೆ ನಂತರ ನಾನು ಇದರೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತಿದ್ದೆ ಮತ್ತು ಅದು ನನಗೆ ಸಂಭವಿಸಲಿಲ್ಲ, ಅಥವಾ ಪ್ರತಿಕೃತಿಯು ಹಿಂದುಳಿದಿರುವುದನ್ನು ನಾನು ನೋಡಿದೆ ಮತ್ತು ಅದನ್ನು ಪುನಃ ತುಂಬಿಸಬೇಕಾಗಿದೆ, ಅಂದರೆ, ನಾನು ಹೇಗಾದರೂ ಅಸಡ್ಡೆಯಿಂದ ಕೆಲಸ ಮಾಡಿದ್ದೇನೆ. ಇದು ನನ್ನ ಜಂಟಿಯಾಗಿತ್ತು.
30 ನಿಮಿಷಗಳ ನಂತರ, ನಿರ್ವಾಹಕರು ಈಗಾಗಲೇ ಬಂದರು, ಅಂದರೆ ನಾನು ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ಪತ್ರೋನಿಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದೆ. ನಾನು ಈಗಾಗಲೇ ಅದನ್ನು ಕೊನೆಗೊಳಿಸಿದ್ದೇನೆ, ಅದನ್ನು ಮತ್ತೆ ತುಂಬಬೇಕು ಎಂದು ನಾನು ಭಾವಿಸಿದೆ. ಮತ್ತು ನಾನು ಯೋಚಿಸಿದೆ - ನಾನು ಪತ್ರೋನಿಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತೇನೆ, ಬಹುಶಃ ಏನಾದರೂ ಒಳ್ಳೆಯದು ಹೊರಹೊಮ್ಮುತ್ತದೆ. ಚೇತರಿಕೆ ಪ್ರಾರಂಭವಾಯಿತು. ಮತ್ತು ಬೇಸ್ ಸಹ ತೆರೆಯಿತು, ಅದು ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಸಿದ್ಧವಾಗಿದೆ.
ಪುನರಾವರ್ತನೆ ಪ್ರಾರಂಭವಾಗಿದೆ. ಆದರೆ ಒಂದು ನಿಮಿಷದ ನಂತರ ವ್ಯವಹಾರದ ದಾಖಲೆಗಳು ತನಗೆ ಸೂಕ್ತವಲ್ಲ ಎಂಬ ದೋಷದಿಂದ ಅವಳು ಬಿದ್ದಳು.
ನಾನು ಮತ್ತೆ ಮರುಪ್ರಾರಂಭಿಸಲು ಯೋಚಿಸಿದೆ. ನಾನು ಮತ್ತೆ ಪತ್ರೋನಿಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದೆ, ಮತ್ತು ನಾನು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲಿಲ್ಲ, ಆದರೆ ಅದು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮಾಂತ್ರಿಕವಾಗಿ ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಎಂಬ ಭರವಸೆಯಲ್ಲಿ ಪತ್ರೋನಿಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದೆ.
ಪುನರಾವರ್ತನೆಯು ಮತ್ತೆ ಪ್ರಾರಂಭವಾಯಿತು, ಆದರೆ ವಹಿವಾಟು ಲಾಗ್‌ನಲ್ಲಿನ ಗುರುತುಗಳು ವಿಭಿನ್ನವಾಗಿವೆ, ಅವು ಹಿಂದಿನ ಪ್ರಾರಂಭದ ಪ್ರಯತ್ನದಂತೆಯೇ ಇರಲಿಲ್ಲ. ಪುನರಾವರ್ತನೆ ಮತ್ತೆ ನಿಲ್ಲಿಸಿದೆ. ಮತ್ತು ಸಂದೇಶವು ಈಗಾಗಲೇ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿತ್ತು. ಮತ್ತು ಇದು ನನಗೆ ಹೆಚ್ಚು ತಿಳಿವಳಿಕೆ ನೀಡಲಿಲ್ಲ.
ತದನಂತರ ಇದು ನನಗೆ ಸಂಭವಿಸುತ್ತದೆ - ನಾನು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದರೆ, ಈ ಸಮಯದಲ್ಲಿ ನಾನು ವಹಿವಾಟು ಲಾಗ್‌ನಲ್ಲಿನ ಬಿಂದುವನ್ನು ಸ್ವಲ್ಪ ಮುಂದಕ್ಕೆ ಸರಿಸಲು ಪ್ರಸ್ತುತ ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಮಾಡಿ ಇದರಿಂದ ಚೇತರಿಕೆ ಇನ್ನೊಂದು ಕ್ಷಣದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ? ಜೊತೆಗೆ, ನಾವು ಇನ್ನೂ WAL ನ ಸ್ಟಾಕ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ನಾನು ಪತ್ರೋನಿಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದೆ, ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಒಂದೆರಡು ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಮಾಡಿದೆ, ಅದು ತೆರೆದಾಗ ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ಒಂದೆರಡು ರೀಸ್ಟಾರ್ಟ್ ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಮಾಡಿದೆ. ಮತ್ತು ಇದು ಸಹಾಯ ಮಾಡಿತು. ಅದು ಏಕೆ ಸಹಾಯ ಮಾಡಿದೆ ಮತ್ತು ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡಿದೆ ಎಂದು ನಾನು ದೀರ್ಘಕಾಲ ಯೋಚಿಸಿದೆ. ಮತ್ತು ಪ್ರತಿಕೃತಿ ಪ್ರಾರಂಭವಾಯಿತು. ಮತ್ತು ಪ್ರತಿಕೃತಿ ಇನ್ನು ಮುಂದೆ ಹರಿದಿಲ್ಲ.
ನನಗೆ ಅಂತಹ ಸಮಸ್ಯೆಯು ಹೆಚ್ಚು ನಿಗೂಢವಾದವುಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ಅದರಲ್ಲಿ ನಿಜವಾಗಿಯೂ ಏನಾಯಿತು ಎಂಬುದರ ಕುರಿತು ನಾನು ಇನ್ನೂ ಒಗಟು ಮಾಡುತ್ತಿದ್ದೇನೆ.
ಇಲ್ಲಿ ಪರಿಣಾಮಗಳೇನು? ಪಾಟ್ರೋನಿ ಉದ್ದೇಶಿಸಿದಂತೆ ಮತ್ತು ಯಾವುದೇ ದೋಷಗಳಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡಬಹುದು. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಇದು ನಮ್ಮೊಂದಿಗೆ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ ಎಂದು 100% ಗ್ಯಾರಂಟಿ ಅಲ್ಲ. ಪ್ರತಿಕೃತಿಯು ಪ್ರಾರಂಭವಾಗಬಹುದು, ಆದರೆ ಇದು ಅರೆ-ಕೆಲಸದ ಸ್ಥಿತಿಯಲ್ಲಿರಬಹುದು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅಂತಹ ಪ್ರತಿಕೃತಿಯೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಹಳೆಯ ಡೇಟಾ ಇರುತ್ತದೆ.
ಮತ್ತು ಫೈಲರ್ ನಂತರ, ಕ್ಲಸ್ಟರ್ನೊಂದಿಗೆ ಎಲ್ಲವೂ ಕ್ರಮದಲ್ಲಿದೆ ಎಂದು ನೀವು ಯಾವಾಗಲೂ ಪರಿಶೀಲಿಸಬೇಕು, ಅಂದರೆ, ಅಗತ್ಯವಿರುವ ಸಂಖ್ಯೆಯ ಪ್ರತಿಕೃತಿಗಳಿವೆ, ಯಾವುದೇ ಪ್ರತಿಕೃತಿ ಮಂದಗತಿ ಇಲ್ಲ.
ಮತ್ತು ನಾವು ಈ ಸಮಸ್ಯೆಗಳ ಮೂಲಕ ಹೋದಂತೆ, ನಾನು ಶಿಫಾರಸುಗಳನ್ನು ಮಾಡುತ್ತೇನೆ. ನಾನು ಅವುಗಳನ್ನು ಎರಡು ಸ್ಲೈಡ್‌ಗಳಾಗಿ ಸಂಯೋಜಿಸಲು ಪ್ರಯತ್ನಿಸಿದೆ. ಬಹುಶಃ, ಎಲ್ಲಾ ಕಥೆಗಳನ್ನು ಎರಡು ಸ್ಲೈಡ್‌ಗಳಾಗಿ ಸಂಯೋಜಿಸಬಹುದು ಮತ್ತು ಮಾತ್ರ ಹೇಳಬಹುದು.
ನೀವು Patroni ಬಳಸುವಾಗ, ನೀವು ಮೇಲ್ವಿಚಾರಣೆ ಹೊಂದಿರಬೇಕು. ಆಟೋಫೈಲ್ಓವರ್ ಯಾವಾಗ ಸಂಭವಿಸಿದೆ ಎಂದು ನೀವು ಯಾವಾಗಲೂ ತಿಳಿದಿರಬೇಕು, ಏಕೆಂದರೆ ನೀವು ಆಟೋಫೈಲ್ಓವರ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ, ಕ್ಲಸ್ಟರ್ ಮೇಲೆ ನಿಮಗೆ ಯಾವುದೇ ನಿಯಂತ್ರಣವಿಲ್ಲ. ಮತ್ತು ಅದು ಕೆಟ್ಟದು.
ಪ್ರತಿ ಫೈಲರ್ ನಂತರ, ನಾವು ಯಾವಾಗಲೂ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಪರಿಶೀಲಿಸಬೇಕು. ನಾವು ಯಾವಾಗಲೂ ಅಪ್-ಟು-ಡೇಟ್ ಸಂಖ್ಯೆಯ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು, ಯಾವುದೇ ಪುನರಾವರ್ತನೆಯ ವಿಳಂಬವಿಲ್ಲ, ಸ್ಟ್ರೀಮಿಂಗ್ ರೆಪ್ಲಿಕೇಶನ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಲಾಗ್ಗಳಲ್ಲಿ ಯಾವುದೇ ದೋಷಗಳಿಲ್ಲ, ಪತ್ರೋನಿಯೊಂದಿಗೆ, DCS ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ.
ಆಟೊಮೇಷನ್ ಯಶಸ್ವಿಯಾಗಿ ಕೆಲಸ ಮಾಡಬಹುದು, ಪತ್ರೋನಿ ಉತ್ತಮ ಸಾಧನವಾಗಿದೆ. ಇದು ಕೆಲಸ ಮಾಡಬಹುದು, ಆದರೆ ಇದು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಬಯಸಿದ ಸ್ಥಿತಿಗೆ ತರುವುದಿಲ್ಲ. ಮತ್ತು ನಾವು ಅದನ್ನು ಕಂಡುಹಿಡಿಯದಿದ್ದರೆ, ನಾವು ತೊಂದರೆಗೆ ಸಿಲುಕುತ್ತೇವೆ.
ಮತ್ತು ಪತ್ರೋನಿ ಬೆಳ್ಳಿಯ ಗುಂಡು ಅಲ್ಲ. ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಪ್ರತಿಕೃತಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನೊಂದಿಗೆ ಪ್ಯಾಟ್ರೋನಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ನೋಡ್ಗಳ ನಡುವೆ ಸಂವಹನವನ್ನು ಹೇಗೆ ಒದಗಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಇನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾಗಿದೆ. ನಿಮ್ಮ ಕೈಗಳಿಂದ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಇದು ಅವಶ್ಯಕವಾಗಿದೆ.
ರೋಗನಿರ್ಣಯದ ಸಮಸ್ಯೆಯನ್ನು ನಾನು ಹೇಗೆ ಸಮೀಪಿಸುವುದು? ನಾವು ವಿಭಿನ್ನ ಕ್ಲೈಂಟ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಯಾರೂ ELK ಸ್ಟಾಕ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ, ಮತ್ತು ನಾವು 6 ಕನ್ಸೋಲ್‌ಗಳು ಮತ್ತು 2 ಟ್ಯಾಬ್‌ಗಳನ್ನು ತೆರೆಯುವ ಮೂಲಕ ಲಾಗ್‌ಗಳನ್ನು ವಿಂಗಡಿಸಬೇಕು. ಒಂದು ಟ್ಯಾಬ್‌ನಲ್ಲಿ, ಇವುಗಳು ಪ್ರತಿ ನೋಡ್‌ಗೆ ಪ್ಯಾಟ್ರೋನಿ ಲಾಗ್ಗಳು, ಇನ್ನೊಂದು ಟ್ಯಾಬ್‌ನಲ್ಲಿ, ಇವುಗಳು ಕಾನ್ಸುಲ್ ಲಾಗ್ಗಳು ಅಥವಾ ಅಗತ್ಯವಿದ್ದರೆ ಪೋಸ್ಟ್ಗ್ರೆಸ್. ಇದನ್ನು ನಿರ್ಣಯಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ.
ನಾನು ಯಾವ ವಿಧಾನಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇನೆ? ಮೊದಲನೆಯದಾಗಿ, ಫೈಲರ್ ಬಂದಾಗ ನಾನು ಯಾವಾಗಲೂ ನೋಡುತ್ತೇನೆ. ಮತ್ತು ನನಗೆ ಇದು ಜಲಾನಯನ ಪ್ರದೇಶವಾಗಿದೆ. ಫೈಲರ್‌ನ ಮೊದಲು, ಫೈಲರ್ ಸಮಯದಲ್ಲಿ ಮತ್ತು ಫೈಲರ್ ನಂತರ ಏನಾಯಿತು ಎಂದು ನಾನು ನೋಡುತ್ತೇನೆ. ಫೈಲ್ ಓವರ್ ಎರಡು ಅಂಕಗಳನ್ನು ಹೊಂದಿದೆ: ಇದು ಪ್ರಾರಂಭ ಮತ್ತು ಅಂತಿಮ ಸಮಯ.
ಮುಂದೆ, ನಾನು ಫೈಲರ್ ಮೊದಲು ಈವೆಂಟ್‌ಗಳಿಗಾಗಿ ಲಾಗ್‌ಗಳನ್ನು ನೋಡುತ್ತೇನೆ, ಅದು ಫೈಲರ್‌ಗೆ ಹಿಂದಿನದು, ಅಂದರೆ ಫೈಲರ್ ಸಂಭವಿಸಿದ ಕಾರಣಗಳಿಗಾಗಿ ನಾನು ಹುಡುಕುತ್ತೇನೆ.
ಮತ್ತು ಇದು ಏನಾಯಿತು ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಚಿತ್ರವನ್ನು ನೀಡುತ್ತದೆ ಇದರಿಂದ ಅಂತಹ ಸಂದರ್ಭಗಳು ಸಂಭವಿಸುವುದಿಲ್ಲ (ಮತ್ತು ಪರಿಣಾಮವಾಗಿ, ಯಾವುದೇ ಫೈಲರ್ ಇಲ್ಲ).
ಮತ್ತು ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲಿ ನೋಡುತ್ತೇವೆ? ನಾನು ಕಾಣುವೆನು:
- ಮೊದಲಿಗೆ, ಪ್ಯಾಟ್ರೋನಿ ಲಾಗ್‌ಗಳಿಗೆ.
- ಮುಂದೆ, ನಾನು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಲಾಗ್‌ಗಳನ್ನು ಅಥವಾ ಡಿಸಿಎಸ್ ಲಾಗ್‌ಗಳನ್ನು ನೋಡುತ್ತೇನೆ, ಅದು ಪ್ಯಾಟ್ರೋನಿ ಲಾಗ್ಗಳಲ್ಲಿ ಕಂಡುಬಂದಿದೆ.
- ಮತ್ತು ಸಿಸ್ಟಮ್ ಲಾಗ್ಗಳು ಕೆಲವೊಮ್ಮೆ ಫೈಲರ್‌ಗೆ ಕಾರಣವಾದವುಗಳ ಬಗ್ಗೆ ತಿಳುವಳಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ.
ಪಾಟ್ರೋನಿ ಬಗ್ಗೆ ನನಗೆ ಹೇಗೆ ಅನಿಸುತ್ತದೆ? ನಾನು ಪತ್ರೋನಿಯೊಂದಿಗೆ ಉತ್ತಮ ಸಂಬಂಧವನ್ನು ಹೊಂದಿದ್ದೇನೆ. ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಇದು ಇಂದಿನ ಅತ್ಯುತ್ತಮವಾಗಿದೆ. ನನಗೆ ಅನೇಕ ಇತರ ಉತ್ಪನ್ನಗಳು ತಿಳಿದಿವೆ. ಅವುಗಳೆಂದರೆ Stolon, Repmgr, Pg_auto_failover, PAF. 4 ಉಪಕರಣಗಳು. ನಾನು ಅವೆಲ್ಲವನ್ನೂ ಪ್ರಯತ್ನಿಸಿದೆ. ಪತ್ರೋನಿ ನನ್ನ ನೆಚ್ಚಿನದು.
ಅವರು ನನ್ನನ್ನು ಕೇಳಿದರೆ: "ನಾನು ಪತ್ರೋನಿಯನ್ನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇನೆಯೇ?". ನಾನು ಹೌದು ಎಂದು ಹೇಳುತ್ತೇನೆ, ಏಕೆಂದರೆ ನಾನು ಪತ್ರೋನಿಯನ್ನು ಇಷ್ಟಪಡುತ್ತೇನೆ. ಮತ್ತು ನಾನು ಅದನ್ನು ಹೇಗೆ ಬೇಯಿಸುವುದು ಎಂದು ಕಲಿತಿದ್ದೇನೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ನಾನು ಪ್ರಸ್ತಾಪಿಸಿದ ಸಮಸ್ಯೆಗಳ ಹೊರತಾಗಿ ಪ್ಯಾಟ್ರೋನಿಯಲ್ಲಿ ಇತರ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂಬುದನ್ನು ನೋಡಲು ನೀವು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ನೀವು ಯಾವಾಗಲೂ ಪುಟವನ್ನು ಪರಿಶೀಲಿಸಬಹುದು GitHub ನಲ್ಲಿ. ಹಲವಾರು ವಿಭಿನ್ನ ಕಥೆಗಳಿವೆ ಮತ್ತು ಅನೇಕ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯಗಳನ್ನು ಅಲ್ಲಿ ಚರ್ಚಿಸಲಾಗಿದೆ. ಮತ್ತು ಪರಿಣಾಮವಾಗಿ, ಕೆಲವು ದೋಷಗಳನ್ನು ಪರಿಚಯಿಸಲಾಯಿತು ಮತ್ತು ಪರಿಹರಿಸಲಾಗಿದೆ, ಅಂದರೆ, ಇದು ಆಸಕ್ತಿದಾಯಕ ಓದುವಿಕೆಯಾಗಿದೆ.
ಜನರು ತಮ್ಮ ಕಾಲಿಗೆ ಗುಂಡು ಹಾರಿಸಿಕೊಳ್ಳುವ ಬಗ್ಗೆ ಕೆಲವು ಆಸಕ್ತಿದಾಯಕ ಕಥೆಗಳಿವೆ. ಬಹಳ ತಿಳಿವಳಿಕೆ. ಹಾಗೆ ಮಾಡುವುದು ಅನಿವಾರ್ಯವಲ್ಲ ಎಂದು ನೀವು ಓದಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ. ನಾನೇ ಟಿಕ್ ಮಾಡಿದೆ.
ಮತ್ತು ಈ ಯೋಜನೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದಕ್ಕಾಗಿ ನಾನು ಝಲ್ಯಾಂಡೊಗೆ ದೊಡ್ಡ ಧನ್ಯವಾದ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ, ಅವುಗಳೆಂದರೆ ಅಲೆಕ್ಸಾಂಡರ್ ಕುಕುಶ್ಕಿನ್ ಮತ್ತು ಅಲೆಕ್ಸಿ ಕ್ಲುಕಿನ್. ಅಲೆಕ್ಸಿ ಕ್ಲುಕಿನ್ ಸಹ-ಲೇಖಕರಲ್ಲಿ ಒಬ್ಬರು, ಅವರು ಇನ್ನು ಮುಂದೆ ಜಲಾಂಡೋದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ಆದರೆ ಈ ಉತ್ಪನ್ನದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದ ಇಬ್ಬರು ವ್ಯಕ್ತಿಗಳು.
ಮತ್ತು ಪತ್ರೋನಿ ತುಂಬಾ ತಂಪಾದ ವಿಷಯ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಅವಳು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದಳು ಎಂದು ನನಗೆ ಸಂತೋಷವಾಗಿದೆ, ಅದು ಅವಳೊಂದಿಗೆ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ. ಮತ್ತು ಪತ್ರೋನಿಗೆ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಬರೆಯುವ ಎಲ್ಲಾ ಕೊಡುಗೆದಾರರಿಗೆ ದೊಡ್ಡ ಧನ್ಯವಾದಗಳು. ವಯಸ್ಸಾದಂತೆ ಪತ್ರೋನಿ ಹೆಚ್ಚು ಪ್ರಬುದ್ಧ, ತಂಪಾಗಿ ಮತ್ತು ದಕ್ಷತೆ ಹೊಂದುತ್ತಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಇದು ಈಗಾಗಲೇ ಕ್ರಿಯಾತ್ಮಕವಾಗಿದೆ, ಆದರೆ ಇದು ಇನ್ನೂ ಉತ್ತಮಗೊಳ್ಳುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಆದ್ದರಿಂದ, ನೀವು ಪತ್ರೋನಿಯನ್ನು ಬಳಸಲು ಯೋಜಿಸಿದರೆ, ನಂತರ ಭಯಪಡಬೇಡಿ. ಇದು ಉತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ, ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು ಮತ್ತು ಬಳಸಬಹುದು.
ಅಷ್ಟೇ. ನೀವು ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಕೇಳಿ.
ಪ್ರಶ್ನೆಗಳು
ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ಫೈಲರ್ ನಂತರ ನೀವು ಇನ್ನೂ ಅಲ್ಲಿ ಬಹಳ ಎಚ್ಚರಿಕೆಯಿಂದ ನೋಡಬೇಕಾದರೆ, ನಮಗೆ ಸ್ವಯಂಚಾಲಿತ ಫೈಲರ್ ಏಕೆ ಬೇಕು?
ಏಕೆಂದರೆ ಇದು ಹೊಸ ವಿಷಯ. ನಾವು ಅವಳೊಂದಿಗೆ ಒಂದು ವರ್ಷ ಮಾತ್ರ ಇದ್ದೇವೆ. ಸುರಕ್ಷಿತವಾಗಿರುವುದು ಉತ್ತಮ. ನಾವು ಒಳಗೆ ಬರಲು ಬಯಸುತ್ತೇವೆ ಮತ್ತು ಎಲ್ಲವೂ ನಿಜವಾಗಿಯೂ ಅದು ಮಾಡಬೇಕಾದ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದೆ ಎಂದು ನೋಡಲು ಬಯಸುತ್ತೇವೆ. ಇದು ವಯಸ್ಕರ ಅಪನಂಬಿಕೆಯ ಮಟ್ಟವಾಗಿದೆ - ಎರಡು ಬಾರಿ ಪರಿಶೀಲಿಸುವುದು ಮತ್ತು ನೋಡುವುದು ಉತ್ತಮ.
ಉದಾಹರಣೆಗೆ, ನಾವು ಬೆಳಿಗ್ಗೆ ಹೋಗಿ ನೋಡಿದೆವು, ಸರಿ?
ಬೆಳಿಗ್ಗೆ ಅಲ್ಲ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಆಟೋಫೈಲ್ ಬಗ್ಗೆ ತಕ್ಷಣವೇ ಕಲಿಯುತ್ತೇವೆ. ನಾವು ಅಧಿಸೂಚನೆಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ, ಆಟೋಫೈಲ್ ಸಂಭವಿಸಿರುವುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. ನಾವು ತಕ್ಷಣವೇ ಹೋಗಿ ನೋಡುತ್ತೇವೆ. ಆದರೆ ಈ ಎಲ್ಲಾ ತಪಾಸಣೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣಾ ಮಟ್ಟಕ್ಕೆ ತರಬೇಕು. ನೀವು REST API ಮೂಲಕ Patroni ಅನ್ನು ಪ್ರವೇಶಿಸಿದರೆ, ಇತಿಹಾಸವಿದೆ. ಫೈಲರ್ ಸಂಭವಿಸಿದಾಗ ಇತಿಹಾಸದ ಮೂಲಕ ನೀವು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ನೋಡಬಹುದು. ಇದರ ಆಧಾರದ ಮೇಲೆ, ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು. ನೀವು ಇತಿಹಾಸವನ್ನು ನೋಡಬಹುದು, ಎಷ್ಟು ಘಟನೆಗಳು ಇದ್ದವು. ನಾವು ಹೆಚ್ಚಿನ ಈವೆಂಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ಸ್ವಯಂ ಫೈಲ್ ಸಂಭವಿಸಿದೆ. ನೀವು ಹೋಗಿ ನೋಡಬಹುದು. ಅಥವಾ ನಮ್ಮ ಮಾನಿಟರಿಂಗ್ ಯಾಂತ್ರೀಕೃತಗೊಂಡವು ನಾವು ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿದೆ, ಯಾವುದೇ ವಿಳಂಬವಿಲ್ಲ ಮತ್ತು ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ.
ಧನ್ಯವಾದಗಳು!
ಉತ್ತಮ ಕಥೆಗಾಗಿ ತುಂಬಾ ಧನ್ಯವಾದಗಳು! ನಾವು ಡಿಸಿಎಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪೋಸ್ಟ್ಗ್ರೆಸ್ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಎಲ್ಲೋ ದೂರಕ್ಕೆ ಸ್ಥಳಾಂತರಿಸಿದರೆ, ಈ ಕ್ಲಸ್ಟರ್‌ಗೆ ನಿಯತಕಾಲಿಕವಾಗಿ ಸೇವೆ ಸಲ್ಲಿಸಬೇಕೇ? DCS ಕ್ಲಸ್ಟರ್ನ ಕೆಲವು ತುಣುಕುಗಳನ್ನು ಆಫ್ ಮಾಡಬೇಕಾದ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು ಯಾವುವು, ಅವುಗಳನ್ನು ಏನಾದರೂ ಮಾಡಬೇಕು, ಇತ್ಯಾದಿ. ಈ ಸಂಪೂರ್ಣ ರಚನೆಯು ಹೇಗೆ ಉಳಿದುಕೊಂಡಿದೆ? ಮತ್ತು ನೀವು ಈ ಕೆಲಸಗಳನ್ನು ಹೇಗೆ ಮಾಡುತ್ತೀರಿ?
ಒಂದು ಕಂಪನಿಗೆ, ಸಮಸ್ಯೆಗಳ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಮಾಡುವುದು ಅಗತ್ಯವಾಗಿತ್ತು, ಒಂದು ಘಟಕ ಅಥವಾ ಹಲವಾರು ಘಟಕಗಳು ವಿಫಲವಾದರೆ ಏನಾಗುತ್ತದೆ. ಈ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಪ್ರಕಾರ, ನಾವು ಅನುಕ್ರಮವಾಗಿ ಎಲ್ಲಾ ಘಟಕಗಳ ಮೂಲಕ ಹೋಗುತ್ತೇವೆ ಮತ್ತು ಈ ಘಟಕಗಳ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಸನ್ನಿವೇಶಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ. ಅಂತೆಯೇ, ಪ್ರತಿ ವೈಫಲ್ಯದ ಸನ್ನಿವೇಶದಲ್ಲಿ, ನೀವು ಚೇತರಿಕೆಗೆ ಕ್ರಿಯಾ ಯೋಜನೆಯನ್ನು ಹೊಂದಬಹುದು. ಮತ್ತು DCS ನ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಪ್ರಮಾಣಿತ ಮೂಲಸೌಕರ್ಯದ ಭಾಗವಾಗಿ ಬರುತ್ತದೆ. ಮತ್ತು ನಿರ್ವಾಹಕರು ಅದನ್ನು ನಿರ್ವಹಿಸುತ್ತಾರೆ ಮತ್ತು ನಾವು ಈಗಾಗಲೇ ಅದನ್ನು ನಿರ್ವಹಿಸುವ ನಿರ್ವಾಹಕರು ಮತ್ತು ಅಪಘಾತಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಅದನ್ನು ಸರಿಪಡಿಸುವ ಅವರ ಸಾಮರ್ಥ್ಯವನ್ನು ಅವಲಂಬಿಸಿದ್ದೇವೆ. ಯಾವುದೇ ಡಿಸಿಎಸ್ ಇಲ್ಲದಿದ್ದರೆ, ನಾವು ಅದನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ನಾವು ಅದನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ನಾವು ಜವಾಬ್ದಾರರಲ್ಲ, ಆದರೆ ಹೇಗೆ ಮತ್ತು ಏನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು ಎಂಬುದರ ಕುರಿತು ನಾವು ಶಿಫಾರಸುಗಳನ್ನು ನೀಡುತ್ತೇವೆ.
ಅಂದರೆ, ಆತಿಥೇಯರೊಂದಿಗೆ ಏನನ್ನಾದರೂ ಮಾಡುವ ಮೊದಲು ನಾನು ಪತ್ರೋನಿಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಕು, ಫೈಲರ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಕು, ಎಲ್ಲವನ್ನೂ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಕು ಎಂದು ನಾನು ಸರಿಯಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆಯೇ?
ಇದು ಡಿಸಿಎಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಾವು ಎಷ್ಟು ನೋಡ್ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಅನೇಕ ನೋಡ್‌ಗಳಿದ್ದರೆ ಮತ್ತು ನಾವು ನೋಡ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ಮಾತ್ರ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದರೆ (ಪ್ರತಿಕೃತಿ), ನಂತರ ಕ್ಲಸ್ಟರ್ ಕೋರಂ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಮತ್ತು ಪತ್ರೋನಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ. ಮತ್ತು ಯಾವುದನ್ನೂ ಪ್ರಚೋದಿಸಲಾಗಿಲ್ಲ. ನಾವು ಹೆಚ್ಚು ನೋಡ್ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಕೆಲವು ಸಂಕೀರ್ಣ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದರ ಅನುಪಸ್ಥಿತಿಯು ಕೋರಮ್ ಅನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ, ಆಗ - ಹೌದು, ಪತ್ರೋನಿಯನ್ನು ವಿರಾಮಗೊಳಿಸುವುದು ಅರ್ಥಪೂರ್ಣವಾಗಬಹುದು. ಇದು ಅನುಗುಣವಾದ ಆಜ್ಞೆಯನ್ನು ಹೊಂದಿದೆ - patronictl ವಿರಾಮ, patronictl ಪುನರಾರಂಭ. ನಾವು ವಿರಾಮಗೊಳಿಸುತ್ತೇವೆ ಮತ್ತು ಆ ಸಮಯದಲ್ಲಿ ಆಟೋಫೈಲರ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ನಾವು DCS ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಿರ್ವಹಣೆಯನ್ನು ಮಾಡುತ್ತೇವೆ, ನಂತರ ನಾವು ವಿರಾಮವನ್ನು ತೆಗೆದುಹಾಕುತ್ತೇವೆ ಮತ್ತು ಜೀವಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ.
ತುಂಬಾ ಧನ್ಯವಾದಗಳು!
ನಿಮ್ಮ ವರದಿಗಾಗಿ ತುಂಬಾ ಧನ್ಯವಾದಗಳು! ಡೇಟಾ ಕಳೆದುಹೋಗುವುದರ ಬಗ್ಗೆ ಉತ್ಪನ್ನ ತಂಡವು ಹೇಗೆ ಭಾವಿಸುತ್ತದೆ?
ಉತ್ಪನ್ನ ತಂಡಗಳು ಕಾಳಜಿ ವಹಿಸುವುದಿಲ್ಲ ಮತ್ತು ತಂಡದ ಪ್ರಮುಖರು ಚಿಂತಿತರಾಗಿದ್ದಾರೆ.
ಯಾವ ಗ್ಯಾರಂಟಿಗಳಿವೆ?
ಖಾತರಿಗಳು ತುಂಬಾ ಕಷ್ಟ. ಅಲೆಕ್ಸಾಂಡರ್ ಕುಕುಶ್ಕಿನ್ ಅವರು "RPO ಮತ್ತು RTO ಅನ್ನು ಹೇಗೆ ಲೆಕ್ಕ ಹಾಕಬೇಕು" ಎಂಬ ವರದಿಯನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಅಂದರೆ ಚೇತರಿಕೆಯ ಸಮಯ ಮತ್ತು ನಾವು ಎಷ್ಟು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು. ನಾವು ಈ ಸ್ಲೈಡ್‌ಗಳನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು ಮತ್ತು ಅವುಗಳನ್ನು ಅಧ್ಯಯನ ಮಾಡಬೇಕು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನನಗೆ ನೆನಪಿರುವಂತೆ, ಈ ವಿಷಯಗಳನ್ನು ಹೇಗೆ ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದು ಎಂಬುದರ ಕುರಿತು ನಿರ್ದಿಷ್ಟ ಹಂತಗಳಿವೆ. ನಾವು ಎಷ್ಟು ವಹಿವಾಟುಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು, ಎಷ್ಟು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು. ಒಂದು ಆಯ್ಕೆಯಾಗಿ, ನಾವು ಪ್ಯಾಟ್ರೋನಿ ಮಟ್ಟದಲ್ಲಿ ಸಿಂಕ್ರೊನಸ್ ಪುನರಾವರ್ತನೆಯನ್ನು ಬಳಸಬಹುದು, ಆದರೆ ಇದು ಎರಡು ಅಂಚಿನ ಕತ್ತಿಯಾಗಿದೆ: ನಾವು ಡೇಟಾ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಅಥವಾ ನಾವು ವೇಗವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ. ಸಿಂಕ್ರೊನಸ್ ಪುನರಾವರ್ತನೆ ಇದೆ, ಆದರೆ ಇದು ಡೇಟಾ ನಷ್ಟದ ವಿರುದ್ಧ 100% ರಕ್ಷಣೆಯನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ.
ಅಲೆಕ್ಸಿ, ಉತ್ತಮ ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ಶೂನ್ಯ ಮಟ್ಟದ ರಕ್ಷಣೆಗಾಗಿ ಪತ್ರೋನಿಯನ್ನು ಬಳಸುವ ಅನುಭವವಿದೆಯೇ? ಅಂದರೆ, ಸಿಂಕ್ರೊನಸ್ ಸ್ಟ್ಯಾಂಡ್‌ಬೈ ಜೊತೆಯಲ್ಲಿ? ಇದು ಮೊದಲ ಪ್ರಶ್ನೆ. ಮತ್ತು ಎರಡನೇ ಪ್ರಶ್ನೆ. ನೀವು ವಿಭಿನ್ನ ಪರಿಹಾರಗಳನ್ನು ಬಳಸಿದ್ದೀರಿ. ನಾವು Repmgr ಅನ್ನು ಬಳಸಿದ್ದೇವೆ, ಆದರೆ ಆಟೋಫೈಲರ್ ಇಲ್ಲದೆ, ಮತ್ತು ಈಗ ನಾವು ಆಟೋಫೈಲರ್ ಅನ್ನು ಸೇರಿಸಲು ಯೋಜಿಸುತ್ತಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ಪ್ಯಾಟ್ರೋನಿಯನ್ನು ಪರ್ಯಾಯ ಪರಿಹಾರವೆಂದು ಪರಿಗಣಿಸುತ್ತೇವೆ. Repmgr ಗೆ ಹೋಲಿಸಿದರೆ ನೀವು ಏನು ಪ್ರಯೋಜನಗಳನ್ನು ಹೇಳಬಹುದು?
ಮೊದಲ ಪ್ರಶ್ನೆಯು ಸಿಂಕ್ರೊನಸ್ ಪ್ರತಿಕೃತಿಗಳ ಬಗ್ಗೆ. ಇಲ್ಲಿ ಯಾರೂ ಸಿಂಕ್ರೊನಸ್ ಪುನರಾವರ್ತನೆಯನ್ನು ಬಳಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಎಲ್ಲರೂ ಹೆದರುತ್ತಾರೆ (ಹಲವಾರು ಗ್ರಾಹಕರು ಈಗಾಗಲೇ ಇದನ್ನು ಬಳಸುತ್ತಿದ್ದಾರೆ, ತಾತ್ವಿಕವಾಗಿ, ಅವರು ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಗಮನಿಸಲಿಲ್ಲ - ಸ್ಪೀಕರ್ ಟಿಪ್ಪಣಿ) ಆದರೆ ಸಿಂಕ್ರೊನಸ್ ರೆಪ್ಲಿಕೇಶನ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕನಿಷ್ಠ ಮೂರು ನೋಡ್‌ಗಳಿರಬೇಕು ಎಂಬ ನಿಯಮವನ್ನು ನಾವೇ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ ನಾವು ಎರಡು ನೋಡ್ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಮಾಸ್ಟರ್ ಅಥವಾ ಪ್ರತಿಕೃತಿ ವಿಫಲವಾದರೆ, ಪ್ಯಾಟ್ರೋನಿ ಈ ನೋಡ್ ಅನ್ನು ಸ್ವತಂತ್ರ ಮೋಡ್‌ಗೆ ಬದಲಾಯಿಸುತ್ತದೆ ಇದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಮುಂದುವರಿಯುತ್ತದೆ ಕೆಲಸ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಡೇಟಾ ನಷ್ಟದ ಅಪಾಯವಿದೆ.
ಎರಡನೇ ಪ್ರಶ್ನೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ನಾವು Repmgr ಅನ್ನು ಬಳಸಿದ್ದೇವೆ ಮತ್ತು ಐತಿಹಾಸಿಕ ಕಾರಣಗಳಿಗಾಗಿ ಇನ್ನೂ ಕೆಲವು ಕ್ಲೈಂಟ್‌ಗಳೊಂದಿಗೆ ಮಾಡುತ್ತಿದ್ದೇವೆ. ಏನು ಹೇಳಬಹುದು? Patroni ಒಂದು ಆಟೋಫೈಲರ್ ಔಟ್ ಆಫ್ ದಿ ಬಾಕ್ಸ್‌ನೊಂದಿಗೆ ಬರುತ್ತದೆ, Repmgr ಹೆಚ್ಚುವರಿ ವೈಶಿಷ್ಟ್ಯವಾಗಿ ಆಟೋಫೈಲರ್‌ನೊಂದಿಗೆ ಬರುತ್ತದೆ ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬೇಕಾಗಿದೆ. ನಾವು ಪ್ರತಿ ನೋಡ್‌ನಲ್ಲಿ Repmgr ಡೀಮನ್ ಅನ್ನು ಚಲಾಯಿಸಬೇಕು ಮತ್ತು ನಂತರ ನಾವು ಆಟೋಫೈಲರ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು.
ಪೋಸ್ಟ್ಗ್ರೆಸ್ ನೋಡ್ಗಳು ಜೀವಂತವಾಗಿದೆಯೇ ಎಂದು Repmgr ಪರಿಶೀಲಿಸುತ್ತದೆ. Repmgr ಪ್ರಕ್ರಿಯೆಗಳು ಪರಸ್ಪರ ಅಸ್ತಿತ್ವವನ್ನು ಪರಿಶೀಲಿಸುತ್ತವೆ, ಇದು ತುಂಬಾ ಪರಿಣಾಮಕಾರಿ ವಿಧಾನವಲ್ಲ. ನೆಟ್ವರ್ಕ್ ಪ್ರತ್ಯೇಕತೆಯ ಸಂಕೀರ್ಣ ಪ್ರಕರಣಗಳು ಇರಬಹುದು, ಇದರಲ್ಲಿ ದೊಡ್ಡ Repmgr ಕ್ಲಸ್ಟರ್ ಹಲವಾರು ಚಿಕ್ಕದಾಗಿದೆ ಮತ್ತು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು. ನಾನು ಬಹಳ ಸಮಯದಿಂದ Repmgr ಅನ್ನು ಅನುಸರಿಸುತ್ತಿಲ್ಲ, ಬಹುಶಃ ಅದನ್ನು ಸರಿಪಡಿಸಲಾಗಿದೆ ... ಅಥವಾ ಇರಬಹುದು. ಆದರೆ ಸ್ಟೋಲನ್, ಪ್ಯಾಟ್ರೋನಿ ಮಾಡುವಂತೆ DCS ನಲ್ಲಿನ ಕ್ಲಸ್ಟರ್ನ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ತೆಗೆದುಹಾಕುವುದು ಅತ್ಯಂತ ಕಾರ್ಯಸಾಧ್ಯವಾದ ಆಯ್ಕೆಯಾಗಿದೆ.
ಅಲೆಕ್ಸಿ, ನನಗೆ ಒಂದು ಪ್ರಶ್ನೆ ಇದೆ, ಬಹುಶಃ ಒಂದು ಲೇಮರ್. ಮೊದಲ ಉದಾಹರಣೆಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ, ನೀವು ಸ್ಥಳೀಯ ಯಂತ್ರದಿಂದ ದೂರಸ್ಥ ಹೋಸ್ಟ್‌ಗೆ DCS ಅನ್ನು ಸರಿಸಿದ್ದೀರಿ. ನೆಟ್ವರ್ಕ್ ತನ್ನದೇ ಆದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿರುವ ಒಂದು ವಿಷಯ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ, ಅದು ತನ್ನದೇ ಆದ ಮೇಲೆ ವಾಸಿಸುತ್ತದೆ. ಮತ್ತು ಕೆಲವು ಕಾರಣಗಳಿಂದ DCS ಕ್ಲಸ್ಟರ್ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ? ನಾನು ಕಾರಣಗಳನ್ನು ಹೇಳುವುದಿಲ್ಲ, ಅವುಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಇರಬಹುದು: ನೆಟ್‌ವರ್ಕರ್‌ಗಳ ವಕ್ರ ಕೈಗಳಿಂದ ನಿಜವಾದ ಸಮಸ್ಯೆಗಳಿಗೆ.
ನಾನು ಅದನ್ನು ಜೋರಾಗಿ ಹೇಳಲಿಲ್ಲ, ಆದರೆ DCS ಕ್ಲಸ್ಟರ್ ಸಹ ವಿಫಲವಾಗಿರಬೇಕು, ಅಂದರೆ ಕೋರಮ್ ಅನ್ನು ಪೂರೈಸಲು ಇದು ಬೆಸ ಸಂಖ್ಯೆಯ ನೋಡ್‌ಗಳಾಗಿರಬೇಕು. DCS ಕ್ಲಸ್ಟರ್ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ ಅಥವಾ ಕೋರಮ್ ಅನ್ನು ಪೂರೈಸಲಾಗದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ, ಅಂದರೆ ಕೆಲವು ರೀತಿಯ ನೆಟ್ವರ್ಕ್ ವಿಭಜನೆ ಅಥವಾ ನೋಡ್ ವೈಫಲ್ಯ? ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ಯಾಟ್ರೋನಿ ಕ್ಲಸ್ಟರ್ ಓದಲು ಮಾತ್ರ ಮೋಡ್‌ಗೆ ಹೋಗುತ್ತದೆ. ಪ್ಯಾಟ್ರೋನಿ ಕ್ಲಸ್ಟರ್ ಕ್ಲಸ್ಟರ್ನ ಸ್ಥಿತಿಯನ್ನು ಮತ್ತು ಏನು ಮಾಡಬೇಕೆಂದು ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇದು DCS ಅನ್ನು ಸಂಪರ್ಕಿಸಲು ಮತ್ತು ಅಲ್ಲಿ ಹೊಸ ಕ್ಲಸ್ಟರ್ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ ಓದಲು ಮಾತ್ರ ಹೋಗುತ್ತದೆ. ಮತ್ತು ಆಪರೇಟರ್‌ನಿಂದ ಹಸ್ತಚಾಲಿತ ಹಸ್ತಕ್ಷೇಪಕ್ಕಾಗಿ ಅಥವಾ DCS ಚೇತರಿಸಿಕೊಳ್ಳಲು ಕಾಯುತ್ತದೆ.
ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ, DCS ನಮಗೆ ಬೇಸ್‌ನಷ್ಟೇ ಮುಖ್ಯವಾದ ಸೇವೆಯಾಗುತ್ತದೆ?
ಹೌದು ಹೌದು. ಅನೇಕ ಆಧುನಿಕ ಕಂಪನಿಗಳಲ್ಲಿ, ಸೇವಾ ಡಿಸ್ಕವರಿ ಮೂಲಸೌಕರ್ಯದ ಅವಿಭಾಜ್ಯ ಅಂಗವಾಗಿದೆ. ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಇರುವ ಮೊದಲೇ ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತಿದೆ. ತುಲನಾತ್ಮಕವಾಗಿ ಹೇಳುವುದಾದರೆ, ಮೂಲಸೌಕರ್ಯವನ್ನು ಪ್ರಾರಂಭಿಸಲಾಯಿತು, DC ಯಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು ನಾವು ತಕ್ಷಣವೇ ಸೇವೆಯ ಅನ್ವೇಷಣೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅದು ಕಾನ್ಸುಲ್ ಆಗಿದ್ದರೆ, ಅದರ ಮೇಲೆ DNS ಅನ್ನು ನಿರ್ಮಿಸಬಹುದು. ಇದು Etcd ಆಗಿದ್ದರೆ, ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಒಂದು ಭಾಗವಿರಬಹುದು, ಅದರಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ನಿಯೋಜಿಸಲಾಗುವುದು. ಸರ್ವಿಸ್ ಡಿಸ್ಕವರಿ ಈಗಾಗಲೇ ಆಧುನಿಕ ಮೂಲಸೌಕರ್ಯಗಳ ಅವಿಭಾಜ್ಯ ಅಂಗವಾಗಿದೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ. ಮತ್ತು ಅವರು ಡೇಟಾಬೇಸ್‌ಗಳಿಗಿಂತ ಮುಂಚೆಯೇ ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತಾರೆ.
ಧನ್ಯವಾದಗಳು!
ಮೂಲ: www.habr.com