VPN ಕಡಿತದ ನಂತರ MySQL ಪ್ರತಿಕೃತಿ: ಮೊದಲು ಎರಡೂ ಹಂತಗಳನ್ನು ಓದಿ

VPN ಬಿದ್ದಾಗ ಪ್ರತಿಕೃತಿ ಮೇಲ್ವಿಚಾರಣೆ ಕೆಂಪಾಗುತ್ತದೆ, ಮತ್ತು ಮೊದಲ ಪ್ರವೃತ್ತಿ ಸ್ಥಾನವನ್ನು ಮರುಹೊಂದಿಸುವುದು. ಆ ಪ್ರವೃತ್ತಿಯೇ ಜಾಲ ಕಡಿತವನ್ನು ದತ್ತಾಂಶ ಸಮಸ್ಯೆಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಬಿದ್ದ ಮಾರ್ಗವು ಪ್ರತಿಕೃತಿಯು ಏನನ್ನು ಸ್ವೀಕರಿಸಿದೆ ಅಥವಾ ಅನ್ವಯಿಸಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಅವು ಎರಡು ಸ್ಥಿತಿಗಳಿರುವ ಎರಡು ಹಂತಗಳು. ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಅವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಓದಿ.

ಎರಡು ಹಂತಗಳು, ಎರಡು ಪ್ರತ್ಯೇಕ ಉತ್ತರಗಳು

ಸಾಂಪ್ರದಾಯಿಕ ಅಸಿಂಕ್ರೋನಸ್ ಪ್ರತಿಕೃತಿಯು ಎರಡು ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತದೆ. ಸ್ವೀಕರಿಸುವವರು ಮೂಲಕ್ಕೆ ಸಂಪರ್ಕಿಸಿ, ಘಟನೆಗಳನ್ನು ಎಳೆದು ಅವನ್ನು ಸ್ಥಳೀಯವಾಗಿ ರಿಲೇ ದಾಖಲೆಗೆ ಬರೆಯುತ್ತದೆ. ಅನ್ವಯಿಸುವವರು ಆ ದಾಖಲೆಯನ್ನು ಓದಿ ಘಟನೆಗಳನ್ನು ಪ್ರತಿಕೃತಿಯ ಮೇಲೆ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಮಾರ್ಗ ಒಡೆದಾಗ ಸ್ವೀಕರಿಸುವವರು ತಕ್ಷಣ ನಿಲ್ಲುತ್ತದೆ, ಆದರೆ ಅನ್ವಯಿಸುವವರು ಈಗಾಗಲೇ ಡಿಸ್ಕಿನಲ್ಲಿರುವ ಬಾಕಿಯನ್ನು ಪ್ರಕ್ರಿಯೆ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ. ಹಾಗಾಗಿ ಒಂದು ಅಡಚಣೆ ಎರಡು ಬೇರೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಹುಟ್ಟಿಸುತ್ತದೆ: ಸಂಪರ್ಕ ಮರಳಿದೆಯೇ, ಮತ್ತು ಸಂಗ್ರಹವಾದ ಕೆಲಸ ಅನ್ವಯವಾಯಿತೇ? ಅವನ್ನು ಒಂದೇ ಪ್ರಶ್ನೆಯೆಂದು ಪರಿಗಣಿಸಿದರೆ ಎರಡು ಸ್ಥಿತಿಗಳು ಸೇರಿ ದಾರಿತಪ್ಪಿಸುವ ಉತ್ತರವಾಗುತ್ತದೆ.

ಸ್ವೀಕರಿಸುವವರು ಚೇತರಿಸಿಕೊಳ್ಳುವುದು ಮಾರ್ಗ ಚಾಲ್ತಿಯಲ್ಲಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಅನ್ವಯಿಸುವವರು ಎಷ್ಟು ಹಿಂದೆ ಇದೆ, ಅಥವಾ ಸಂಪರ್ಕ ಕಡಿತದ ವೇಳೆ ದೋಷ ಎದುರಾಯಿತೇ ಎಂದು ಅದು ಹೇಳುವುದಿಲ್ಲ.

ಸರಿಯಾದ ಹೇಳಿಕೆಯೊಂದಿಗೆ ಚಾನೆಲ್ ಓದಿ

MySQL 8.4 ನಲ್ಲಿ, SHOW REPLICA STATUS ಪ್ರತಿ ಸಂರಚಿತ ಚಾನೆಲ್ಗೆ ಒಂದು ಸಾಲನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪಟ್ಟಿಯಲ್ಲಿನ ಮೊದಲ ಸಾಲಿನ ಬದಲು ನೀವು ಉದ್ದೇಶಿಸಿದ ಚಾನೆಲ್ನ ಸಾಲನ್ನು ಓದಿ. Replica_IO_Running ಸಂಪರ್ಕಗೊಂಡ ಸ್ವೀಕರಿಸುವವರನ್ನು ಸಂಪರ್ಕಿಸುತ್ತಿರುವ ಅಥವಾ ನಿಂತಿರುವ ಸ್ವೀಕರಿಸುವವರಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಮತ್ತು Replica_SQL_Running ಅನ್ವಯಿಸುವವರನ್ನು ವಿವರಿಸುತ್ತದೆ. ಅವುಗಳ ಪಕ್ಕದ ದೋಷ ಸ್ತಂಭಗಳನ್ನೂ ಓದಿ, ಏಕೆಂದರೆ ಮತ್ತೆ ಸಂಪರ್ಕಗೊಂಡು ತಕ್ಷಣ ವಿಫಲವಾಗುವ ಸ್ವೀಕರಿಸುವವರು ಯಾವುದೇ ಸ್ಥಿತಿ ಧ್ವಜ ತೋರಿಸದ ಸಂದೇಶವನ್ನು ಬಿಡುತ್ತದೆ. ಹಳೆಯ ಆವೃತ್ತಿಗಳು ಬೇರೆ ಸ್ತಂಭ ಹೆಸರುಗಳನ್ನು ಬಳಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಕೇವಲ ಆಜ್ಞೆಗಳ ಹೆಸರು ಬದಲಿಸಿ ಹಳೆಯ ವಿಧಾನವನ್ನು ಅನುವಾದಿಸಬೇಡಿ.

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

ಶೂನ್ಯ ವಿಳಂಬದ ಸಂಖ್ಯೆ ಸುಳ್ಳು ಹೇಳಬಹುದೇಕೆ

ವಿಳಂಬದ ಮೌಲ್ಯವು ಕೊನೆಯದಾಗಿ ಅನ್ವಯಿಸಿದ ಘಟನೆಯ ಸಮಯಮುದ್ರೆಯನ್ನು ಪ್ರಸ್ತುತ ಸಮಯದೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ. ಸ್ವೀಕರಿಸುವವರು ಒಂದು ಗಂಟೆ ನಿಂತಿದ್ದರೆ, ಅನ್ವಯಿಸುವವರು ಬಾಕಿಯನ್ನು ಮುಗಿಸಿ ಸ್ವೀಕರಿಸಿದ್ದರ ಕೊನೆ ತಲುಪಬಹುದು, ಆಗ ಪ್ರತಿಕೃತಿ ಮೂಲಕ್ಕಿಂತ ಒಂದು ಗಂಟೆ ಹಿಂದಿದ್ದರೂ ಸಂಖ್ಯೆ ಶೂನ್ಯಕ್ಕೆ ಇಳಿಯುತ್ತದೆ. ಈ ಅಳತೆ ಅನ್ವಯಿಸುವವರ ಸರದಿಯನ್ನು ಅಳೆಯುತ್ತದೆ, ಪ್ರತಿಕೃತಿಯ ನವೀನತೆಯನ್ನಲ್ಲ.

ಬದಲಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದ ವಹಿವಾಟುಗಳನ್ನು ಮೂಲದಲ್ಲಿ ಲಭ್ಯವಿರುವುದಕ್ಕೆ ಹೋಲಿಸಿ. ಆ ಹೋಲಿಕೆ ನಿಂತಿರುವ ಸ್ವೀಕರಿಸುವವರನ್ನೂ ತಾಳಿಕೊಳ್ಳುತ್ತದೆ.

ನಿಜವಾದ ಚೇತರಿಕೆ ಕಿಟಕಿಯನ್ನು ಧಾರಣ ನಿರ್ಧರಿಸುತ್ತದೆ

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

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

ಸೂಚಕದ ಬಣ್ಣವಲ್ಲ, ಹಿಂದೆ ಹೋದದ್ದನ್ನು ಪರಿಶೀಲಿಸಿ

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

ಅನ್ವಯಿಸುವವರು ಮೂಲದ ಪ್ರಸ್ತುತ ಸ್ಥಾನವನ್ನು ತಲುಪಿದೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ಹಳೆಯ ಬಾಕಿಯ ಕೊನೆಯನ್ನು ಮಾತ್ರವಲ್ಲ. ಅನ್ವಯಿಸುವವರಲ್ಲಿ ಯಾವುದೇ ದೋಷ ಕಾಯುತ್ತಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಒಂದು ವಿಫಲ ಘಟನೆ ಪ್ರಗತಿಯನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಆದರೆ ಸ್ವೀಕರಿಸುವವರು ಸಂಪರ್ಕವಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ. ನಂತರ ಸಾಕ್ಷ್ಯವನ್ನು ದಾಖಲಿಸಿ: ಚಾನೆಲ್ ಹೆಸರು, ಎರಡೂ ಹಂತಗಳ ಸ್ಥಿತಿ, ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಸ್ಥಾನ ಮತ್ತು ಸಮಯ. ಹಸಿರು ಸೂಚಕ ಒಂದು ವಾದ; ಸ್ಥಾನ ಒಂದು ಸತ್ಯ.