История изменений
Исправление sanyo1234, (текущая версия) :
Сегодня один сервер закончил запись транзакций на цифре 5000 и похерился, другой сервер для этих 5000 транзакций записал детальную инфу, а ты такой умный взял и восстановил снапшот сделанный на 4000-ной транзакции, чем похерил детальную инфу для тыщи транзакций на втором сервере.
Выше я тебе привел кейс для использования снэпшотов. Снэпшоты - это только дополнительный инструмент.
Ессно для восстановления рабочей нагрузки используются архивные логи и штатные бэкапы. Я не понимаю, зачем ты сравниваешь снэпшоты в качестве замены стандартной процедуры восстановления базы, вероятно ты не понимаешь, для чего нужны снэпшоты баз.
MySQL тебе дурачку в этом случае скажет «Duplicate entry for key», банк уволит со взысканием, а государство вообще посадить может за вредительство.
MySQL никогда ничего мне не скажет, потому что я никогда бы не согласился его админить. А всех тех, кто выбирает колхозно-костыльный MySQL для рабочей нагрузки (кроме популярных бесплатных кидискриптисов типа CMS) я бы сразу увольнял как проф непригодных и никогда больше не допускал бы до баз данных.
Для реляционных ACID баз данных есть нормальные СУБД типа IBM Db2, PostgreSQL, Microsoft SQL, etc., а не сраный MySQL.
Исправление sanyo1234, :
Сегодня один сервер закончил запись транзакций на цифре 5000 и похерился, другой сервер для этих 5000 транзакций записал детальную инфу, а ты такой умный взял и восстановил снапшот сделанный на 4000-ной транзакции, чем похерил детальную инфу для тыщи транзакций на втором сервере.
Выше я тебе привел кейс для использования снэпшотов. Снэпшоты - это только дополнительный инструмент.
Ессно для восстановления рабочей нагрузки используются архивные логи и штатные бэкапы. Я не понимаю, зачем ты сравниваешь снэпшоты в качестве замены стандартной процедуры восстановления базы, вероятно ты не понимаешь, для чего нужны снэпшоты баз.
MySQL тебе дурачку в этом случае скажет «Duplicate entry for key», банк уволит со взысканием, а государство вообще посадить может за вредительство.
MySQL никогда не скажет мне ничего, потому что я никогда бы не согласился админить его. А всех тех, кто выбирает колхозно-костыльный MySQL для рабочей нагрузки (кроме популярных бесплатных кидискриптисов типа CMS) я бы сразу увольнял как проф непригодных и никогда больше не допускал бы до баз данных.
Для реляционных ACID баз данных есть нормальные СУБД типа IBM Db2, PostgreSQL, Microsoft SQL, etc., а не сраный MySQL.
Исходная версия sanyo1234, :
Сегодня один сервер закончил запись транзакций на цифре 5000 и похерился, другой сервер для этих 5000 транзакций записал детальную инфу, а ты такой умный взял и восстановил снапшот сделанный на 4000-ной транзакции, чем похерил детальную инфу для тыщи транзакций на втором сервере.
Выше я тебе привел кейс для использования снэпшотов. Снэпшоты - это только дополнительный инструмент.
Ессно для восстановления рабочей нагрузки используются архивные логи и штатные бэкапы. Я не понимаю, зачем ты сравниваешь снэпшоты в качестве замены стандартной процедуры восстановления базы, вероятно ты не понимаешь, для чего нужны снэпшоты баз.
MySQL тебе дурачку в этом случае скажет «Duplicate entry for key», банк уволит со взысканием, а государство вообще посадить может за вредительство.
MySQL никогда не скажет мне ничего, потому что я никогда бы не согласился админить его. А всех тех, кто выбирает колхозно-костыльный MySQL для рабочей нагрузки (кроме популярных бесплатных кидискриптисов типа CMS) я бы сразу увольнял как проф непригодных и никогда больше не допускал бы до баз данных.
Для баз данных есть нормальные СУБД типа IBM Db2, PostgreSQL, Microsoft SQL, etc., а не сраный MySQL.