Tailscale ಕಂಪನಿಯು SQLiteಯ Write-Ahead Logging (WAL) ಕಾರ್ಯವಿಧಾನದಲ್ಲಿನ 16 ವರ್ಷಗಳ ಹಳೆಯ ದೋಷವು ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಮೌನವಾಗಿ ಹಾಳುಮಾಡಬಹುದು (corrupt) ಎಂದು ಖಚಿತಪಡಿಸಿದೆ. ಈ ದೋಷವನ್ನು ಸರಿಪಡಿಸಲು ಕಂಪನಿಯು SQLite ನಿರ್ವಾಹಕರೊಂದಿಗೆ (maintainers) ಕೆಲಸ ಮಾಡಿ, version 3.46.1 ರಲ್ಲಿ ಪರಿಹಾರವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ. ಈ ಸಂಶೋಧನೆಯು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಅನೇಕ ಆಧುನಿಕ ಸೇವೆಗಳು ಇನ್ನೂ SQLite ಅನ್ನು WAL ಮೋಡ್‌ನಲ್ಲಿ ಬಳಸುತ್ತಿವೆ ಮತ್ತು ಪತ್ತೆಹಚ್ಚಲಾಗದ ದೋಷವು ಕಾನ್ಫಿಗರೇಶನ್ ಡೇಟಾವನ್ನು ಅಳಿಸಿಹಾಕಬಹುದು ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ನೋಡ್‌ಗಳನ್ನು (network nodes) ಸ್ಥಗಿತಗೊಳಿಸಬಹುದು.

ಈ ದೋಷವು ಹೇಗೆ ತಪ್ಪಿಹೋಯಿತು

ಈ ದೋಷವು 2010 ರಿಂದ WAL ಕಾರ್ಯವಿಧಾನದಲ್ಲೇ ಇತ್ತು. ಹೆಚ್ಚಿನ ಏಕಕಾಲಿಕ ಪ್ರವೇಶ ಮಾದರಿಗಳು (high-concurrency access patterns) ಮತ್ತು ಕೆಲವು ಫೈಲ್-ಸಿಸ್ಟಮ್ ನಡವಳಿಕೆಗಳ ನಡುವಿನ ಅಪರೂಪದ ಸಂವಹನವು ಮೌನ ಡೇಟಾ ದೋಷಕ್ಕೆ (silent data corruption) ಕಾರಣವಾಯಿತು ಮತ್ತು ಸಾಮಾನ್ಯ ಹೆಲ್ತ್ ಚೆಕ್‌ಗಳು ಇದನ್ನು ಪತ್ತೆಹಚ್ಚಲು ವಿಫಲವಾದವು.

Tailscale ಎಂಜಿನಿಯರ್‌ಗಳು ಮೊದಲು ಕೆಲವು ನೋಡ್‌ಗಳು ಯಾವುದೇ ಸ್ಪಷ್ಟವಾದ ದೋಷ ಸಂದೇಶಗಳಿಲ್ಲದೆ ತಮ್ಮ ಸಂಗ್ರಹಿಸಿದ ಸ್ಥಿತಿಯನ್ನು (stored state) ಕಳೆದುಕೊಳ್ಳುತ್ತಿರುವುದನ್ನು ಗಮನಿಸಿದರು. “is the database up?” ಎಂದು ಕೇಳುವ ಪ್ರೋಬ್‌ಗಳು (probes) ಯಶಸ್ಸನ್ನು ತೋರಿಸುತ್ತಿದ್ದವು, ಆದರೆ ಕಾನ್ಫಿಗರೇಶನ್ ಎಂಟ್ರಿಗಳು ಮಾಯವಾಗುತ್ತಿದ್ದವು. ಈ ಸಮಸ್ಯೆಯನ್ನು ಪುನರಾವರ್ತಿಸಲು (reproducing), WAL ಪಥಕ್ಕೆ ಒತ್ತಡ ನೀಡುವ ಮತ್ತು ಫೈಲ್-ಸಿಸ್ಟಮ್ ಟೈಮಿಂಗ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ಕಸ್ಟಮ್ ಟೂಲಿಂಗ್ ಅಗತ್ಯವಿತ್ತು, ಇದೇ ಕಾರಣಕ್ಕೆ ಈ ಸಮಸ್ಯೆ ಒಂದು ದಶಕಕ್ಕೂ ಹೆಚ್ಚು ಕಾಲ ಅಡಗಿದ್ದಿತು.

ಯಾರು ಕಳವಳಪಡಬೇಕಿದೆ?

  • WAL ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ SQLite ಅನ್ನು ಚಲಾಯಿಸುವ ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್, ವಿಶೇಷವಾಗಿ ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ ಪ್ರಕ್ರಿಯೆಗಳು (processes) ಅಥವಾ ಥ್ರೆಡ್‌ಗಳು (threads) ಬರೆಯುವಾಗ.
  • ಅಸಂಪ್ರದಾಯಿಕ ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಮಾಡಲಾದ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿನ ನಿಯೋಜನೆಗಳು (deployments), ಅಲ್ಲಿ ವಿಳಂಬ (latency) ಮತ್ತು ಕ್ಯಾಷಿಂಗ್ (caching) ಸಮಯದ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ.
  • ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುವ SQLite ಫೈಲ್ ಅನ್ನು ಡೇಟಾ ಸಮಗ್ರತೆಯ (data integrity) ಖಾತರಿ ಎಂದು ಪರಿಗಣಿಸುವ ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಸೇವೆಗಳು.

ತಡೆಗಟ್ಟುವ ಕ್ರಮಗಳು

  1. SQLite ಅನ್ನು ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡಿ – version 3.46.1 ಅಥವಾ ನಂತರದ ಆವೃತ್ತಿಗೆ ಬದಲಾಯಿಸಿ; WAL ದೋಷವನ್ನು ಅಲ್ಲಿ ಸರಿಪಡಿಸಲಾಗಿದೆ.
  2. ಇಂಟೆಗ್ರಿಟಿ ಚೆಕ್‌ಗಳನ್ನು ರನ್ ಮಾಡಿ – ಡೇಟಾಬೇಸ್‌ನ ಆಂತರಿಕ ರಚನೆಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ನಿಯಮಿತವಾಗಿ PRAGMA integrity_check; ಅಥವಾ ವೇಗವಾದ PRAGMA quick_check; ಅನ್ನು ಚಲಾಯಿಸಿ.
  3. WAL ಬಳಕೆಯನ್ನು ಆಡಿಟ್ ಮಾಡಿ – ಕೋಡ್‌ಬೇಸ್‌ಗಳಲ್ಲಿ journal_mode=WAL ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗಾಗಿ ಸ್ಕ್ಯಾನ್ ಮಾಡಿ ಮತ್ತು ಏಕಕಾಲಿಕ ಪ್ರವೇಶದ ಮಟ್ಟವು ಅವುಗಳನ್ನು ಸಮರ್ಥಿಸುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ.
  4. ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಬಲಪಡಿಸಿ – ಕೇವಲ ಸಂಪರ್ಕ ಲಭ್ಯತೆಯನ್ನು (reachability) ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವ ಬದಲು, ನಿರೀಕ್ಷಿತ ಡೇಟಾ ಮಾದರಿಗಳು ಅಥವಾ ರೋ (row) ಸಂಖ್ಯೆಗಳನ್ನು ಹೋಲಿಸುವ ಚೆಕ್‌ಗಳನ್ನು ಸೇರಿಸಿ.
  5. ನಿರಂತರವಾಗಿ ಬ್ಯಾಕಪ್ ತೆಗೆದುಕೊಳ್ಳಿ – Litestream ನಂತಹ ಪರಿಕರಗಳನ್ನು ಬಳಸಿ, ಇವು SQLite ಬದಲಾವಣೆಗಳನ್ನು ನೈಜ ಸಮಯದಲ್ಲಿ (real time) ಪ್ರತಿಲিপি ಮಾಡುತ್ತದೆ, ಇದರಿಂದ ದೋಷವು ಪತ್ತೆಯಾಗದಿದ್ದರೆ ಸುರಕ್ಷತಾ ಜಾಲವನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಈ ಘಟನೆಯು ಕಲಿಸುವ ಪಾಠಗಳು

  • ಹಳೆಯ ದೋಷಗಳು ಹೊಸ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಹೊರಬರಬಹುದು – ಸೇವೆಗಳು ವಿಸ್ತರಿಸುತ್ತಿದ್ದಂತೆ, ಒಮ್ಮೆ ಅಪರೂಪವಾಗಿದ್ದ ಮಾದರಿಗಳು ಸಾಮಾನ್ಯವಾಗುತ್ತವೆ ಮತ್ತು ಹಳೆಯ ದೋಷಗಳನ್ನು ಬಯಲಿಗೆಳೆಯುತ್ತವೆ.
  • ಮೌನ ದೋಷವು ಕ್ರ್ಯಾಶ್ (crash) ಆಗುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಅಪಾಯಕಾರಿ – ಕ್ರ್ಯಾಶ್ ಆದಾಗ ಮರುಪ್ರಾರಂಭಿಸಲು (restart) ಅನಿವಾರ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಅಲರ್ಟ್‌ಗಳನ್ನು ನೀಡುತ್ತದೆ; ಆದರೆ ಮೌನ ಡೇಟಾ ನಷ್ಟವು ವಾರಗಟ್ಟಲೆ ಗಮನಕ್ಕೆ ಬರದೇ ಇರಬಹುದು.
  • ಮುಕ್ತ ಪೋಸ್ಟ್-ಮೋರ್ಟಮ್‌ಗಳು (post-mortems) ಪರಿಸರ ವ್ಯವಸ್ಥೆಗೆ ಸಹಾಯ ಮಾಡುತ್ತವೆ – Tailscale ನ ವಿವರವಾದ ವರದಿಯು ಇತರ ತಂಡಗಳಿಗೆ ತಮ್ಮ ನಿಯೋಜನೆಗಳನ್ನು (deployments) ಶೀಘ್ರವಾಗಿ ಆಡಿಟ್ ಮಾಡಲು ಅಗತ್ಯವಿರುವ ಮಾಹಿತಿಯನ್ನು ನೀಡಿತು.

ಮುಂದೆ ಗಮನಿಸಬೇಕಾದವುಗಳು

ಸುದ್ದಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಮೊದಲು ಪರಿಹಾರ ಸಿದ್ಧವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು Tailscale, SQLite ತಂಡದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿತು.

ಸಾರಾಂಶ: 16 ವರ್ಷಗಳ ಕಾಲ ಗಮನಕ್ಕೆ ಬಾರದೆ ಇದ್ದ ದೋಷವು ಮರುಕಳಿಸಿತು, ಏಕೆಂದರೆ ಆಧುನಿಕ ಕೆಲಸದ ಹೊರೆಗಳು (workloads) ಮೂಲ ಡೆವಲಪರ್‌ಗಳು ಎಂದಿಗೂ ಊಹಿಸದ ರೀತಿಯಲ್ಲಿ SQLite ಅನ್ನು ಬಳಸಿದವು. ಲೈಬ್ರರಿಯನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುವುದು, ಇಂಟೆಗ್ರಿಟಿ ಚೆಕ್‌ಗಳನ್ನು ರನ್ ಮಾಡುವುದು ಮತ್ತು ಅಬ್ಸರ್ವೇಬಿಲಿಟಿಯನ್ನು (observability) ಸುಧಾರಿಸುವುದು ಇಂತಹ ಗುಪ್ತ ವೈಫಲ್ಯಗಳಿಂದ ರಕ್ಷಿಸಿಕೊಳ್ಳಲು ಇರುವ ಅತ್ಯಂತ ವೇಗವಾದ ಮಾರ್ಗಗಳಾಗಿವೆ.