Citymobil ನಲ್ಲಿ ನಾವು MySQL ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಮ್ಮ ಮುಖ್ಯ ನಿರಂತರ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯಾಗಿ ಬಳಸುತ್ತೇವೆ. ವಿವಿಧ ಸೇವೆಗಳು ಮತ್ತು ಉದ್ದೇಶಗಳಿಗಾಗಿ ನಾವು ಹಲವಾರು ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ಮಾಸ್ಟರ್ನ ನಿರಂತರ ಲಭ್ಯತೆಯು ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ ಮತ್ತು ಅದರ ಪ್ರತ್ಯೇಕ ಭಾಗಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯ ನಿರ್ಣಾಯಕ ಸೂಚಕವಾಗಿದೆ. ಮಾಸ್ಟರ್ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ಕ್ಲಸ್ಟರ್ ಮರುಪಡೆಯುವಿಕೆ ಘಟನೆಯ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ ಮತ್ತು ಸಿಸ್ಟಮ್ ಅಲಭ್ಯತೆಯನ್ನು ಬಹಳವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಈ ಲೇಖನದಲ್ಲಿ, MySQL ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ (HA) ವಿನ್ಯಾಸವನ್ನು ನಾನು ನೋಡುತ್ತೇನೆ MySQL ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಮತ್ತು ವರ್ಚುವಲ್ ಐಪಿ ವಿಳಾಸಗಳು (ವಿಐಪಿ).

ವಿಐಪಿ ಆಧಾರಿತ HA ಪರಿಹಾರ

ಮೊದಲಿಗೆ, ನಮ್ಮ ಡೇಟಾ ಸಂಗ್ರಹಣಾ ವ್ಯವಸ್ಥೆ ಏನೆಂದು ನಾನು ನಿಮಗೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುತ್ತೇನೆ.

ನಾವು ಒಂದು ಬರೆಯಲು ಪ್ರವೇಶಿಸಬಹುದಾದ ಮಾಸ್ಟರ್ ಮತ್ತು ಬಹು ಓದಲು-ಮಾತ್ರ ಪ್ರತಿಕೃತಿಗಳೊಂದಿಗೆ ಕ್ಲಾಸಿಕ್ ರೆಪ್ಲಿಕೇಶನ್ ಸ್ಕೀಮ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಒಂದು ಕ್ಲಸ್ಟರ್ ಮಧ್ಯಂತರ ಮಾಸ್ಟರ್ ಅನ್ನು ಒಳಗೊಂಡಿರಬಹುದು - ಇತರರಿಗೆ ಪ್ರತಿಕೃತಿ ಮತ್ತು ಮಾಸ್ಟರ್ ಎರಡೂ ಆಗಿರುವ ನೋಡ್. ಗ್ರಾಹಕರು HAProxy ಮೂಲಕ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಪ್ರವೇಶಿಸುತ್ತಾರೆ, ಇದು ಲೋಡ್ ವಿತರಣೆ ಮತ್ತು ಸುಲಭ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಸಹ ಅನುಮತಿಸುತ್ತದೆ. HAProxy ಬಳಕೆಯು ಐತಿಹಾಸಿಕ ಕಾರಣಗಳಿಂದಾಗಿ, ಮತ್ತು ನಾವು ಪ್ರಸ್ತುತ ProxySQL ಗೆ ವಲಸೆ ಹೋಗುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿದ್ದೇವೆ.

ಆಧಾರದ ಮೇಲೆ ಅರೆ-ಸಿಂಕ್ರೊನಸ್ ಮೋಡ್ನಲ್ಲಿ ನಕಲು ಮಾಡಲಾಗುತ್ತದೆ GTID. ಇದರರ್ಥ ಕನಿಷ್ಠ ಒಂದು ಪ್ರತಿಕೃತಿಯು ವ್ಯವಹಾರವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪರಿಗಣಿಸುವ ಮೊದಲು ಲಾಗ್ ಮಾಡಬೇಕು. ಈ ರೆಪ್ಲಿಕೇಶನ್ ಮೋಡ್ ಮಾಸ್ಟರ್ ನೋಡ್ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಡೇಟಾ ಸುರಕ್ಷತೆಯ ನಡುವೆ ಅತ್ಯುತ್ತಮ ಸಮತೋಲನವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಮೂಲಭೂತವಾಗಿ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಸ್ಟರ್‌ನಿಂದ ಬಳಸಿ ಪ್ರತಿಕೃತಿಗಳಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ Row Based Replication (RBR), ಆದರೆ ಕೆಲವು ನೋಡ್‌ಗಳು ಹೊಂದಿರಬಹುದು mixed binlog format.

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

ಮಾಸ್ಟರ್ ವಿಫಲವಾದರೆ ಅದನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ಒಂದು ಸರಳ ಮಾರ್ಗವೆಂದರೆ ತೇಲುವ ವಿಐಪಿ ವಿಳಾಸಗಳನ್ನು ಬಳಸುವುದು.

ಮುಂದುವರಿಯುವ ಮೊದಲು ಈ ಪರಿಹಾರದ ಬಗ್ಗೆ ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದದ್ದು:

• ವಿಐಪಿ ಎನ್ನುವುದು ಐಪಿ ವಿಳಾಸವಾಗಿದ್ದು ಅದು ನಿರ್ದಿಷ್ಟ ಭೌತಿಕ ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್‌ನೊಂದಿಗೆ ಸಂಬಂಧ ಹೊಂದಿಲ್ಲ. ನೋಡ್ ವಿಫಲವಾದಲ್ಲಿ ಅಥವಾ ನಿಗದಿತ ನಿರ್ವಹಣೆಯ ಸಮಯದಲ್ಲಿ, ನಾವು ವಿಐಪಿಯನ್ನು ಕನಿಷ್ಠ ಅಲಭ್ಯತೆಯೊಂದಿಗೆ ಮತ್ತೊಂದು ಸಂಪನ್ಮೂಲಕ್ಕೆ ಬದಲಾಯಿಸಬಹುದು.
• ವರ್ಚುವಲ್ ಐಪಿ ವಿಳಾಸವನ್ನು ಮುಕ್ತಗೊಳಿಸುವುದು ಮತ್ತು ನೀಡುವುದು ಅಗ್ಗದ ಮತ್ತು ವೇಗದ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದೆ.
• ವಿಐಪಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು, ನಿಮಗೆ SSH ಮೂಲಕ ಸರ್ವರ್‌ಗೆ ಪ್ರವೇಶ ಬೇಕಾಗುತ್ತದೆ, ಅಥವಾ ವಿಶೇಷ ಉಪಯುಕ್ತತೆಗಳ ಬಳಕೆ, ಉದಾಹರಣೆಗೆ, keepalived.

ನಮ್ಮ ಮಾಂತ್ರಿಕನೊಂದಿಗಿನ ಸಂಭವನೀಯ ಸಮಸ್ಯೆಗಳನ್ನು ನೋಡೋಣ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಚೇತರಿಕೆ ಕಾರ್ಯವಿಧಾನವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು ಎಂಬುದನ್ನು ಊಹಿಸಿ.

ಮಾಸ್ಟರ್‌ಗೆ ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕವು ಕಣ್ಮರೆಯಾಗಿದೆ ಅಥವಾ ಹಾರ್ಡ್‌ವೇರ್ ಮಟ್ಟದಲ್ಲಿ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸಿದೆ ಮತ್ತು ಸರ್ವರ್ ಲಭ್ಯವಿಲ್ಲ

1. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಕ್ಲಸ್ಟರ್ ಟೋಪೋಲಜಿಯನ್ನು ನವೀಕರಿಸುತ್ತಾನೆ, ಪ್ರತಿ ಪ್ರತಿಕೃತಿಯು ಮಾಸ್ಟರ್ ಲಭ್ಯವಿಲ್ಲ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಹೊಸ ಮಾಸ್ಟರ್ ಪಾತ್ರಕ್ಕೆ ಸೂಕ್ತವಾದ ಪ್ರತಿಕೃತಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ ಮತ್ತು ಚೇತರಿಕೆ ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ.
2. ನಾವು ಹಳೆಯ ಮಾಸ್ಟರ್‌ನಿಂದ ವಿಐಪಿಯನ್ನು ತೆಗೆದುಹಾಕಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ - ಯಶಸ್ವಿಯಾಗಲಿಲ್ಲ.
3. ಪ್ರತಿಕೃತಿಯು ಮಾಸ್ಟರ್ ಪಾತ್ರಕ್ಕೆ ಬದಲಾಗುತ್ತದೆ. ಟೋಪೋಲಜಿಯನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಲಾಗುತ್ತಿದೆ.
4. ವಿಐಪಿ ಜೊತೆಗೆ ಹೊಸ ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್ ಸೇರಿಸಲಾಗುತ್ತಿದೆ. VIP ಅನ್ನು ತೆಗೆದುಹಾಕಲು ಸಾಧ್ಯವಾಗದ ಕಾರಣ, ನಾವು ನಿಯತಕಾಲಿಕವಾಗಿ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ ಅನಪೇಕ್ಷಿತ ARP. ಈ ರೀತಿಯ ವಿನಂತಿ/ಪ್ರತಿಕ್ರಿಯೆಯು ಸಂಪರ್ಕಿತ ಸ್ವಿಚ್‌ಗಳಲ್ಲಿ IP ಮತ್ತು MAC ವಿಳಾಸ ಮ್ಯಾಪಿಂಗ್ ಟೇಬಲ್ ಅನ್ನು ನವೀಕರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಆ ಮೂಲಕ ನಮ್ಮ VIP ಸ್ಥಳಾಂತರಗೊಂಡಿದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿಸುತ್ತದೆ. ಇದು ಸಂಭವನೀಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ split brain ಹಳೆಯ ಯಜಮಾನನನ್ನು ಹಿಂದಿರುಗಿಸುವಾಗ.
5. ಎಲ್ಲಾ ಹೊಸ ಸಂಪರ್ಕಗಳನ್ನು ತಕ್ಷಣವೇ ಹೊಸ ಮಾಸ್ಟರ್‌ಗೆ ಮರುನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ. ಹಳೆಯ ಸಂಪರ್ಕಗಳು ವಿಫಲಗೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗೆ ಪುನರಾವರ್ತಿತ ಕರೆಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ.

ಸರ್ವರ್ ಸಾಮಾನ್ಯ ಕ್ರಮದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, DBMS ಮಟ್ಟದಲ್ಲಿ ವೈಫಲ್ಯ ಸಂಭವಿಸಿದೆ

ಅಲ್ಗಾರಿದಮ್ ಹಿಂದಿನ ಪ್ರಕರಣಕ್ಕೆ ಹೋಲುತ್ತದೆ: ಟೋಪೋಲಜಿಯನ್ನು ನವೀಕರಿಸುವುದು ಮತ್ತು ಚೇತರಿಕೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು. ಸರ್ವರ್ ಲಭ್ಯವಿರುವುದರಿಂದ, ನಾವು ಹಳೆಯ ಮಾಸ್ಟರ್‌ನಲ್ಲಿ VIP ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಬಿಡುಗಡೆ ಮಾಡುತ್ತೇವೆ, ಅದನ್ನು ಹೊಸದಕ್ಕೆ ವರ್ಗಾಯಿಸುತ್ತೇವೆ ಮತ್ತು ಹಲವಾರು ARP ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತೇವೆ. ಹಳೆಯ ಮಾಸ್ಟರ್ನ ಸಂಭವನೀಯ ವಾಪಸಾತಿಯು ಮರುನಿರ್ಮಿಸಲಾದ ಕ್ಲಸ್ಟರ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ನ ಕಾರ್ಯಾಚರಣೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಾರದು.

ಇತರ ಸಮಸ್ಯೆಗಳು

ಪ್ರತಿಕೃತಿಗಳು ಅಥವಾ ಮಧ್ಯಂತರ ಮಾಸ್ಟರ್‌ಗಳ ವೈಫಲ್ಯ ದಾರಿ ಮಾಡುವುದಿಲ್ಲ ಸ್ವಯಂಚಾಲಿತ ಕ್ರಿಯೆಗಳಿಗೆ ಮತ್ತು ಹಸ್ತಚಾಲಿತ ಹಸ್ತಕ್ಷೇಪದ ಅಗತ್ಯವಿದೆ.

ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಯಾವಾಗಲೂ ತಾತ್ಕಾಲಿಕವಾಗಿ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಅಂದರೆ, ಸರ್ವರ್ ರೀಬೂಟ್ ಮಾಡಿದ ನಂತರ, VIP ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿಯೋಜಿಸಲಾಗುವುದಿಲ್ಲ. ಪ್ರತಿ ಡೇಟಾಬೇಸ್ ನಿದರ್ಶನವು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಓದಲು-ಮಾತ್ರ ಮೋಡ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊಸ ಮಾಸ್ಟರ್ ಅನ್ನು ಬರೆಯಲು ಬದಲಾಯಿಸುತ್ತದೆ ಮತ್ತು ಸ್ಥಾಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ read only ಹಳೆಯ ಮಾಸ್ಟರ್ ಮೇಲೆ. ಈ ಕ್ರಮಗಳು ಸಂಭವನೀಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಗುರಿಯನ್ನು ಹೊಂದಿವೆ split brain.

ಮರುಪ್ರಾಪ್ತಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಸಮಸ್ಯೆಗಳು ಉಂಟಾಗಬಹುದು, ಇದನ್ನು ಪ್ರಮಾಣಿತ ಮಾನಿಟರಿಂಗ್ ಪರಿಕರಗಳ ಜೊತೆಗೆ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ UI ಮೂಲಕವೂ ತಿಳಿಸಬೇಕು. ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ನಾವು REST API ಅನ್ನು ವಿಸ್ತರಿಸಿದ್ದೇವೆ (PR ಪ್ರಸ್ತುತ ಪರಿಶೀಲನೆಯಲ್ಲಿದೆ).

HA ಪರಿಹಾರದ ಸಾಮಾನ್ಯ ರೇಖಾಚಿತ್ರವನ್ನು ಕೆಳಗೆ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ.

ಹೊಸ ಮಾಸ್ಟರ್ ಆಯ್ಕೆ

ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಸಾಕಷ್ಟು ಸ್ಮಾರ್ಟ್ ಮತ್ತು ಆಯ್ಕೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಾನೆ ಅತ್ಯಂತ ಸೂಕ್ತವಾದ ಪ್ರತಿಕೃತಿ ಕೆಳಗಿನ ಮಾನದಂಡಗಳ ಪ್ರಕಾರ ಹೊಸ ಮಾಸ್ಟರ್ ಆಗಿ:

• ಪ್ರತಿಕೃತಿಯು ಮಾಸ್ಟರ್ಗಿಂತ ಹಿಂದುಳಿದಿದೆ;
• ಮಾಸ್ಟರ್ ಮತ್ತು ಪ್ರತಿಕೃತಿಯ MySQL ಆವೃತ್ತಿ;
• ಪ್ರತಿಕೃತಿ ಪ್ರಕಾರ (RBR, SBR ಅಥವಾ ಮಿಶ್ರ);
• ಒಂದೇ ಅಥವಾ ವಿಭಿನ್ನ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಸ್ಥಳ;
• ಲಭ್ಯತೆ errant GTID - ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಮತ್ತು ಮಾಸ್ಟರ್‌ನಲ್ಲಿಲ್ಲದ ವಹಿವಾಟುಗಳು;
• ಕಸ್ಟಮ್ ಆಯ್ಕೆ ನಿಯಮಗಳನ್ನು ಸಹ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ.

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

ಪ್ರತಿಕ್ರಿಯೆ ಮತ್ತು ಚೇತರಿಕೆಯ ಸಮಯ

ಘಟನೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಸಿಸ್ಟಮ್ ಡೌನ್‌ಟೈಮ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಮುಖ್ಯ, ಆದ್ದರಿಂದ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ನಿಂದ ಕ್ಲಸ್ಟರ್ ಟೋಪೋಲಜಿಯ ರಚನೆ ಮತ್ತು ನವೀಕರಣದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ MySQL ನಿಯತಾಂಕಗಳನ್ನು ಪರಿಗಣಿಸೋಣ:

• slave_net_timeout - ಸಂಪರ್ಕವು ಕಳೆದುಹೋಗಿದೆ ಮತ್ತು ಮರುಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ಗುರುತಿಸುವ ಮೊದಲು ಮಾಸ್ಟರ್‌ನಿಂದ ಬರುವ ಹೊಸ ಡೇಟಾ ಅಥವಾ ಹೃದಯ ಬಡಿತದ ಸಂಕೇತಕ್ಕಾಗಿ ಪ್ರತಿಕೃತಿಯು ಕಾಯುವ ಸೆಕೆಂಡುಗಳ ಸಂಖ್ಯೆ. ಕಡಿಮೆ ಮೌಲ್ಯ, ಮಾಸ್ಟರ್‌ನೊಂದಿಗಿನ ಸಂವಹನವು ಮುರಿದುಹೋಗಿದೆ ಎಂದು ಪ್ರತಿಕೃತಿ ವೇಗವಾಗಿ ನಿರ್ಧರಿಸುತ್ತದೆ. ನಾವು ಈ ಮೌಲ್ಯವನ್ನು 5 ಸೆಕೆಂಡುಗಳಿಗೆ ಹೊಂದಿಸಿದ್ದೇವೆ.
• MASTER_CONNECT_RETRY - ಮರುಸಂಪರ್ಕ ಪ್ರಯತ್ನಗಳ ನಡುವಿನ ಸೆಕೆಂಡುಗಳ ಸಂಖ್ಯೆ. ನೆಟ್‌ವರ್ಕ್ ಸಮಸ್ಯೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಈ ಪ್ಯಾರಾಮೀಟರ್‌ಗೆ ಕಡಿಮೆ ಮೌಲ್ಯವು ತ್ವರಿತ ಮರುಸಂಪರ್ಕವನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್ ಮರುಪಡೆಯುವಿಕೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಶಿಫಾರಸು ಮಾಡಲಾದ ಮೌಲ್ಯವು 1 ಸೆಕೆಂಡ್ ಆಗಿದೆ.
• MASTER_RETRY_COUNT - ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಮರುಸಂಪರ್ಕ ಪ್ರಯತ್ನಗಳು.
• MASTER_HEARTBEAT_PERIOD - ಮಾಸ್ಟರ್ ಹೃದಯ ಬಡಿತದ ಸಂಕೇತವನ್ನು ಕಳುಹಿಸುವ ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಮಧ್ಯಂತರ. ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯದ ಅರ್ಧದಷ್ಟು slave_net_timeout.

ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಆಯ್ಕೆಗಳು:

• DelayMasterPromotionIfSQLThreadNotUpToDate - ಸಮಾನವಾಗಿದ್ದರೆ true, ನಂತರ ಪ್ರತಿಕೃತಿಯ SQL ಥ್ರೆಡ್ ರಿಲೇ ಲಾಗ್‌ನಿಂದ ಅನ್ವಯಿಸದ ಎಲ್ಲಾ ವಹಿವಾಟುಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸುವವರೆಗೆ ಅಭ್ಯರ್ಥಿಯ ಪ್ರತಿಕೃತಿಯ ಮೇಲೆ ಮಾಸ್ಟರ್ ಪಾತ್ರವನ್ನು ಅನ್ವಯಿಸಲಾಗುವುದಿಲ್ಲ. ಎಲ್ಲಾ ಅಭ್ಯರ್ಥಿ ಪ್ರತಿಕೃತಿಗಳು ಹಿಂದೆ ಬಿದ್ದಾಗ ವಹಿವಾಟುಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದನ್ನು ತಪ್ಪಿಸಲು ನಾವು ಈ ಆಯ್ಕೆಯನ್ನು ಬಳಸುತ್ತೇವೆ.
• InstancePollSeconds - ಟೋಪೋಲಜಿಯನ್ನು ನಿರ್ಮಿಸುವ ಮತ್ತು ನವೀಕರಿಸುವ ಆವರ್ತನ.
• RecoveryPollSeconds - ಟೋಪೋಲಜಿ ವಿಶ್ಲೇಷಣೆಯ ಆವರ್ತನ. ಸಮಸ್ಯೆ ಪತ್ತೆಯಾದರೆ, ಟೋಪೋಲಜಿ ಚೇತರಿಕೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಈ ನಿರಂತರ, 1 ಸೆಕೆಂಡಿಗೆ ಸಮಾನವಾಗಿರುತ್ತದೆ.

ಪ್ರತಿ ಕ್ಲಸ್ಟರ್ ನೋಡ್ ಅನ್ನು ಪ್ರತಿ ಬಾರಿ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ನಿಂದ ಪೋಲ್ ಮಾಡಲಾಗುತ್ತದೆ InstancePollSeconds ಸೆಕೆಂಡುಗಳು ಸಮಸ್ಯೆ ಪತ್ತೆಯಾದಾಗ, ಕ್ಲಸ್ಟರ್ ಸ್ಥಿತಿಯನ್ನು ಬಲವಂತಪಡಿಸಲಾಗುತ್ತದೆ ನವೀಕರಿಸಲಾಗಿದೆ, ಮತ್ತು ನಂತರ ಚೇತರಿಕೆ ನಿರ್ವಹಿಸಲು ಅಂತಿಮ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ. ವಿಭಿನ್ನ ಡೇಟಾಬೇಸ್ ಮತ್ತು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳೊಂದಿಗೆ ಪ್ರಯೋಗ ಮಾಡುವ ಮೂಲಕ, ನಾವು ಪ್ರತಿಕ್ರಿಯೆ ಮತ್ತು ಚೇತರಿಕೆಯ ಸಮಯವನ್ನು 30 ಸೆಕೆಂಡುಗಳಿಗೆ ಕಡಿಮೆ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು.

ಪರೀಕ್ಷಾ ನಿಲುವು

ನಾವು ಸ್ಥಳೀಯರ ಅಭಿವೃದ್ಧಿಯೊಂದಿಗೆ HA ಯೋಜನೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಪರೀಕ್ಷಾ ಬೆಂಚ್ ಮತ್ತು ಪರೀಕ್ಷೆ ಮತ್ತು ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಮತ್ತಷ್ಟು ಅನುಷ್ಠಾನ. ಸ್ಥಳೀಯ ಸ್ಟ್ಯಾಂಡ್ ಡಾಕರ್ ಅನ್ನು ಆಧರಿಸಿ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿದೆ ಮತ್ತು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್‌ನ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಪ್ರಯೋಗಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಕ್ಲಸ್ಟರ್ ಅನ್ನು 2-3 ಸರ್ವರ್‌ಗಳಿಂದ ಹಲವಾರು ಡಜನ್‌ಗಳಿಗೆ ಅಳೆಯಲು ಮತ್ತು ಸುರಕ್ಷಿತ ವಾತಾವರಣದಲ್ಲಿ ವ್ಯಾಯಾಮಗಳನ್ನು ನಡೆಸುತ್ತದೆ.

ವ್ಯಾಯಾಮದ ಸಮಯದಲ್ಲಿ, ನಾವು ಸಮಸ್ಯೆಯ ಎಮ್ಯುಲೇಶನ್ ವಿಧಾನಗಳಲ್ಲಿ ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ: ಬಳಸಿ ಮಾಸ್ಟರ್ ಅನ್ನು ತಕ್ಷಣವೇ ಶೂಟ್ ಮಾಡಿ kill -9, ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮೃದುವಾಗಿ ಕೊನೆಗೊಳಿಸಿ ಮತ್ತು ಸರ್ವರ್ ಅನ್ನು ನಿಲ್ಲಿಸಿ (docker-compose stop), ಬಳಸಿಕೊಂಡು ನೆಟ್‌ವರ್ಕ್ ಸಮಸ್ಯೆಗಳನ್ನು ಅನುಕರಿಸಿ iptables -j REJECT ಅಥವಾ iptables -j DROP. ನಾವು ಈ ಕೆಳಗಿನ ಫಲಿತಾಂಶಗಳನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ:

• ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಮಾಸ್ಟರ್‌ನೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಟೋಪೋಲಜಿಯನ್ನು 10 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ನವೀಕರಿಸುವುದಿಲ್ಲ;
• ಚೇತರಿಕೆ ಪ್ರಕ್ರಿಯೆಯು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ: ನೆಟ್‌ವರ್ಕ್ ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾಗುತ್ತದೆ, ಮಾಸ್ಟರ್‌ನ ಪಾತ್ರವು ಪ್ರತಿಕೃತಿಗೆ ಹಾದುಹೋಗುತ್ತದೆ, ಟೋಪೋಲಜಿಯನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಲಾಗುತ್ತದೆ;
• ಹೊಸ ಮಾಸ್ಟರ್ ಬರೆಯಬಲ್ಲರು, ಮರುನಿರ್ಮಾಣ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಲೈವ್ ಪ್ರತಿಕೃತಿಗಳು ಕಳೆದುಹೋಗುವುದಿಲ್ಲ;
• ಡೇಟಾವನ್ನು ಹೊಸ ಮಾಸ್ಟರ್‌ಗೆ ಬರೆಯಲು ಮತ್ತು ಪುನರಾವರ್ತಿಸಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ;
• ಒಟ್ಟು ಚೇತರಿಕೆಯ ಸಮಯವು 30 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚಿಲ್ಲ.

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

ಸಂಶೋಧನೆಗಳು

ಮುಖ್ಯ ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಯ ನೋಡ್‌ನ ಆರೋಗ್ಯವು SRE ಮತ್ತು ಕಾರ್ಯಾಚರಣೆ ತಂಡದ ಮುಖ್ಯ ಕಾರ್ಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. VIP ಆಧಾರಿತ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಮತ್ತು HA ಪರಿಹಾರದ ಅನುಷ್ಠಾನವು ಈ ಕೆಳಗಿನ ಫಲಿತಾಂಶಗಳನ್ನು ಸಾಧಿಸಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು:

• ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರ್‌ನ ಟೋಪೋಲಜಿಯೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳ ವಿಶ್ವಾಸಾರ್ಹ ಪತ್ತೆ;
• ಮಾಸ್ಟರ್-ಸಂಬಂಧಿತ ಘಟನೆಗಳಿಗೆ ಸ್ವಯಂಚಾಲಿತ ಮತ್ತು ತ್ವರಿತ ಪ್ರತಿಕ್ರಿಯೆ, ಸಿಸ್ಟಮ್ ಅಲಭ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಆದಾಗ್ಯೂ, ಪರಿಹಾರವು ಅದರ ಮಿತಿಗಳು ಮತ್ತು ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ:

• HA ಯೋಜನೆಯನ್ನು ಹಲವಾರು ಡೇಟಾ ಕೇಂದ್ರಗಳಿಗೆ ಸ್ಕೇಲಿಂಗ್ ಮಾಡಲು ಅವುಗಳ ನಡುವೆ ಒಂದೇ L2 ನೆಟ್‌ವರ್ಕ್ ಅಗತ್ಯವಿರುತ್ತದೆ;
• ಹೊಸ ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ವಿಐಪಿ ನಿಯೋಜಿಸುವ ಮೊದಲು, ನಾವು ಅದನ್ನು ಹಳೆಯದರಲ್ಲಿ ಬಿಡುಗಡೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಪ್ರಕ್ರಿಯೆಯು ಅನುಕ್ರಮವಾಗಿದೆ, ಇದು ಚೇತರಿಕೆಯ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ;
• VIP ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ಸರ್ವರ್‌ಗೆ SSH ಪ್ರವೇಶದ ಅಗತ್ಯವಿದೆ, ಅಥವಾ ರಿಮೋಟ್ ಕಾರ್ಯವಿಧಾನಗಳಿಗೆ ಕರೆ ಮಾಡುವ ಯಾವುದೇ ಇತರ ವಿಧಾನ. ಮರುಪ್ರಾಪ್ತಿ ಪ್ರಕ್ರಿಯೆಗೆ ಕಾರಣವಾದ ಸಮಸ್ಯೆಗಳನ್ನು ಸರ್ವರ್ ಅಥವಾ ಡೇಟಾಬೇಸ್ ಎದುರಿಸುತ್ತಿರುವುದರಿಂದ, VIP ತೆಗೆದುಹಾಕುವಿಕೆಯು ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ ಎಂದು ನಾವು ಖಚಿತವಾಗಿ ಹೇಳಲಾಗುವುದಿಲ್ಲ. ಮತ್ತು ಇದು ಒಂದೇ ವರ್ಚುವಲ್ ಐಪಿ ವಿಳಾಸ ಮತ್ತು ಸಮಸ್ಯೆಯೊಂದಿಗೆ ಎರಡು ಸರ್ವರ್‌ಗಳ ಗೋಚರಿಸುವಿಕೆಗೆ ಕಾರಣವಾಗಬಹುದು split brain.

ತಪ್ಪಿಸಲು split brain, ನೀವು ವಿಧಾನವನ್ನು ಬಳಸಬಹುದು ಸ್ಟೋನಿತ್ ("ಶೂಟ್ ದಿ ಅದರ್ ನೋಡ್ ಇನ್ ದಿ ಹೆಡ್"), ಇದು ಸಮಸ್ಯೆ ನೋಡ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ ಅಥವಾ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. ಕ್ಲಸ್ಟರ್ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಇತರ ಮಾರ್ಗಗಳಿವೆ: ವಿಐಪಿ ಮತ್ತು ಡಿಎನ್ಎಸ್, ಸೇವೆಯ ಅನ್ವೇಷಣೆ ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಸೇವೆಗಳ ಸಂಯೋಜನೆ, ಸಿಂಕ್ರೊನಸ್ ಪುನರಾವರ್ತನೆ ಮತ್ತು ತಮ್ಮದೇ ಆದ ಅನಾನುಕೂಲಗಳು ಮತ್ತು ಅನುಕೂಲಗಳನ್ನು ಹೊಂದಿರುವ ಇತರ ವಿಧಾನಗಳು.

MySQL ಫೇಲ್ಓವರ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸುವ ನಮ್ಮ ವಿಧಾನದ ಬಗ್ಗೆ ನಾನು ಮಾತನಾಡಿದೆ. ಇದು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸುಲಭ ಮತ್ತು ಪ್ರಸ್ತುತ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಸ್ವೀಕಾರಾರ್ಹ ಮಟ್ಟದ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಒಟ್ಟಾರೆಯಾಗಿ ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ಮೂಲಸೌಕರ್ಯ ಅಭಿವೃದ್ಧಿಯಾದಂತೆ, ಈ ವಿಧಾನವು ನಿಸ್ಸಂದೇಹವಾಗಿ ವಿಕಸನಗೊಳ್ಳುತ್ತದೆ.

ಮೂಲ: www.habr.com