ಪರಿಚಯ

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

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

ಈಗ ಆಡಳಿತ ಮಂಡಳಿ ಅನುಮತಿ ನೀಡಿದೆ MIT ಪರವಾನಗಿ ಅಡಿಯಲ್ಲಿ ಮುಕ್ತ ಮೂಲ ಸಮುದಾಯಕ್ಕೆ ಯೋಜನೆಯನ್ನು ತೆರೆಯಿರಿ. README ಅನ್ನು ಶೀಘ್ರದಲ್ಲೇ ಇಂಗ್ಲಿಷ್‌ಗೆ ಅನುವಾದಿಸಲಾಗುತ್ತದೆ (ಏಕೆಂದರೆ ಮುಖ್ಯ ಗ್ರಾಹಕರು ಪೇಸ್‌ಮೇಕರ್ ಮತ್ತು PostgreSQL ಡೆವಲಪರ್‌ಗಳು ಎಂದು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ), ಮತ್ತು README ನ ಹಳೆಯ ರಷ್ಯನ್ ಆವೃತ್ತಿಯನ್ನು (ಭಾಗಶಃ) ಈ ಲೇಖನದ ರೂಪದಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲು ನಾನು ನಿರ್ಧರಿಸಿದೆ.

ವರ್ಚುವಲ್ ಗಣಕಗಳಲ್ಲಿ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲಾಗಿದೆ ವರ್ಚುವಲ್ಬಾಕ್ಸ್. ಒಟ್ಟು 12 ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು (ಒಟ್ಟು 36GiB) ನಿಯೋಜಿಸಲಾಗುವುದು, ಇದು 4 ದೋಷ-ಸಹಿಷ್ಣು ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ರೂಪಿಸುತ್ತದೆ (ವಿಭಿನ್ನ ಆಯ್ಕೆಗಳು). ಮೊದಲ ಎರಡು ಕ್ಲಸ್ಟರ್‌ಗಳು ಎರಡು PostgreSQL ಸರ್ವರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ, ಅವು ವಿಭಿನ್ನ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿವೆ ಮತ್ತು ಸಾಮಾನ್ಯ ಸರ್ವರ್ ಸಾಕ್ಷಿ c ಕೋರಂ ಸಾಧನ (ಮೂರನೇ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಅಗ್ಗದ ವರ್ಚುವಲ್ ಗಣಕದಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಲಾಗಿದೆ), ಇದು ಅನಿಶ್ಚಿತತೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ 50% / 50%, ನಿಮ್ಮ ಮತವನ್ನು ಪಕ್ಷಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ನೀಡಿ. ಮೂರು ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಮೂರನೇ ಕ್ಲಸ್ಟರ್: ಒಬ್ಬ ಮಾಸ್ಟರ್, ಇಬ್ಬರು ಗುಲಾಮರು, ನಂ ಕೋರಂ ಸಾಧನ. ನಾಲ್ಕನೇ ಕ್ಲಸ್ಟರ್ ನಾಲ್ಕು PostgreSQL ಸರ್ವರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ಪ್ರತಿ ಡೇಟಾ ಸೆಂಟರ್‌ಗೆ ಎರಡು: ಒಂದು ಮಾಸ್ಟರ್, ಉಳಿದ ಪ್ರತಿಕೃತಿಗಳು ಮತ್ತು ಬಳಸುತ್ತದೆ ಸಾಕ್ಷಿ c ಕೋರಂ ಸಾಧನ. ನಾಲ್ಕನೆಯದು ಎರಡು ಸರ್ವರ್‌ಗಳು ಅಥವಾ ಒಂದು ಡೇಟಾ ಕೇಂದ್ರದ ವೈಫಲ್ಯವನ್ನು ತಡೆದುಕೊಳ್ಳಬಲ್ಲದು. ಅಗತ್ಯವಿದ್ದರೆ ಈ ಪರಿಹಾರವನ್ನು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಅಳೆಯಬಹುದು.

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

ಆವೃತ್ತಿಗಳು

v0. VirtualBox 7 ನಲ್ಲಿ CentOS 11 ಮತ್ತು PostgreSQL 6.1 ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಕ್ಲಸ್ಟರ್ ರಚನೆ

ಎಲ್ಲಾ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಬಹು ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಇರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಒಂದು ಫ್ಲಾಟ್ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು ಒಂದೇ ಡೇಟಾ ಕೇಂದ್ರದ ವೈಫಲ್ಯ ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ತಡೆದುಕೊಳ್ಳಬೇಕು. ಅದಕ್ಕೇ ಅಸಾಧ್ಯ ವಿರುದ್ಧ ರಕ್ಷಣೆಗಾಗಿ ಬಳಸಿ ವಿಭಜಿತ-ಮೆದುಳು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಪೇಸ್‌ಮೇಕರ್ ತಂತ್ರಜ್ಞಾನ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಸ್ಟೋನಿತ್ (ತಲೆಯಲ್ಲಿ ಇತರ ನೋಡ್ ಅನ್ನು ಶೂಟ್ ಮಾಡಿ) ಅಥವಾ ಫೆನ್ಸಿಂಗ್. ಇದರ ಸಾರ: ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ನೋಡ್‌ಗಳು ಕೆಲವು ನೋಡ್‌ನಲ್ಲಿ ಏನಾದರೂ ತಪ್ಪಾಗಿದೆ ಎಂದು ಅನುಮಾನಿಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಅದು ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿಲ್ಲ ಅಥವಾ ತಪ್ಪಾಗಿ ವರ್ತಿಸುತ್ತಿದೆ, ನಂತರ ಅವರು ಅದನ್ನು "ಬಾಹ್ಯ" ಸಾಧನಗಳ ಮೂಲಕ ಬಲವಂತವಾಗಿ ಆಫ್ ಮಾಡುತ್ತಾರೆ, ಉದಾಹರಣೆಗೆ, IPMI ಅಥವಾ UPS ನಿಯಂತ್ರಣ ಕಾರ್ಡ್ . ಆದರೆ ಒಂದೇ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ, IPMI ಅಥವಾ UPS ಸರ್ವರ್ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರೆಸುವ ಸಂದರ್ಭಗಳಲ್ಲಿ ಮಾತ್ರ ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಸಂಪೂರ್ಣ ಡೇಟಾ ಸೆಂಟರ್ ವಿಫಲವಾದಾಗ (ಉದಾಹರಣೆಗೆ, ಶಕ್ತಿಯನ್ನು ಕಳೆದುಕೊಂಡಾಗ) ಹೆಚ್ಚು ದುರಂತದ ವೈಫಲ್ಯದಿಂದ ರಕ್ಷಿಸಲು ನಾವು ಇಲ್ಲಿ ಯೋಜಿಸುತ್ತೇವೆ. ಮತ್ತು ಅಂತಹ ನಿರಾಕರಣೆಯೊಂದಿಗೆ, ಎಲ್ಲವೂ ಸ್ಟೊನಿತ್-ಸಾಧನಗಳು (IPMI, UPS, ಇತ್ಯಾದಿ) ಸಹ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ.

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

ನೋಡ್‌ಗಳ ಸಂಖ್ಯೆಯು ಸಮವಾಗಿದ್ದರೆ (ಎರಡು ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಒಂದು ಕ್ಲಸ್ಟರ್), ಆಗ ಅನಿಶ್ಚಿತತೆ ಎಂದು ಕರೆಯಲ್ಪಡಬಹುದು 50% / 50% (ಐವತ್ತು ಐವತ್ತು) ನೆಟ್ವರ್ಕ್ ಪ್ರತ್ಯೇಕತೆಯು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿಖರವಾಗಿ ಅರ್ಧದಷ್ಟು ಭಾಗಿಸಿದಾಗ. ಆದ್ದರಿಂದ, ಸಮ ಸಂಖ್ಯೆಯ ನೋಡ್‌ಗಳಿಗಾಗಿ, ನಾವು ಸೇರಿಸುತ್ತೇವೆ ಕೋರಂ ಸಾಧನ ಮೂರನೇ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಅಗ್ಗದ ವರ್ಚುವಲ್ ಗಣಕದಲ್ಲಿ ಪ್ರಾರಂಭಿಸಬಹುದಾದ ಬೇಡಿಕೆಯಿಲ್ಲದ ಡೀಮನ್ ಆಗಿದೆ. ಅವನು ತನ್ನ ಮತವನ್ನು ಒಂದು ಭಾಗಕ್ಕೆ (ಅವನು ನೋಡುತ್ತಾನೆ) ನೀಡುತ್ತಾನೆ ಮತ್ತು ಆ ಮೂಲಕ 50%/50% ಅನಿಶ್ಚಿತತೆಯನ್ನು ಪರಿಹರಿಸುತ್ತಾನೆ. ಕೋರಂ ಸಾಧನವನ್ನು ಪ್ರಾರಂಭಿಸುವ ಸರ್ವರ್ ಅನ್ನು ನಾನು ಹೆಸರಿಸಿದೆ ಸಾಕ್ಷಿ (repmgr ನಿಂದ ಪರಿಭಾಷೆ, ನಾನು ಅದನ್ನು ಇಷ್ಟಪಟ್ಟಿದ್ದೇನೆ).

ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸ್ಥಳದಿಂದ ಸ್ಥಳಕ್ಕೆ ಸ್ಥಳಾಂತರಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ದೋಷಯುಕ್ತ ಸರ್ವರ್‌ಗಳಿಂದ ಆರೋಗ್ಯಕರವಾದವುಗಳಿಗೆ ಅಥವಾ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರ ಆಜ್ಞೆಯ ಮೇರೆಗೆ. ಆದ್ದರಿಂದ ಗ್ರಾಹಕರಿಗೆ ಅಗತ್ಯವಿರುವ ಸಂಪನ್ಮೂಲಗಳು ಎಲ್ಲಿವೆ ಎಂದು ತಿಳಿಯುತ್ತದೆ (ಎಲ್ಲಿ ಸಂಪರ್ಕಿಸಬೇಕು?), ತೇಲುವ IP (ಫ್ಲೋಟ್ ಐಪಿ) ಇವುಗಳು ಪೇಸ್‌ಮೇಕರ್ ನೋಡ್‌ಗಳ ಸುತ್ತಲೂ ಚಲಿಸಬಲ್ಲ IPಗಳಾಗಿವೆ (ಎಲ್ಲವೂ ಫ್ಲಾಟ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿದೆ). ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಸಂಪನ್ಮೂಲವನ್ನು (ಸೇವೆ) ಸಂಕೇತಿಸುತ್ತದೆ ಮತ್ತು ಈ ಸೇವೆಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆಯಲು ನೀವು ಸಂಪರ್ಕಿಸಬೇಕಾದ ಸ್ಥಳದಲ್ಲಿ (ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಡೇಟಾಬೇಸ್) ಇರುತ್ತದೆ.

ತುಚಂಕಾ1 (ಸಂಕೋಚನದೊಂದಿಗೆ ಸರ್ಕ್ಯೂಟ್)

ರಚನೆ

ನಾವು ಕಡಿಮೆ ಲೋಡ್‌ನೊಂದಿಗೆ ಅನೇಕ ಸಣ್ಣ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಇದಕ್ಕಾಗಿ ಓದಲು ಮಾತ್ರ ವಹಿವಾಟುಗಳಿಗಾಗಿ ಹಾಟ್ ಸ್ಟ್ಯಾಂಡ್‌ಬೈ ಮೋಡ್‌ನಲ್ಲಿ ಮೀಸಲಾದ ಸ್ಲೇವ್ ಸರ್ವರ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದು ಲಾಭದಾಯಕವಲ್ಲ (ಇಂತಹ ಸಂಪನ್ಮೂಲಗಳ ವ್ಯರ್ಥ ಅಗತ್ಯವಿಲ್ಲ).

ಪ್ರತಿಯೊಂದು ಡೇಟಾ ಕೇಂದ್ರವು ಒಂದು ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಪ್ರತಿ ಸರ್ವರ್ ಎರಡು PostgreSQL ನಿದರ್ಶನಗಳನ್ನು ಹೊಂದಿದೆ (PostgreSQL ಪರಿಭಾಷೆಯಲ್ಲಿ ಅವುಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ಗಳು ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಆದರೆ ಗೊಂದಲವನ್ನು ತಪ್ಪಿಸಲು ನಾನು ಅವುಗಳನ್ನು ನಿದರ್ಶನಗಳು ಎಂದು ಕರೆಯುತ್ತೇನೆ (ಇತರ ಡೇಟಾಬೇಸ್‌ಗಳೊಂದಿಗೆ ಸಾದೃಶ್ಯದ ಮೂಲಕ), ಮತ್ತು ನಾನು ಪೇಸ್‌ಮೇಕರ್ ಕ್ಲಸ್ಟರ್‌ಗಳ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಮಾತ್ರ ಕರೆಯುತ್ತೇನೆ). ಒಂದು ನಿದರ್ಶನವು ಮಾಸ್ಟರ್ ಮೋಡ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದು ಸೇವೆಗಳನ್ನು ಮಾತ್ರ ಒದಗಿಸುತ್ತದೆ (ಫ್ಲೋಟ್ ಐಪಿ ಮಾತ್ರ ಇದಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ). ಎರಡನೆಯ ನಿದರ್ಶನವು ಎರಡನೇ ಡೇಟಾ ಸೆಂಟರ್‌ಗೆ ಗುಲಾಮನಂತೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದರ ಮಾಸ್ಟರ್ ವಿಫಲವಾದರೆ ಮಾತ್ರ ಸೇವೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ಸಮಯ ಎರಡರಲ್ಲಿ (ಮಾಸ್ಟರ್) ಕೇವಲ ಒಂದು ನಿದರ್ಶನವು ಸೇವೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ (ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ), ಎಲ್ಲಾ ಸರ್ವರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮಾಸ್ಟರ್‌ಗಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾಗಿದೆ (ಮೆಮೊರಿಯನ್ನು ಹಂಚಿಕೊಂಡ_ಬಫರ್‌ಗಳ ಸಂಗ್ರಹಕ್ಕಾಗಿ ಹಂಚಲಾಗುತ್ತದೆ, ಇತ್ಯಾದಿ), ಆದರೆ ಎರಡನೇ ನಿದರ್ಶನ ಡೇಟಾ ಸೆಂಟರ್‌ಗಳಲ್ಲಿ ಒಂದರ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿದೆ ( ಫೈಲ್ ಸಿಸ್ಟಮ್ ಕ್ಯಾಶ್ ಮೂಲಕ ಸಬ್‌ಪ್ಟಿಮಲ್ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ). ಕ್ಲಸ್ಟರ್‌ನ ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ಗುಲಾಮನು ಸೇವೆಗಳನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ (ಓದಲು ಮಾತ್ರ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುವುದಿಲ್ಲ), ಆದ್ದರಿಂದ ಅದೇ ಯಂತ್ರದಲ್ಲಿ ಮಾಸ್ಟರ್‌ನೊಂದಿಗೆ ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ ಯಾವುದೇ ಯುದ್ಧವಿಲ್ಲ.

ಎರಡು ನೋಡ್‌ಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಅಸಮಕಾಲಿಕ ಪುನರಾವರ್ತನೆಯೊಂದಿಗೆ ದೋಷ ಸಹಿಷ್ಣುತೆ ಮಾತ್ರ ಸಾಧ್ಯ, ಏಕೆಂದರೆ ಸಿಂಕ್ರೊನಸ್ ಪುನರಾವರ್ತನೆಯೊಂದಿಗೆ, ಗುಲಾಮರ ವೈಫಲ್ಯವು ಯಜಮಾನನ ನಿಲುಗಡೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಸಾಕ್ಷಿಯಾಗಲು ವಿಫಲತೆ

ಸಾಕ್ಷಿಯಾಗಲು ವಿಫಲತೆ (ಕೋರಂ ಸಾಧನ) ನಾನು ತುಚಂಕಾ1 ಕ್ಲಸ್ಟರ್‌ಗೆ ಮಾತ್ರ ಪರಿಗಣಿಸುತ್ತೇನೆ, ಉಳಿದೆಲ್ಲವುಗಳೊಂದಿಗೆ ಇದು ಒಂದೇ ಕಥೆಯಾಗಿರುತ್ತದೆ. ಸಾಕ್ಷಿ ವಿಫಲವಾದರೆ, ಕ್ಲಸ್ಟರ್ ರಚನೆಯಲ್ಲಿ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ, ಎಲ್ಲವೂ ಅದೇ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. ಆದರೆ ಕೋರಂ 2 ರಲ್ಲಿ 3 ಆಗುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಯಾವುದೇ ನಂತರದ ವೈಫಲ್ಯವು ಕ್ಲಸ್ಟರ್‌ಗೆ ಮಾರಕವಾಗಿರುತ್ತದೆ. ಇನ್ನಾದರೂ ತುರ್ತಾಗಿ ಸರಿಪಡಿಸಬೇಕು.

ತುಚಂಕಾ1 ನಿರಾಕರಣೆ

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

ತುಚಂಕಾ2 (ಶಾಸ್ತ್ರೀಯ)

ರಚನೆ

ಎರಡು ನೋಡ್ಗಳ ಕ್ಲಾಸಿಕ್ ಯೋಜನೆ. ಯಜಮಾನನು ಒಬ್ಬನ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತಾನೆ, ಗುಲಾಮನು ಎರಡನೆಯದರಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾನೆ. ಎರಡೂ ವಿನಂತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು (ಗುಲಾಮನನ್ನು ಓದಲು ಮಾತ್ರ), ಆದ್ದರಿಂದ ಎರಡನ್ನೂ ಫ್ಲೋಟ್ IP ಮೂಲಕ ಸೂಚಿಸಲಾಗುತ್ತದೆ: krogan2 ಮಾಸ್ಟರ್, krogan2s1 ಗುಲಾಮ. ಯಜಮಾನ ಮತ್ತು ಗುಲಾಮ ಇಬ್ಬರೂ ತಪ್ಪು ಸಹಿಷ್ಣುತೆಯನ್ನು ಹೊಂದಿರುತ್ತಾರೆ.

ಎರಡು ನೋಡ್‌ಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಅಸಮಕಾಲಿಕ ಪುನರಾವರ್ತನೆಯೊಂದಿಗೆ ದೋಷ ಸಹಿಷ್ಣುತೆ ಮಾತ್ರ ಸಾಧ್ಯ, ಏಕೆಂದರೆ ಸಿಂಕ್ರೊನಸ್ ಪುನರಾವರ್ತನೆಯೊಂದಿಗೆ, ಗುಲಾಮರ ವೈಫಲ್ಯವು ಮಾಸ್ಟರ್ನ ನಿಲುಗಡೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ತುಚಂಕಾ2 ನಿರಾಕರಣೆ

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

ತುಚಂಕಾ4 (ಅನೇಕ ಗುಲಾಮರು)

ರಚನೆ

ಈಗಾಗಲೇ ಮತ್ತೊಂದು ವಿಪರೀತವಾಗಿದೆ. ಬಹಳಷ್ಟು ಓದಲು-ಮಾತ್ರ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಡೇಟಾಬೇಸ್‌ಗಳಿವೆ (ಹೆಚ್ಚಿನ-ಲೋಡ್ ಸೈಟ್‌ನ ವಿಶಿಷ್ಟ ಪ್ರಕರಣ). Tuchanka4 ಅಂತಹ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಮೂರು ಅಥವಾ ಹೆಚ್ಚು ಗುಲಾಮರು ಇರಬಹುದು, ಆದರೆ ಇನ್ನೂ ಹೆಚ್ಚು ಅಲ್ಲ. ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಗುಲಾಮರೊಂದಿಗೆ, ಕ್ರಮಾನುಗತ ಪ್ರತಿಕೃತಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಆವಿಷ್ಕರಿಸುವುದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. ಕನಿಷ್ಠ ಸಂದರ್ಭದಲ್ಲಿ (ಚಿತ್ರದಲ್ಲಿ), ಎರಡು ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಎರಡು ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಪ್ರತಿಯೊಂದೂ PostgreSQL ನಿದರ್ಶನದೊಂದಿಗೆ.

ಈ ಯೋಜನೆಯ ಮತ್ತೊಂದು ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ ಒಂದು ಸಿಂಕ್ರೊನಸ್ ಪ್ರತಿಕೃತಿಯನ್ನು ಸಂಘಟಿಸಲು ಈಗಾಗಲೇ ಸಾಧ್ಯವಿದೆ. ಮಾಸ್ಟರ್‌ನಂತೆಯೇ ಅದೇ ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಕೃತಿಗೆ ಬದಲಾಗಿ, ಸಾಧ್ಯವಾದರೆ, ಮತ್ತೊಂದು ಡೇಟಾ ಕೇಂದ್ರಕ್ಕೆ ಪುನರಾವರ್ತಿಸಲು ಇದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ. ಮಾಸ್ಟರ್ ಮತ್ತು ಪ್ರತಿ ಗುಲಾಮರನ್ನು ಫ್ಲೋಟ್ ಐಪಿ ಮೂಲಕ ಸೂಚಿಸಲಾಗಿದೆ. ಅದೃಷ್ಟವಶಾತ್, ಗುಲಾಮರ ನಡುವೆ ಹೇಗಾದರೂ ವಿನಂತಿಗಳನ್ನು ಸಮತೋಲನಗೊಳಿಸುವುದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ sql ಪ್ರಾಕ್ಸಿ, ಉದಾಹರಣೆಗೆ, ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ. ವಿಭಿನ್ನ ರೀತಿಯ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ವಿಭಿನ್ನ ಪ್ರಕಾರಗಳು ಬೇಕಾಗಬಹುದು sql ಪ್ರಾಕ್ಸಿ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಮಾತ್ರ ಯಾರಿಗೆ ಬೇಕು ಎಂದು ತಿಳಿದಿದೆ. ಈ ಕಾರ್ಯವನ್ನು ಬಾಹ್ಯ ಡೀಮನ್ ಅಥವಾ ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿ (ಸಂಪರ್ಕ ಪೂಲ್) ಇತ್ಯಾದಿಗಳಿಂದ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಇದೆಲ್ಲವೂ ವಿಫಲವಾದ ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರ್‌ನ ವಿಷಯವನ್ನು ಮೀರಿದೆ (ವೈಫಲ್ಯ SQL ಪ್ರಾಕ್ಸಿ ಕ್ಲೈಂಟ್ ತಪ್ಪು ಸಹಿಷ್ಣುತೆಯೊಂದಿಗೆ ಸ್ವತಂತ್ರವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು).

ತುಚಂಕಾ4 ನಿರಾಕರಣೆ

ಒಂದು ಡೇಟಾ ಸೆಂಟರ್ (ಅಂದರೆ, ಎರಡು ಸರ್ವರ್‌ಗಳು) ವಿಫಲವಾದರೆ, ಸಾಕ್ಷಿಗಳು ಎರಡನೆಯದಕ್ಕೆ ಮತ ಚಲಾಯಿಸುತ್ತಾರೆ. ಪರಿಣಾಮವಾಗಿ, ಎರಡನೇ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಎರಡು ಸರ್ವರ್‌ಗಳು ಚಾಲನೆಯಲ್ಲಿವೆ: ಒಂದು ಮಾಸ್ಟರ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿದೆ, ಮತ್ತು ಮಾಸ್ಟರ್ ಫ್ಲೋಟ್ ಐಪಿ ಪಾಯಿಂಟ್‌ಗಳು (ಓದಲು-ಬರೆಯಲು ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಲು); ಮತ್ತು ಎರಡನೇ ಸರ್ವರ್‌ನಲ್ಲಿ ಸಿಂಕ್ರೊನಸ್ ರೆಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಸ್ಲೇವ್ ಚಾಲನೆಯಲ್ಲಿದೆ, ಮತ್ತು ಸ್ಲೇವ್ ಫ್ಲೋಟ್ IP ಗಳಲ್ಲಿ ಒಂದು ಅದನ್ನು ಸೂಚಿಸುತ್ತದೆ (ಓದಲು-ಮಾತ್ರ ವಿನಂತಿಗಳಿಗಾಗಿ).

ಗಮನಿಸಬೇಕಾದ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಎಲ್ಲಾ ಸ್ಲೇವ್ ಫ್ಲೋಟ್ ಐಪಿಗಳು ಕೆಲಸಗಾರರಾಗಿರುವುದಿಲ್ಲ, ಆದರೆ ಒಬ್ಬರು ಮಾತ್ರ. ಮತ್ತು ಅದರೊಂದಿಗೆ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಲು ಅದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ sql ಪ್ರಾಕ್ಸಿ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಮಾತ್ರ ಉಳಿದಿರುವ ಫ್ಲೋಟ್ IP ಗೆ ಮರುನಿರ್ದೇಶಿಸಲಾಗಿದೆ; ಮತ್ತು ವೇಳೆ sql ಪ್ರಾಕ್ಸಿ ಇಲ್ಲ, ನಂತರ ನೀವು ಸಂಪರ್ಕ URL ನಲ್ಲಿ ಅಲ್ಪವಿರಾಮದಿಂದ ಬೇರ್ಪಡಿಸಲಾದ ಎಲ್ಲಾ ಫ್ಲೋಟ್ IP ಸ್ಲೇವ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಜೊತೆಗೆ libpq ಸಂಪರ್ಕವು ಮೊದಲ ಕೆಲಸ ಮಾಡುವ ಐಪಿಗೆ ಇರುತ್ತದೆ, ಇದನ್ನು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ. ಬಹುಶಃ ಇತರ ಗ್ರಂಥಾಲಯಗಳಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ಜೆಡಿಬಿಸಿ, ಇದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಅವಶ್ಯಕವಾಗಿದೆ sql ಪ್ರಾಕ್ಸಿ. ಗುಲಾಮರಿಗೆ ಫ್ಲೋಟ್ ಐಪಿಗಳನ್ನು ಒಂದೇ ಸರ್ವರ್‌ನಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ಹೆಚ್ಚಿಸುವುದನ್ನು ನಿಷೇಧಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಅವುಗಳಲ್ಲಿ ಹಲವಾರು ಚಾಲನೆಯಲ್ಲಿದ್ದರೆ ಅವುಗಳನ್ನು ಸ್ಲೇವ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಸಮವಾಗಿ ವಿತರಿಸಲಾಗುತ್ತದೆ.

ಎರಡನೆಯದು: ಡೇಟಾ ಸೆಂಟರ್ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಸಹ, ಸಿಂಕ್ರೊನಸ್ ಪುನರಾವರ್ತನೆಯನ್ನು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ದ್ವಿತೀಯಕ ವೈಫಲ್ಯ ಸಂಭವಿಸಿದರೂ, ಅಂದರೆ, ಉಳಿದ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿನ ಎರಡು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದು ವಿಫಲವಾದರೆ, ಕ್ಲಸ್ಟರ್, ಸೇವೆಗಳನ್ನು ಒದಗಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದರೂ, ಬದ್ಧತೆಯ ದೃಢೀಕರಣವನ್ನು ನೀಡಿದ ಎಲ್ಲಾ ಬದ್ಧ ವಹಿವಾಟುಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. (ದ್ವಿತೀಯ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಯಾವುದೇ ನಷ್ಟದ ಮಾಹಿತಿ ಇರುವುದಿಲ್ಲ).

ತುಚಂಕಾ3 (3 ಡೇಟಾ ಕೇಂದ್ರಗಳು)

ರಚನೆ

ಮೂರು ಸಂಪೂರ್ಣ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಡೇಟಾ ಕೇಂದ್ರಗಳಿರುವ ಪರಿಸ್ಥಿತಿಗೆ ಇದು ಕ್ಲಸ್ಟರ್ ಆಗಿದೆ, ಪ್ರತಿಯೊಂದೂ ಸಂಪೂರ್ಣವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಡೇಟಾಬೇಸ್ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿದೆ. ಈ ವಿಷಯದಲ್ಲಿ ಕೋರಂ ಸಾಧನ ಅಗತ್ಯವಿಲ್ಲ. ಒಂದು ದತ್ತಾಂಶ ಕೇಂದ್ರವು ಮಾಸ್ಟರ್‌ನಿಂದ ಸಿಬ್ಬಂದಿಯನ್ನು ಹೊಂದಿದೆ, ಇನ್ನೆರಡು ಗುಲಾಮರಿಂದ ಸಿಬ್ಬಂದಿಯನ್ನು ಹೊಂದಿದೆ. ಪುನರಾವರ್ತನೆಯು ಸಿಂಕ್ರೊನಸ್ ಆಗಿದೆ, ಯಾವುದೇ (ಸ್ಲೇವ್1, ಸ್ಲೇವ್2) ಎಂದು ಟೈಪ್ ಮಾಡಿ, ಅಂದರೆ, ಯಾವುದೇ ಗುಲಾಮರು ತಾನು ಬದ್ಧತೆಯನ್ನು ಒಪ್ಪಿಕೊಂಡಿದ್ದಾರೆ ಎಂದು ಮೊದಲು ಪ್ರತಿಕ್ರಿಯಿಸಿದಾಗ ಕ್ಲೈಂಟ್ ಬದ್ಧತೆಯ ದೃಢೀಕರಣವನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ. ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮಾಸ್ಟರ್‌ಗೆ ಒಂದು ಫ್ಲೋಟ್ ಐಪಿ ಮತ್ತು ಎರಡು ಗುಲಾಮರಿಗೆ ಸೂಚಿಸಲಾಗುತ್ತದೆ. Tuchanka4 ಭಿನ್ನವಾಗಿ, ಎಲ್ಲಾ ಮೂರು ಫ್ಲೋಟ್ IP ಗಳು ದೋಷ-ಸಹಿಷ್ಣು. ನೀವು ಬಳಸಬಹುದಾದ ಓದಲು-ಮಾತ್ರ SQL ಪ್ರಶ್ನೆಗಳನ್ನು ಸಮತೋಲನಗೊಳಿಸಲು sql ಪ್ರಾಕ್ಸಿ (ಪ್ರತ್ಯೇಕ ದೋಷ ಸಹಿಷ್ಣುತೆಯೊಂದಿಗೆ), ಅಥವಾ ಒಂದು ಸ್ಲೇವ್ ಫ್ಲೋಟ್ IP ಅನ್ನು ಅರ್ಧದಷ್ಟು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಮತ್ತು ಇತರ ಅರ್ಧವನ್ನು ಎರಡನೆಯವರಿಗೆ ನಿಯೋಜಿಸಿ.

ತುಚಂಕಾ3 ನಿರಾಕರಣೆ

ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಒಂದು ವಿಫಲವಾದರೆ, ಎರಡು ಉಳಿಯುತ್ತದೆ. ಒಂದರಲ್ಲಿ, ಮಾಸ್ಟರ್‌ನಿಂದ ಮಾಸ್ಟರ್ ಮತ್ತು ಫ್ಲೋಟ್ ಐಪಿಯನ್ನು ಹೆಚ್ಚಿಸಲಾಗಿದೆ, ಎರಡನೆಯದರಲ್ಲಿ - ಸ್ಲೇವ್ ಮತ್ತು ಎರಡೂ ಸ್ಲೇವ್ ಫ್ಲೋಟ್ ಐಪಿಗಳು (ಉದಾಹರಣೆಗೆ ಎರಡೂ ಸ್ಲೇವ್ ಫ್ಲೋಟ್ ಐಪಿಗಳಿಂದ ಎಲ್ಲಾ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಸಂಪನ್ಮೂಲಗಳ ಡಬಲ್ ಮೀಸಲು ಹೊಂದಿರಬೇಕು). ಮಾಸ್ಟರ್ಸ್ ಮತ್ತು ಗುಲಾಮರ ನಡುವೆ ಸಿಂಕ್ರೊನಸ್ ಪ್ರತಿಕೃತಿ. ಅಲ್ಲದೆ, ಎರಡು ಡೇಟಾ ಕೇಂದ್ರಗಳ ನಾಶದ ಸಂದರ್ಭದಲ್ಲಿ (ಅವು ಏಕಕಾಲದಲ್ಲಿ ನಾಶವಾಗದಿದ್ದರೆ) ಕ್ಲಸ್ಟರ್ ಬದ್ಧ ಮತ್ತು ದೃಢಪಡಿಸಿದ ವಹಿವಾಟುಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಉಳಿಸುತ್ತದೆ (ಮಾಹಿತಿ ನಷ್ಟವಾಗುವುದಿಲ್ಲ).

ಫೈಲ್ ರಚನೆ ಮತ್ತು ನಿಯೋಜನೆಯ ವಿವರವಾದ ವಿವರಣೆಯನ್ನು ಸೇರಿಸದಿರಲು ನಾನು ನಿರ್ಧರಿಸಿದೆ. ಸುತ್ತಲೂ ಆಡಲು ಬಯಸುವ ಯಾರಾದರೂ README ನಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಓದಬಹುದು. ನಾನು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯ ವಿವರಣೆಯನ್ನು ಮಾತ್ರ ಒದಗಿಸುತ್ತಿದ್ದೇನೆ.

ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷಾ ವ್ಯವಸ್ಥೆ

ವಿವಿಧ ದೋಷಗಳನ್ನು ಅನುಕರಿಸುವ ಮೂಲಕ ಕ್ಲಸ್ಟರ್‌ಗಳ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು, ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷಾ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸಲಾಗಿದೆ. ಸ್ಕ್ರಿಪ್ಟ್ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ test/failure. ನೀವು ಪರೀಕ್ಷಿಸಲು ಬಯಸುವ ಕ್ಲಸ್ಟರ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ ನಿಯತಾಂಕಗಳಾಗಿ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಉದಾಹರಣೆಗೆ ಈ ಆಜ್ಞೆ:

test/failure 2 3

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

ಟರ್ಮಿನಲ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುವ ಕ್ಲಸ್ಟರ್‌ಗಳ ಸಂಖ್ಯೆಗೆ ಅನುಗುಣವಾಗಿ ಕಾಲಮ್‌ಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ; ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ (ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ನಲ್ಲಿ) ನಾಲ್ಕು ಇವೆ. ನಾನು ತುಚಂಕಾ 2 ರ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಕಾಲಮ್‌ಗಳ ವಿಷಯಗಳನ್ನು ವಿವರಿಸುತ್ತೇನೆ. ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ನಲ್ಲಿನ ಫಲಕಗಳನ್ನು ಎಣಿಸಲಾಗಿದೆ:

1. ಪರೀಕ್ಷಾ ಅಂಕಿಅಂಶಗಳನ್ನು ಇಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ. ಕಾಲಮ್‌ಗಳು:
   • ವೈಫಲ್ಯ - ದೋಷವನ್ನು ಅನುಕರಿಸುವ ಪರೀಕ್ಷೆಯ ಹೆಸರು (ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿನ ಕಾರ್ಯ).
   • ಪ್ರತಿಕ್ರಿಯೆ - ಕ್ಲಸ್ಟರ್ ತನ್ನ ಕಾರ್ಯವನ್ನು ಚೇತರಿಸಿಕೊಂಡ ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಅಂಕಗಣಿತದ ಸರಾಸರಿ ಸಮಯ. ದೋಷವನ್ನು ಅನುಕರಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಪ್ರಾರಂಭದಿಂದ ಕ್ಲಸ್ಟರ್ ತನ್ನ ಕಾರ್ಯವನ್ನು ಪುನಃಸ್ಥಾಪಿಸುವ ಮತ್ತು ಸೇವೆಗಳನ್ನು ಒದಗಿಸುವುದನ್ನು ಮುಂದುವರಿಸಲು ಸಾಧ್ಯವಾಗುವ ಕ್ಷಣದವರೆಗೆ ಇದನ್ನು ಅಳೆಯಲಾಗುತ್ತದೆ. ಸಮಯವು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ, ಆರು ಸೆಕೆಂಡುಗಳು (ಇದು ಹಲವಾರು ಗುಲಾಮರನ್ನು ಹೊಂದಿರುವ ಸಮೂಹಗಳಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ (ತುಚಂಕಾ 3 ಮತ್ತು ತುಚಂಕಾ 4)), ಇದರರ್ಥ ದೋಷವು ಅಸಮಕಾಲಿಕ ಗುಲಾಮರ ಮೇಲಿದೆ ಮತ್ತು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಲಿಲ್ಲ; ಇಲ್ಲ ಕ್ಲಸ್ಟರ್ ಸ್ಟೇಟ್ ಸ್ವಿಚ್‌ಗಳು.
   • ವಿಚಲನ - ಮೌಲ್ಯದ ಹರಡುವಿಕೆಯನ್ನು (ನಿಖರತೆ) ತೋರಿಸುತ್ತದೆ ಪ್ರತಿಕ್ರಿಯೆ ಪ್ರಮಾಣಿತ ವಿಚಲನ ವಿಧಾನವನ್ನು ಬಳಸುವುದು.
   • ಎಣಿಕೆ - ಈ ಪರೀಕ್ಷೆಯನ್ನು ಎಷ್ಟು ಬಾರಿ ನಡೆಸಲಾಯಿತು.
2. ಕ್ಲಸ್ಟರ್ ಪ್ರಸ್ತುತ ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಕಿರು ಲಾಗ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಪುನರಾವರ್ತನೆ (ಪರೀಕ್ಷೆ) ಸಂಖ್ಯೆ, ಸಮಯಸ್ಟ್ಯಾಂಪ್ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಹೆಸರನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ. ಹೆಚ್ಚು ಸಮಯ ಓಡುವುದು (> 5 ನಿಮಿಷಗಳು) ಸಮಸ್ಯೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ.
3. ಹೃದಯ (ಹೃದಯ) - ಪ್ರಸ್ತುತ ಸಮಯ. ಕಾರ್ಯಕ್ಷಮತೆಯ ದೃಶ್ಯ ಮೌಲ್ಯಮಾಪನಕ್ಕಾಗಿ ಮಾಸ್ಟರ್ ಫ್ಲೋಟ್ ಐಪಿ ಮಾಸ್ಟರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರಸ್ತುತ ಸಮಯವನ್ನು ನಿರಂತರವಾಗಿ ಅದರ ಟೇಬಲ್‌ಗೆ ಬರೆಯಲಾಗುತ್ತದೆ. ಯಶಸ್ವಿಯಾದರೆ, ಫಲಿತಾಂಶವನ್ನು ಈ ಫಲಕದಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ.
4. ಬೀಟ್ (ನಾಡಿ) - “ಪ್ರಸ್ತುತ ಸಮಯ”, ಇದನ್ನು ಈ ಹಿಂದೆ ಸ್ಕ್ರಿಪ್ಟ್‌ನಿಂದ ದಾಖಲಿಸಲಾಗಿದೆ ಹೃದಯ ಮಾಸ್ಟರ್ ಮಾಡಲು, ಈಗ ಓದಿ ಗುಲಾಮ ಅದರ ಫ್ಲೋಟ್ ಐಪಿ ಮೂಲಕ. ಗುಲಾಮ ಮತ್ತು ಪ್ರತಿಕೃತಿಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ದೃಷ್ಟಿಗೋಚರವಾಗಿ ನಿರ್ಣಯಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ತುಚಾಂಕಾ1 ರಲ್ಲಿ ಫ್ಲೋಟ್ ಐಪಿಯೊಂದಿಗೆ ಯಾವುದೇ ಗುಲಾಮರು ಇಲ್ಲ (ಸೇವೆಗಳನ್ನು ಒದಗಿಸುವ ಗುಲಾಮರು ಇಲ್ಲ), ಆದರೆ ಎರಡು ನಿದರ್ಶನಗಳಿವೆ (ಡಿಬಿಗಳು), ಆದ್ದರಿಂದ ಅದನ್ನು ಇಲ್ಲಿ ತೋರಿಸಲಾಗುವುದಿಲ್ಲ ಬೀಟ್ಮತ್ತು ಹೃದಯ ಎರಡನೇ ನಿದರ್ಶನ.
5. ಉಪಯುಕ್ತತೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಕ್ಲಸ್ಟರ್ ಆರೋಗ್ಯವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು pcs mon. ರಚನೆ, ನೋಡ್‌ಗಳಾದ್ಯಂತ ಸಂಪನ್ಮೂಲಗಳ ವಿತರಣೆ ಮತ್ತು ಇತರ ಉಪಯುಕ್ತ ಮಾಹಿತಿಯನ್ನು ತೋರಿಸುತ್ತದೆ.
6. ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ವರ್ಚುವಲ್ ಗಣಕದಿಂದ ಸಿಸ್ಟಮ್ ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಇಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ. ಕ್ಲಸ್ಟರ್ ಎಷ್ಟು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಹೊಂದಿದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಅಂತಹ ಹೆಚ್ಚಿನ ಫಲಕಗಳು ಇರಬಹುದು. ಎರಡು ಗ್ರಾಫ್ಗಳು CPU ಲೋಡ್ (ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ಎರಡು ಪ್ರೊಸೆಸರ್‌ಗಳನ್ನು ಹೊಂದಿವೆ), ವರ್ಚುವಲ್ ಯಂತ್ರದ ಹೆಸರು, ಸಿಸ್ಟಮ್ ಲೋಡ್ (ಇದು ಸರಾಸರಿ 5, 10 ಮತ್ತು 15 ನಿಮಿಷಗಳನ್ನು ಹೊಂದಿರುವುದರಿಂದ ಲೋಡ್ ಸರಾಸರಿ ಎಂದು ಹೆಸರಿಸಲಾಗಿದೆ), ಡೇಟಾ ಮತ್ತು ಮೆಮೊರಿ ಹಂಚಿಕೆ ಪ್ರಕ್ರಿಯೆ.
7. ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುತ್ತಿರುವ ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಟ್ರೇಸ್. ಅಸಮರ್ಪಕ ಕ್ರಿಯೆಯ ಸಂದರ್ಭದಲ್ಲಿ - ಕಾರ್ಯಾಚರಣೆಯ ಹಠಾತ್ ಅಡಚಣೆ ಅಥವಾ ಅಂತ್ಯವಿಲ್ಲದ ಕಾಯುವ ಚಕ್ರ - ಇಲ್ಲಿ ನೀವು ಈ ನಡವಳಿಕೆಯ ಕಾರಣವನ್ನು ನೋಡಬಹುದು.

ಪರೀಕ್ಷೆಯನ್ನು ಎರಡು ಹಂತಗಳಲ್ಲಿ ನಡೆಸಲಾಗುತ್ತದೆ. ಮೊದಲನೆಯದಾಗಿ, ಸ್ಕ್ರಿಪ್ಟ್ ಎಲ್ಲಾ ರೀತಿಯ ಪರೀಕ್ಷೆಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಈ ಪರೀಕ್ಷೆಯನ್ನು ಅನ್ವಯಿಸಲು ಯಾದೃಚ್ಛಿಕವಾಗಿ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ. ನಂತರ ಪರೀಕ್ಷೆಯ ಅಂತ್ಯವಿಲ್ಲದ ಚಕ್ರವನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ, ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ಮತ್ತು ದೋಷವನ್ನು ಪ್ರತಿ ಬಾರಿಯೂ ಯಾದೃಚ್ಛಿಕವಾಗಿ ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ. ಟೆಸ್ಟಿಂಗ್ ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಹಠಾತ್ ಮುಕ್ತಾಯ (ಕೆಳಗಿನ ಫಲಕ) ಅಥವಾ ಯಾವುದನ್ನಾದರೂ ಕಾಯುವ ಅಂತ್ಯವಿಲ್ಲದ ಲೂಪ್ (> 5 ನಿಮಿಷಗಳ ಒಂದು ಕಾರ್ಯಾಚರಣೆಗೆ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸಮಯ, ಇದನ್ನು ಟ್ರೇಸ್‌ನಲ್ಲಿ ಕಾಣಬಹುದು) ಈ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಕೆಲವು ಪರೀಕ್ಷೆಗಳು ವಿಫಲವಾಗಿವೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ.

ಪ್ರತಿಯೊಂದು ಪರೀಕ್ಷೆಯು ಈ ಕೆಳಗಿನ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

1. ದೋಷವನ್ನು ಅನುಕರಿಸುವ ಕಾರ್ಯವನ್ನು ಪ್ರಾರಂಭಿಸಿ.
2. ರೆಡಿ? — ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ಕಾಯುತ್ತಿದೆ (ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು ಒದಗಿಸಿದಾಗ).
3. ಕ್ಲಸ್ಟರ್ ಮರುಪಡೆಯುವಿಕೆ ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ತೋರಿಸುತ್ತದೆ (ಪ್ರತಿಕ್ರಿಯೆ).
4. ಫಿಕ್ಸ್ - ಕ್ಲಸ್ಟರ್ ಅನ್ನು "ದುರಸ್ತಿ ಮಾಡಲಾಗುತ್ತಿದೆ." ಅದರ ನಂತರ ಅದು ಸಂಪೂರ್ಣ ಕಾರ್ಯಾಚರಣೆಯ ಸ್ಥಿತಿಗೆ ಮರಳಬೇಕು ಮತ್ತು ಮುಂದಿನ ಅಸಮರ್ಪಕ ಕಾರ್ಯಕ್ಕೆ ಸಿದ್ಧವಾಗಿರಬೇಕು.

ಅವರು ಏನು ಮಾಡುತ್ತಾರೆ ಎಂಬುದರ ವಿವರಣೆಯೊಂದಿಗೆ ಪರೀಕ್ಷೆಗಳ ಪಟ್ಟಿ ಇಲ್ಲಿದೆ:

• ಫೋರ್ಕ್‌ಬಾಂಬ್: ಫೋರ್ಕ್ ಬಾಂಬ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು "ಮೆಮೊರಿಯಲ್ಲಿಲ್ಲ" ರಚಿಸುತ್ತದೆ.
• ಬಾಹ್ಯಾಕಾಶ: ಹಾರ್ಡ್ ಡ್ರೈವ್ ತುಂಬಿದೆ. ಆದರೆ ಪರೀಕ್ಷೆಯು ಸಾಂಕೇತಿಕವಾಗಿದೆ; ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ರಚಿಸಲಾದ ಅತ್ಯಲ್ಪ ಹೊರೆಯೊಂದಿಗೆ, ಹಾರ್ಡ್ ಡ್ರೈವ್ ತುಂಬಿದಾಗ PostgreSQL ಸಾಮಾನ್ಯವಾಗಿ ವಿಫಲವಾಗುವುದಿಲ್ಲ.
• ಪೋಸ್ಟ್ಗ್ರೆಸ್-ಕಿಲ್: ಆಜ್ಞೆಯೊಂದಿಗೆ PostgreSQL ಅನ್ನು ಕೊಲ್ಲುತ್ತದೆ killall -KILL postgres.
• ಪೋಸ್ಟ್ಗ್ರೆಸ್-ಸ್ಟಾಪ್: PostgreSQL ಆಜ್ಞೆಯನ್ನು ಸ್ಥಗಿತಗೊಳಿಸುತ್ತದೆ killall -STOP postgres.
• ಪವರ್ಆಫ್: ಆಜ್ಞೆಯೊಂದಿಗೆ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು "ಡಿ-ಎನರ್ಜೈಸ್" ಮಾಡುತ್ತದೆ VBoxManage controlvm "виртуалка" poweroff.
• ಮರುಹೊಂದಿಸಿ: ಆಜ್ಞೆಯೊಂದಿಗೆ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ಓವರ್ಲೋಡ್ ಮಾಡುತ್ತದೆ VBoxManage controlvm "виртуалка" reset.
• SBD-ಸ್ಟಾಪ್: ಆಜ್ಞೆಯೊಂದಿಗೆ SBD ರಾಕ್ಷಸನನ್ನು ಅಮಾನತುಗೊಳಿಸುತ್ತದೆ killall -STOP sbd.
• ಮುಚ್ಚಲಾಯಿತು: SSH ಮೂಲಕ ವರ್ಚುವಲ್ ಯಂತ್ರಕ್ಕೆ ಆಜ್ಞೆಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ systemctl poweroff, ವ್ಯವಸ್ಥೆಯು ಆಕರ್ಷಕವಾಗಿ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ.
• ಅನ್ಲಿಂಕ್ ಮಾಡಿ: ನೆಟ್ವರ್ಕ್ ಪ್ರತ್ಯೇಕತೆ, ಆಜ್ಞೆ VBoxManage controlvm "виртуалка" setlinkstate1 off.

ಪ್ರಮಾಣಿತ tmux "kill-window" ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಪರೀಕ್ಷೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುವುದು Ctrl-b &, ಅಥವಾ "ಡಿಟ್ಯಾಚ್-ಕ್ಲೈಂಟ್" ಆಜ್ಞೆ Ctrl-b ಡಿ: ಈ ಹಂತದಲ್ಲಿ ಪರೀಕ್ಷೆಯು ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, tmux ಮುಚ್ಚುತ್ತದೆ, ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಆಫ್ ಮಾಡಲಾಗಿದೆ.

ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಗುರುತಿಸಲಾದ ತೊಂದರೆಗಳು

• ಈ ಕ್ಷಣದಲ್ಲಿ ವಾಚ್‌ಡಾಗ್ ಡೆಮನ್ ಎಸ್‌ಬಿಡಿ ಗಮನಿಸಿದ ಡೀಮನ್‌ಗಳನ್ನು ನಿಲ್ಲಿಸುವಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಅವುಗಳನ್ನು ಘನೀಕರಿಸುವುದಿಲ್ಲ. ಮತ್ತು, ಪರಿಣಾಮವಾಗಿ, ಘನೀಕರಣಕ್ಕೆ ಮಾತ್ರ ಕಾರಣವಾಗುವ ದೋಷಗಳು ಕೊರೊಸಿಂಕ್ и ನಿಯಂತ್ರಕ, ಆದರೆ ನೇತಾಡುವುದಿಲ್ಲ sbd... ಚೆಕ್‌ಗಾಗಿ ಕೊರೊಸಿಂಕ್ ಈಗಾಗಲೇ PR#83 (GitHub ನಲ್ಲಿ sbd), ಥ್ರೆಡ್ಗೆ ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಮಾಸ್ಟರ್. ಪೇಸ್‌ಮೇಕರ್‌ಗೆ ಇದೇ ರೀತಿಯ ಏನಾದರೂ ಇರುತ್ತದೆ ಎಂದು ಅವರು (PR#83 ರಲ್ಲಿ) ಭರವಸೆ ನೀಡಿದರು, ನಾನು ಆ ಮೂಲಕ ಆಶಿಸುತ್ತೇನೆ ರೆಡ್‌ಹ್ಯಾಟ್ 8 ಮಾಡುತ್ತೇನೆ. ಆದರೆ ಅಂತಹ "ಅಸಮರ್ಪಕ ಕಾರ್ಯಗಳು" ಊಹಾತ್ಮಕವಾಗಿವೆ ಮತ್ತು ಕೃತಕವಾಗಿ ಬಳಸಿಕೊಂಡು ಸುಲಭವಾಗಿ ಅನುಕರಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, killall -STOP corosync, ಆದರೆ ನಿಜ ಜೀವನದಲ್ಲಿ ಎಂದಿಗೂ ಭೇಟಿಯಾಗುವುದಿಲ್ಲ.

• У ನಿಯಂತ್ರಕ ಆವೃತ್ತಿಯಲ್ಲಿ ಸೆಂಟಿಒಎಸ್ ಕ್ಯುಮ್ಎಕ್ಸ್ಎಕ್ಸ್ ತಪ್ಪಾಗಿ ಹೊಂದಿಸಲಾಗಿದೆ sync_timeout у ಕೋರಂ ಸಾಧನ, ಪರಿಣಾಮವಾಗಿ ಒಂದು ನೋಡ್ ವಿಫಲವಾದರೆ, ಕೆಲವು ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ ಎರಡನೇ ನೋಡ್ ಸಹ ರೀಬೂಟ್ ಆಗುತ್ತದೆ, ಇದಕ್ಕೆ ಮಾಸ್ಟರ್ ಚಲಿಸಬೇಕಿತ್ತು. ಹಿಗ್ಗುವಿಕೆಯಿಂದ ಗುಣಪಡಿಸಲಾಗಿದೆ sync_timeout у ಕೋರಂ ಸಾಧನ ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ (ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ setup/setup1) ಈ ತಿದ್ದುಪಡಿಯನ್ನು ಡೆವಲಪರ್‌ಗಳು ಸ್ವೀಕರಿಸಲಿಲ್ಲ ನಿಯಂತ್ರಕ, ಬದಲಿಗೆ ಅವರು ಮೂಲಸೌಕರ್ಯವನ್ನು ಮರುವಿನ್ಯಾಸಗೊಳಿಸುವುದಾಗಿ ಭರವಸೆ ನೀಡಿದರು (ಕೆಲವು ಅನಿರ್ದಿಷ್ಟ ಭವಿಷ್ಯದಲ್ಲಿ) ಈ ಸಮಯಾವಧಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ.

• ಡೇಟಾಬೇಸ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅದನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರೆ LC_MESSAGES (ಪಠ್ಯ ಸಂದೇಶಗಳು) ಯುನಿಕೋಡ್ ಅನ್ನು ಬಳಸಬಹುದು, ಉದಾ. ru_RU.UTF-8, ನಂತರ ಪ್ರಾರಂಭದಲ್ಲಿ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಲೊಕೇಲ್ ಯುಟಿಎಫ್-8 ಅಲ್ಲದ ಪರಿಸರದಲ್ಲಿ, ಖಾಲಿ ವಾತಾವರಣದಲ್ಲಿ ಹೇಳಿ (ಇಲ್ಲಿ ನಿಯಂತ್ರಕ+pgsqlms(ಪಾಫ್) ಓಡುತ್ತದೆ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್), ನಂತರ ಲಾಗ್ UTF-8 ಅಕ್ಷರಗಳ ಬದಲಿಗೆ ಪ್ರಶ್ನಾರ್ಥಕ ಚಿಹ್ನೆಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಏನು ಮಾಡಬೇಕೆಂದು PostgreSQL ಡೆವಲಪರ್‌ಗಳು ಒಪ್ಪಿಕೊಂಡಿಲ್ಲ. ಇದು ವೆಚ್ಚವಾಗುತ್ತದೆ, ನೀವು ಸ್ಥಾಪಿಸಬೇಕಾಗಿದೆ LC_MESSAGES=en_US.UTF-8 ಡೇಟಾಬೇಸ್ ನಿದರ್ಶನವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವಾಗ (ರಚಿಸುವಾಗ).

• wal_receiver_timeout ಅನ್ನು ಹೊಂದಿಸಿದ್ದರೆ (ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಇದು 60s), ನಂತರ tuchanka3 ಮತ್ತು tuchanka4 ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಮಾಸ್ಟರ್‌ನಲ್ಲಿ PostgreSQL-STOP ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಪ್ರತಿಕೃತಿಯು ಹೊಸ ಮಾಸ್ಟರ್‌ಗೆ ಮರುಸಂಪರ್ಕಿಸುವುದಿಲ್ಲ. ಅಲ್ಲಿ ಪುನರಾವರ್ತನೆಯು ಸಿಂಕ್ರೊನಸ್ ಆಗಿದೆ, ಆದ್ದರಿಂದ ಗುಲಾಮ ಮಾತ್ರ ನಿಲ್ಲುವುದಿಲ್ಲ, ಆದರೆ ಹೊಸ ಮಾಸ್ಟರ್ ಕೂಡ. PostgreSQL ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವಾಗ wal_receiver_timeout=0 ಹೊಂದಿಸುವ ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

• ಸಾಂದರ್ಭಿಕವಾಗಿ ನಾನು ForkBomb ಪರೀಕ್ಷೆಯಲ್ಲಿ (ಮೆಮೊರಿ ಓವರ್‌ಫ್ಲೋ) PostgreSQL ನಲ್ಲಿ ರೆಪ್ಲಿಕೇಶನ್ ಫ್ರೀಜ್‌ಗಳನ್ನು ಗಮನಿಸಿದ್ದೇನೆ. ForkBomb ನಂತರ, ಕೆಲವೊಮ್ಮೆ ಗುಲಾಮರು ಹೊಸ ಮಾಸ್ಟರ್‌ಗೆ ಮರುಸಂಪರ್ಕಿಸದಿರಬಹುದು. ನಾನು ಇದನ್ನು tuchanka3 ಮತ್ತು tuchanka4 ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ ಎದುರಿಸಿದ್ದೇನೆ, ಅಲ್ಲಿ ಸಿಂಕ್ರೊನಸ್ ಪುನರಾವರ್ತನೆಯಿಂದಾಗಿ ಮಾಸ್ಟರ್ ಫ್ರೀಜ್ ಆಗಿದ್ದಾರೆ. ಬಹಳ ಸಮಯದ ನಂತರ (ಸುಮಾರು ಎರಡು ಗಂಟೆಗಳು) ಸಮಸ್ಯೆ ತಾನಾಗಿಯೇ ಹೋಯಿತು. ಇದನ್ನು ಸರಿಪಡಿಸಲು ಹೆಚ್ಚಿನ ಸಂಶೋಧನೆಯ ಅಗತ್ಯವಿದೆ. ರೋಗಲಕ್ಷಣಗಳು ಹಿಂದಿನ ದೋಷವನ್ನು ಹೋಲುತ್ತವೆ, ಇದು ಬೇರೆ ಕಾರಣದಿಂದ ಉಂಟಾಗುತ್ತದೆ, ಆದರೆ ಅದೇ ಪರಿಣಾಮಗಳೊಂದಿಗೆ.

ಕ್ರೋಗನ್ ಚಿತ್ರವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ವಕ್ರ ಕಲೆ ಲೇಖಕರ ಅನುಮತಿಯೊಂದಿಗೆ:

ಮೂಲ: www.habr.com