Окончание истории с PouchDB
Jun. 16th, 2015 04:14 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Последнюю неделю я практически рыл носом землю, чтобы понять точно, что же вызвало потерю данных. Нашёл и зафайлил кучу багов разной степени тяжести в PouchDB, но ручное прикрытие каждого так и не давало ответа, в чём же в самом деле причина.
Апофеоз истории вот тут https://github.com/pouchdb/pouchdb/issues/3961. В результате я написал тест, который имитирует, что происходит в cloudwall без запуска cloudwall – но оказалось, что этот тест никто кроме меня не может воспроизвести. А у меня он железно воспроизводился на двух моих Маках в 100% случаев – но только для двух доменов, для остальных доменов всё было ок. Я даже стал подозревать в какой-то момент, что зелёные человечки – не выдумка (шучу :)
Ключик в решению проблемы увиделся, когда я слил свои файлы IndexedDB из Хрома разработчику PouchDB, и он не смог воспроизвести баг даже с ними. Просто ничего больше не осталось, как грешить на файловую систему – всё остальное было к тому моменту тщательнейшим образом проверено и отброшено.
Так и оказалось – на обоих Маках у меня были сбои на FS. На эйре, видимо, деградировал SSD, а на iMac – HDD, который часть Fusion Drive. Именно поэтому баг и не проявлялся, пока не закроешь вкладку в Хроме – браузер закрывал файл, а файловая система его обнуляла из-за ошибок в бинарном дереве каталога.
Любопытно, что проверка при запущенных ОС не показывала мне никаких проблем с дисками. Для обнаружения проблем надо было перезагрузить обе машины и запустить проверку диска по-холодному. После исправления дисков и удаления вручную каталогов с базами данных баг перестал воспроизводиться.
Из этого надо вынести несколько уроков:
Апофеоз истории вот тут https://github.com/pouchdb/pouchdb/issues/3961. В результате я написал тест, который имитирует, что происходит в cloudwall без запуска cloudwall – но оказалось, что этот тест никто кроме меня не может воспроизвести. А у меня он железно воспроизводился на двух моих Маках в 100% случаев – но только для двух доменов, для остальных доменов всё было ок. Я даже стал подозревать в какой-то момент, что зелёные человечки – не выдумка (шучу :)
Ключик в решению проблемы увиделся, когда я слил свои файлы IndexedDB из Хрома разработчику PouchDB, и он не смог воспроизвести баг даже с ними. Просто ничего больше не осталось, как грешить на файловую систему – всё остальное было к тому моменту тщательнейшим образом проверено и отброшено.
Так и оказалось – на обоих Маках у меня были сбои на FS. На эйре, видимо, деградировал SSD, а на iMac – HDD, который часть Fusion Drive. Именно поэтому баг и не проявлялся, пока не закроешь вкладку в Хроме – браузер закрывал файл, а файловая система его обнуляла из-за ошибок в бинарном дереве каталога.
Любопытно, что проверка при запущенных ОС не показывала мне никаких проблем с дисками. Для обнаружения проблем надо было перезагрузить обе машины и запустить проверку диска по-холодному. После исправления дисков и удаления вручную каталогов с базами данных баг перестал воспроизводиться.
Из этого надо вынести несколько уроков:
- БД ни при каких обстоятельствах не должна считать нижележащую технологию надёжной. А так считают и PouchDB, и IndexedDB и, увы мне, CloudWall.
- При обнаружении багов с потерей данных идти надо начинать снизу вверх, а не сверху вниз. Это тот-же ровно принцип, как и в случае с проверкой розетки, питания и предохранителей в первую очередь, когда «компьютер сломался». Я как-то не соотносил эту народную мудрость с высокими технологиями, а напрасно.
- Баг – лучший учитель. Я за последнюю неделю досконально разобрался, как устроен PouchDB в части репликации, внешних ajаx-запросов и взаимодействия с IndexedDB. Попутно разобрался со схемой запросов к IDB по-хорошему (ну и гадость, доложу я вам), с производительностью IDB, с тем, как устроены файлы каталогов в HFS+, и много ещё чего попутного по мелочи.