ಲೇಖನದ ಅನುವಾದವನ್ನು ಕೋರ್ಸ್‌ನ ವಿದ್ಯಾರ್ಥಿಗಳಿಗೆ ವಿಶೇಷವಾಗಿ ಸಿದ್ಧಪಡಿಸಲಾಗಿದೆ "ಡೇಟಾಬೇಸ್". ಈ ದಿಕ್ಕಿನಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಆಸಕ್ತಿ ಇದೆಯೇ? ನಾವು ನಿಮ್ಮನ್ನು ಆಹ್ವಾನಿಸುತ್ತೇವೆ ತೆರೆದ ದಿನ, ಅಲ್ಲಿ ನಾವು ಕಾರ್ಯಕ್ರಮದ ಬಗ್ಗೆ ವಿವರವಾಗಿ ಮಾತನಾಡುತ್ತೇವೆ, ಆನ್‌ಲೈನ್ ಸ್ವರೂಪದ ವೈಶಿಷ್ಟ್ಯಗಳು, ತರಬೇತಿಯ ನಂತರ ಪದವೀಧರರಿಗೆ ಕಾಯುತ್ತಿರುವ ಸಾಮರ್ಥ್ಯಗಳು ಮತ್ತು ವೃತ್ತಿ ಭವಿಷ್ಯ.

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

ನನಗೆ ಅದು ಏಕೆ ಬೇಕು?

ಕ್ಲಸ್ಟರ್ ಹೇಗೆ ವರ್ತಿಸಬೇಕು ಎಂಬುದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಬಿಲ್ ಪಾವತಿ ಅಪ್ಲಿಕೇಶನ್ ತೆಗೆದುಕೊಳ್ಳಿ. ಕ್ಲಸ್ಟರ್‌ನಾದ್ಯಂತ ನಿಮಗೆ XNUMX% ಸ್ಥಿರತೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಸಿಂಕ್ರೊನಸ್ ಕಮಿಟ್‌ಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ ಇದರಿಂದ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಕಾಯುತ್ತದೆ. ಆದಾಗ್ಯೂ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ವೇಗವಾಗಿ ಬೆಳೆಯುತ್ತಿರುವ ಸಾಮಾಜಿಕ ನೆಟ್‌ವರ್ಕ್ ಆಗಿದ್ದರೆ, ನೀವು ಬಹುಶಃ XNUMX% ಸ್ಥಿರತೆಗಿಂತ ವೇಗದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಬಯಸುತ್ತೀರಿ. ಇದನ್ನು ಸಾಧಿಸಲು, ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನೀವು ಅಸಮಕಾಲಿಕ ಕಮಿಟ್‌ಗಳನ್ನು ಬಳಸಬಹುದು.

ರಾಜಿ ಭೇಟಿ ಮಾಡಿ

ಡೇಟಾ ಸ್ಥಿರತೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ನಡುವೆ ನೀವು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬೇಕು. PostgreSQL ಸ್ಥಿರತೆಯಿಂದ ದೂರ ಹೋಗುತ್ತದೆ ಏಕೆಂದರೆ ಡೀಫಾಲ್ಟ್ ಕಾನ್ಫಿಗರೇಶನ್ ನಂತರ ಊಹಿಸಬಹುದಾದ ಮತ್ತು ಅನಿರೀಕ್ಷಿತ ಆಶ್ಚರ್ಯಗಳಿಲ್ಲದೆ. ಈಗ ರಾಜಿಗಳನ್ನು ನೋಡೋಣ.

ವ್ಯಾಪಾರ 1: ಕಾರ್ಯಕ್ಷಮತೆ

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

ವ್ಯಾಪಾರ 2: ಸ್ಥಿರತೆ

ಈ ಎರಡು ವಿಧಾನಗಳಲ್ಲಿ ನಾಯಕನ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಫಲಿತಾಂಶವು ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಕೆಲಸವನ್ನು ಅಸಮಕಾಲಿಕವಾಗಿ ನಿರ್ವಹಿಸಿದರೆ, ಅಂತಹ ದೋಷ ಸಂಭವಿಸಿದಲ್ಲಿ, ಎಲ್ಲಾ ದಾಖಲೆಗಳು ಪ್ರತಿಕೃತಿಗಳಿಂದ ಬದ್ಧವಾಗುವುದಿಲ್ಲ. ಎಷ್ಟು ನಷ್ಟವಾಗುತ್ತದೆ? ಅಪ್ಲಿಕೇಶನ್ ಸ್ವತಃ ಮತ್ತು ಪುನರಾವರ್ತನೆಯ ದಕ್ಷತೆಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಕಂಪೋಸ್ ರೆಪ್ಲಿಕೇಶನ್ ಅದರಲ್ಲಿರುವ ಮಾಹಿತಿಯ ಪ್ರಮಾಣವು ಲೀಡರ್‌ಗಿಂತ 1 MB ಕಡಿಮೆಯಿದ್ದರೆ ಪ್ರತಿಕೃತಿಯನ್ನು ನಾಯಕನಾಗುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಅಂದರೆ, ಅಸಮಕಾಲಿಕ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ 1 MB ವರೆಗಿನ ದಾಖಲೆಗಳು ಸಂಭಾವ್ಯವಾಗಿ ಕಳೆದುಹೋಗಬಹುದು.

ಸಿಂಕ್ರೊನಸ್ ಮೋಡ್‌ನಲ್ಲಿ ಇದು ಸಂಭವಿಸುವುದಿಲ್ಲ. ನಾಯಕ ವಿಫಲವಾದರೆ, ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ನಾಯಕನ ಮೇಲೆ ದೃಢೀಕರಿಸಿದ ಯಾವುದೇ ಬರಹವನ್ನು ಪ್ರತಿಕೃತಿಗಳಲ್ಲಿ ದೃಢೀಕರಿಸಬೇಕು. ಇದು ಸ್ಥಿರತೆ.

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

ಟ್ರೇಡ್-ಆಫ್ 3: ಕ್ರ್ಯಾಶ್‌ಗಳು

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

ಪ್ರತಿ ವಹಿವಾಟಿಗೆ ಒಂದು ಸಂಪರ್ಕವೇ?

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

ಈ ಎಲ್ಲಾ ನಿರ್ಧಾರಗಳನ್ನು ಸಹಜವಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ. ಪ್ರತಿ ವಿಧಾನವನ್ನು ಯಾವಾಗ ಬಳಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ಸರಿಯಾದ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಹೆಚ್ಚಿನದನ್ನು ಪಡೆಯಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಸಂಪರ್ಕಗಳಿಗಾಗಿ ಮತ್ತು ವಹಿವಾಟುಗಳಿಗಾಗಿ ಡೆವಲಪರ್ SQL ಮಟ್ಟದಲ್ಲಿ ಅವುಗಳ ನಡುವೆ ಬದಲಾಯಿಸಬಹುದು ಎಂಬುದು ಮುಖ್ಯ.

ಆಚರಣೆಯಲ್ಲಿ ನಿಯಂತ್ರಣವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು

ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, PostgreSQL ಸ್ಥಿರತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದನ್ನು ಸರ್ವರ್ ಪ್ಯಾರಾಮೀಟರ್ ಮೂಲಕ ನಿಯಂತ್ರಿಸಲಾಗುತ್ತದೆ synchronous_commit. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅದು ಸ್ಥಾನದಲ್ಲಿದೆ on, ಆದರೆ ಇದು ಮೂರು ಇತರ ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿದೆ: local, remote_write ಅಥವಾ off.

ನಿಯತಾಂಕವನ್ನು ಹೊಂದಿಸುವಾಗ off ಸ್ಥಳೀಯ ವ್ಯವಸ್ಥೆಯಲ್ಲಿಯೂ ಸಹ ಎಲ್ಲಾ ಸಿಂಕ್ರೊನಸ್ ಕಮಿಟ್‌ಗಳನ್ನು ನಿಲ್ಲಿಸಲಾಗುತ್ತದೆ. ಸ್ಥಳೀಯ ಪ್ಯಾರಾಮೀಟರ್ ಸ್ಥಳೀಯ ವ್ಯವಸ್ಥೆಗೆ ಸಿಂಕ್ರೊನಸ್ ಮೋಡ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ, ಆದರೆ ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಬರೆಯುವುದು ಅಸಮಕಾಲಿಕವಾಗಿ ನಿರ್ವಹಿಸಲ್ಪಡುತ್ತದೆ. Remote_write ಇನ್ನೂ ಮುಂದಕ್ಕೆ ಹೋಗುತ್ತದೆ: ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಬರೆಯುವುದನ್ನು ಅಸಮಕಾಲಿಕವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ, ಆದರೆ ಪ್ರತಿಕೃತಿಯು ಬರವಣಿಗೆಯನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಅದನ್ನು ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯದಿದ್ದಾಗ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ.

ಲಭ್ಯವಿರುವ ಆಯ್ಕೆಗಳ ಶ್ರೇಣಿಯನ್ನು ಪರಿಗಣಿಸಿ, ನಾವು ನಡವಳಿಕೆಯನ್ನು ಆರಿಸಿಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳುತ್ತೇವೆ on - ಇವು ಸಿಂಕ್ರೊನಸ್ ರೆಕಾರ್ಡಿಂಗ್‌ಗಳು, ನಾವು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ local ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಅಸಮಕಾಲಿಕ ಕಮಿಟ್‌ಗಳಿಗಾಗಿ, ಸ್ಥಳೀಯ ಕಮಿಟ್‌ಗಳನ್ನು ಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಬಿಡುತ್ತದೆ.

ಈಗ, ಒಂದು ಕ್ಷಣದಲ್ಲಿ ಇದನ್ನು ಹೇಗೆ ಹೊಂದಿಸುವುದು ಎಂದು ನಾವು ನಿಮಗೆ ಹೇಳುತ್ತೇವೆ, ಆದರೆ ನಾವು ಹೊಂದಿಸಿದ್ದೇವೆ ಎಂದು ಊಹಿಸಿ synchronous_commit в local ಸರ್ವರ್‌ಗಾಗಿ. ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವೇ ಎಂದು ನಾವು ಯೋಚಿಸಿದ್ದೇವೆ synchronous_commit ಹಾರಾಡುತ್ತ, ಮತ್ತು ಇದು ಕೇವಲ ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಬದಲಾಯಿತು, ಇದನ್ನು ಮಾಡಲು ಎರಡು ಮಾರ್ಗಗಳಿವೆ. ನಿಮ್ಮ ಸಂಪರ್ಕದ ಸೆಶನ್ ಅನ್ನು ಈ ಕೆಳಗಿನಂತೆ ಹೊಂದಿಸುವುದು ಮೊದಲನೆಯದು:

SET SESSION synchronous_commit TO ON;  
// Your writes go here

ಅಧಿವೇಶನದಲ್ಲಿ ಎಲ್ಲಾ ನಂತರದ ಬರಹಗಳು ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್‌ಗೆ ಧನಾತ್ಮಕ ಫಲಿತಾಂಶವನ್ನು ಹಿಂದಿರುಗಿಸುವ ಮೊದಲು ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಬರಹಗಳನ್ನು ಅಂಗೀಕರಿಸುತ್ತವೆ. ನೀವು ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಬದಲಾಯಿಸದ ಹೊರತು synchronous_commit ಮತ್ತೆ. ನೀವು ಭಾಗವನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದು SESSION ಆಜ್ಞೆಯಲ್ಲಿ ಏಕೆಂದರೆ ಅದು ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯದಲ್ಲಿರುತ್ತದೆ.

ಒಂದೇ ವಹಿವಾಟಿಗೆ ನೀವು ಸಿಂಕ್ರೊನಸ್ ಪುನರಾವರ್ತನೆಯನ್ನು ಪಡೆಯುತ್ತೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನೀವು ಬಯಸಿದಾಗ ಎರಡನೆಯ ವಿಧಾನವು ಒಳ್ಳೆಯದು. ಅನೇಕ NoSQL ಪೀಳಿಗೆಯ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ವಹಿವಾಟುಗಳ ಪರಿಕಲ್ಪನೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ, ಆದರೆ ಇದು PostgreSQL ನಲ್ಲಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ನೀವು ವ್ಯವಹಾರವನ್ನು ಪ್ರಾರಂಭಿಸಿ ನಂತರ ಹೊಂದಿಸಿ synchronous_commit в on ವಹಿವಾಟಿನ ಪ್ರವೇಶವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು. COMMIT ಯಾವುದೇ ಪ್ಯಾರಾಮೀಟರ್ ಮೌಲ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು ವಹಿವಾಟು ನಡೆಸುತ್ತದೆ synchronous_commit, ಆ ಸಮಯದಲ್ಲಿ ಇದನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ, ಆದರೂ ಇತರ ಡೆವಲಪರ್‌ಗಳು ಬರಹಗಳು ಅಸಮಕಾಲಿಕವಾಗಿಲ್ಲ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ವೇರಿಯಬಲ್ ಅನ್ನು ಮುಂಗಡವಾಗಿ ಹೊಂದಿಸುವುದು ಉತ್ತಮವಾಗಿದೆ.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್‌ಗೆ ಡೇಟಾಬೇಸ್ ಸಕಾರಾತ್ಮಕ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂದಿರುಗಿಸುವ ಮೊದಲು ಎಲ್ಲಾ ವಹಿವಾಟು ಬದ್ಧತೆಗಳನ್ನು ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಬರೆಯಲಾಗಿದೆ ಎಂದು ದೃಢೀಕರಿಸಲಾಗುತ್ತದೆ.

PostgreSQL ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗುತ್ತಿದೆ

ಇದಕ್ಕೂ ಮೊದಲು, ನಾವು PostgreSQL ವ್ಯವಸ್ಥೆಯನ್ನು ಕಲ್ಪಿಸಿಕೊಂಡಿದ್ದೇವೆ synchronous_commit, ಸ್ಥಾಪಿಸಲಾಗಿದೆ local. ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಇದನ್ನು ವಾಸ್ತವಿಕವಾಗಿ ಮಾಡಲು, ನೀವು ಎರಡು ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿಸಬೇಕಾಗುತ್ತದೆ. ಇನ್ನೂ ಒಂದು ಪ್ಯಾರಾಮೀಟರ್ synchronous_standby_names ಯಾವಾಗ ತನ್ನಷ್ಟಕ್ಕೆ ಬರುತ್ತದೆ synchronous_commit ಒಳಗೆ ಇರುತ್ತದೆ on. ಸಿಂಕ್ರೊನಸ್ ಕಮಿಟ್‌ಗಳಿಗೆ ಯಾವ ಪ್ರತಿಕೃತಿಗಳು ಅರ್ಹವಾಗಿವೆ ಎಂಬುದನ್ನು ಇದು ನಿರ್ಧರಿಸುತ್ತದೆ ಮತ್ತು ನಾವು ಅದನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ *, ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳು ಒಳಗೊಂಡಿವೆ ಎಂದು ಅರ್ಥ. ಈ ಮೌಲ್ಯಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗುತ್ತದೆ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಸೇರಿಸುವ ಮೂಲಕ:

synchronous_commit = local  
synchronous_standby_names='*'

ನಿಯತಾಂಕವನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ synchronous_commit ಅರ್ಥದಲ್ಲಿ local, ನಾವು ಸ್ಥಳೀಯ ಡಿಸ್ಕ್ಗಳು ​​ಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಉಳಿಯುವ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸುತ್ತೇವೆ, ಆದರೆ ನೆಟ್ವರ್ಕ್ ಪ್ರತಿಕೃತಿ ಕಮಿಟ್ಗಳು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅಸಮಕಾಲಿಕವಾಗಿರುತ್ತವೆ. ಸಹಜವಾಗಿ, ಮೇಲೆ ತೋರಿಸಿರುವಂತೆ ಈ ಬದ್ಧತೆಗಳನ್ನು ಸಿಂಕ್ರೊನಸ್ ಮಾಡಲು ನಾವು ನಿರ್ಧರಿಸುತ್ತೇವೆ.

ನೀವು ಅಭಿವೃದ್ಧಿಯನ್ನು ಅನುಸರಿಸುತ್ತಿದ್ದರೆ ಗವರ್ನರ್ ಯೋಜನೆ, ನೀವು ಇತ್ತೀಚಿನ ಕೆಲವು ಬದಲಾವಣೆಗಳನ್ನು ಗಮನಿಸಿರಬಹುದು (1, 2), ಇದು ಗವರ್ನರ್ ಬಳಕೆದಾರರಿಗೆ ಈ ನಿಯತಾಂಕಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಮತ್ತು ಅವುಗಳ ಸ್ಥಿರತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.

ಇನ್ನೂ ಕೆಲವು ಪದಗಳು...

ಕೇವಲ ಒಂದು ವಾರದ ಹಿಂದೆ, PostgreSQL ಅನ್ನು ತುಂಬಾ ಸೂಕ್ಷ್ಮವಾಗಿ ಟ್ಯೂನ್ ಮಾಡುವುದು ಅಸಾಧ್ಯವೆಂದು ನಾನು ನಿಮಗೆ ಹೇಳಿದ್ದೆ. ಆಗ ಕಂಪೋಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ತಂಡದ ಸದಸ್ಯ ಕರ್ಟ್ ಅಂತಹ ಅವಕಾಶವಿದೆ ಎಂದು ಒತ್ತಾಯಿಸಿದರು. ಅವರು ನನ್ನ ಆಕ್ಷೇಪಣೆಗಳನ್ನು ಶಾಂತಗೊಳಿಸಿದರು ಮತ್ತು PostgreSQL ದಾಖಲಾತಿಯಲ್ಲಿ ಕಂಡುಕೊಂಡರು ಕೆಳಗಿನವುಗಳು:

ಈ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಬದಲಾಯಿಸಬಹುದು. ಯಾವುದೇ ವಹಿವಾಟಿನ ನಡವಳಿಕೆಯು ಬದ್ಧತೆಯ ಸಮಯದಲ್ಲಿ ಪರಿಣಾಮ ಬೀರುವ ಸೆಟ್ಟಿಂಗ್‌ನಿಂದ ನಿರ್ಧರಿಸಲ್ಪಡುತ್ತದೆ. ಆದ್ದರಿಂದ, ಕೆಲವು ವಹಿವಾಟುಗಳು ಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಮತ್ತು ಇತರರಿಗೆ ಅಸಮಕಾಲಿಕವಾಗಿ ಬದ್ಧವಾಗಲು ಸಾಧ್ಯ ಮತ್ತು ಉಪಯುಕ್ತವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಒಂದನ್ನು ಒತ್ತಾಯಿಸಲು multistatement ಪ್ಯಾರಾಮೀಟರ್‌ನ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವು ವಿರುದ್ಧವಾಗಿ, ಹೊಂದಿಸಿದಾಗ ಮಾಡಲು ವಹಿವಾಟು ಅಸಮಕಾಲಿಕವಾಗಿ ನಡೆಯುತ್ತದೆ SET LOCAL synchronous_commit TO OFF ವಹಿವಾಟಿನಲ್ಲಿ.

ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗೆ ಈ ಸಣ್ಣ ಮಾರ್ಪಾಡಿನೊಂದಿಗೆ, ನಾವು ಬಳಕೆದಾರರಿಗೆ ಅವರ ಸ್ಥಿರತೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ನಿಯಂತ್ರಣವನ್ನು ನೀಡಿದ್ದೇವೆ.

ಮೂಲ: www.habr.com