Двухфазная фиксация в MongoDB
внимательно читать документации, у меня еще есть много вопросов о двухфазной фиксации в MongoDB.
В разделе восстановление от сбоев, почему существует только два класса сбоев? По моему мнению, неудача может произойти на любом из этих шагов, поэтому здесь должно быть намного больше, чем два класса. Например, что если, (in применить транзакцию к обоим счетам раздел), после обновления учетной записи A сбой сервера базы данных. Это означает, что счет a потерял некоторые деньги, ничего не произошло на счете B. И у нас была бы непоследовательная транзакция?
3 ответов
в моем мышлении сбой может произойти на любом из этих шагов, поэтому здесь должно быть намного больше, чем два класса.
главное помнить, что документация не является окончательным руководством по двухфазным коммитам, на самом деле двухфазные коммиты технически невозможны в MongoDB, и я настоятельно рекомендую вам получить ACID tech, если вы хотите их выполнить.
вы должны помнить, что есть определенные сценарии сбоя, которые вы не можете счетчик из-за этого не находится внутри самого сервера. Вместо этого все существование двухфазных коммитов-это только клиентская сторона, как таковая, она довольно хлипкая по сравнению с контролем TTL.
после обновления учетной записи a сервер базы данных не удалось. Это означает, что счет a потерял некоторые деньги, ничего не произошло на счете B. И у нас была бы непоследовательная транзакция?
в поддержку Philipps ответьте на исходную транзакцию между счетами A и B в этом случае он будет перенесен в finished/completed только после обновления счета B.
это означает, что транзакция не может быть помечена как завершенная, пока она не будет завершена.
вместо использования MongoDB для сценария, для которого он не предназначен, я бы рекомендовал использовать что-то, что предназначено для вашего сценария.
когда приложение или база данных внезапно аварийно завершает работу между применением транзакции к A и применением транзакции к B, все равно будет транзакция с state:"pending" в глобальной коллекции транзакций. Ваш сценарий восстановления, который вы запускаете после сбоя, должен заметить это, проверить две учетные записи и увидеть, что есть ожидающая транзакция в одной, но не в другой учетной записи. Теперь он знает все, что ему нужно знать, чтобы либо откатить транзакцию, либо попытаться завершить он.
да, написание сценария восстановления, который является умным, нелегко. Но транзакции в системе баз данных, не предназначенной для них, всегда сложны. Иногда вы можете обойти требование транзакций в MongoDB, разработав свои документы таким образом, что поля, которые необходимо обновить вместе, всегда находятся в одном документе, но не всегда есть разумный способ сделать это. Когда ваш прецедент абсолютно нуждается в транзакциях, защитите свое здравомыслие и используйте реляционную базу данных.