надежность 100%?

блин, вы как маленький.
Хорошо, перфразирую: считаете ли вы вероятность резкого и неожиданного выключения реального физического сервера ну пусть даже только от сбоя электричества (а ведь и ups может не включиться), хотя в общем случае - от множества различных поломок, настолько низкой, что в БД можно не предусматривать механизмы восстановления после неожиданного выключения?

так тогда о чем вы?

ладно, мы про разные вещи. Я про худший случай, когда все равно выключится, вы - про лучший.

Как правило ИБП типа online (с двойным преобразованием) позволяют даже очень чувствительное оборудование защитить от сбоев электропитания.
Но это не аргумент для отказа от  других механизмов защиты данных от повреждения или утраты

знакомый энергетик говорил, что не заметно пропадание электричества на время меньшее половине длины волны, то есть при 50 гц - 1\100 сек.

Речь идёт о штатном выключении

Предлагаю не набрасывать, а говорить по существу для начала

там была беседа с другим человеком, он потом удалил свои сообщения. Это было не вам

Ок

при штатном выключении, если предварительно снять с БД нагрузку, восстановление после просто выключения будет околонулевым. Да и никто не заставляет прям рубить контейнер. Можно и послать базе команду выключиться, хотя это и требует дополнительного управления.

Речь о том, что docker stop не то же самое что systemctl shutdown

Docker просто остановит контейнер, а в другом случае система дождется завершения

в теории - нужно просто чуть более умное управление. Просто не делать так.
Я спросил друзей-девопсов. Если что-нибудь умное ответят - напишу

товарищ ответил:
вообще-то для тушения процессов в докере используется сигтерм, и только по завершению грейс-периода идет сигкилл.... время грейса можно настроить в конфиге

а это прям полностью эмулирует systemctl shutdown

только по дефолту там 10 сек. что меньше, чем при выключении компа

Обычно под бд используются контроллеры с батарейкой, которые даже при внезапном отключении питания запишут данные из буфера на диск.

Собственно любая нормальная субд без особых проблем переживет внезапную остановку. Тут важно, чтобы данные, которые субд считает записанными, действительно записались на диск, а не умерли вместе с буфером.

Например у меня такая ошибка:
Duplicate class javax.inject.Inject found in modules jetified-jakarta.inject-2.6.1.jar (org.glassfish.hk2.external:jakarta.inject:2.6.1) and jetified-javax.inject-1.jar (javax.inject:javax.inject:1)

Градл документация предлагает что-то типа:
implementation('commons-beanutils:commons-beanutils:1.9.4') {
       exclude group: 'commons-collections', module: 'commons-collections'
   }

Как мне найти зависbмость, к которой нужно применить данный метод?