{imgicourl}{zamok}
<< предыдущая заметкаследующая заметка >>
03 июня 2020
Крах всему: помощь зала

UPD: Всем спасибо за советы, вопрос решен: оказывается, инкрементальный бэкап MySQL MariaDB не будет правильно работать до тех пор, пока базы не перевести из устаревшего формата MyISAM в формат InnoDB. Сделать это по-любому следует, формат устаревший. Перегнать MyISAM в InnoDB можно одной командой «ALTER TABLE `имя таблицы` ENGINE=InnoDB».

БЫЛО:

Вчера лишился всего, шо нажито непосильным трудом — всех своих сайтов и сетевых архивов. Потом все вернулось, но страху натерпелся...

История смешная. Короче, Linux-сервер. Я люблю, чтобы сервер, система и все прочее легко восстанавливаемое говно было где оно само захочет, но вот мои уникальные данные — где я захочу. А именно - в отдельной корневой папке, желательно даже на отдельной партиции. Мои данные уникальны, поэтому должны храниться на самом видном для меня месте. Чтоб если переезд — не бегать их собирать по кусочкам в далеких сраных папках самого разного софта, а взять и перенести. Как-то так.

Однако, nginx и особенно mysql очень не любят, когда их данные хранят не в /home/www, где они привыкли. И симлинк тоже не устраивает капризного mysql. Поэтому единственный способ вынести базы и сайты в корневую папку — это монтировать ее как bind в /home/www Поэтому у меня в fstab всегда было написано: "/home/www /R none bind 0 0" Но вчера я планово обновил систему, перезагрузился — и диск /R исчез! Увидев ПУСТУЮ папку /R, я пришел в неописуемый ужас и час страшно горевал, потому что там было всё: весь lleo.me, весь binoniq.net, все базы, вообще всё! И без бэкапа фактически, ну то есть, с бэкапом, но полугодичной давности. Потом удалось разобраться. Оказалось, "/home/www /R none bind 0 0" конечно монтирует первое во второе, поэтому вместо /R появилась пустая /home/www, а его реальное содержимое стало невидимым. Правильно наоборот: "/R /home/www none bind 0 0" Но блин, остается страшной загадкой, как оно у меня работало все это время — полгода, год? Либо я вписал это в fstab и не перегружал никогда машину (не верится), либо обновился mount, раньше он каким-то образом понимал, что строчка ошибочна, и монтировал как надо, а после обновления перестал... В общем, загадка.

Далее до полуночи я пробовал придумать наконец себе бэкап. Потому что это вообще с моей стороны дикое свинство подвергать опасности не только lleo.me, но и binoniq.net, где пользовательские данные. И оказалось, что с проблемой бэкапа до сих пор в мире всё достаточно тупо. Ну, то есть, файлы-то бэкапить не проблема, есть rsync, например. Но файлы и потерять не проблема, что там за файлы? Код движка — восстанавливается, фотки дневника (по крайней мере, моего) — они тоже копируются в разные места, в альбомы ВКонтактик, например, фотки каждой заметки исправно дублируются. В случае чего из кэшей поисковика собрать можно, у меня когда-то даже был скрипт, который собирал так убитые ЖЖ. Поэтому основная проблема бэкапа — это базы MySQL. Размер баз у меня — несколько гигабайт, и каждый вечер их в бэкап перезаливать на удаленное облако глупо. Особенно если на Яндекс-Диск, он монтируется как davfs2, а это, кто не в курсе, очень тормозная и проблемная штука, чтобы ворочать гигантскими файлами...

Окей, у mariadb есть фича инкрементального бэкапа. То есть, он якобы умеет записывать изменения. Инструкции предлагают сделать первый раз бэкап основной, а следующим шагом писать от него инкрементальный с последними изменениями относительно основного:

mariabackup --backup --target-dir=/B/backup --user=lleo --password=T,fnmNsEvysq

mariabackup --backup --target-dir=/B/inc1/ --incremental-basedir=/B/backup/ --user=lleo --password=T,fnmNsEvysq

Однако, как я ни бился, итог плачевный - "инкрементальный бэкап" по размерам получается примерно как основной, хотя за эти несколько минут в базах изменений накапливается (в основном, от ваших посещений) на копейку:

/B/backup 2486M

/B/inc1 2279M

Требуется помощь зала: что я делаю не так с инкрементальным бэкапом MariaDB? Как вы бэкапите базы?

PS: Видимо я не очень хорошо объяснил, уточню: бэкап файлов не является проблемой и софт по бэкапу файлов мне не нужен. Файлы (по сути - фотки) добавляются относительно редко, никогда потом не меняются, и они небольшие. То есть, нет никаких проблем с их бэкапом. Проблемой является именно бэкап баз MySQL MariaDB, потому что каждый чих на сайте приводит к изменению в гигабайтных файлах. С точки зрения софтинки, умеющей бэкапить файлы, когда кто-то на сайте поставил вашему комменту плюсик, то гигабайтный файл всех комментариев за последние 20 лет стал другим, и его надо срочно бежать перезаливать взамен старого. А это не дело.

<< предыдущая заметка следующая заметка >>
пожаловаться на эту публикацию администрации портала
Страницы, которые привлекли мое внимание за последние дни, рекомендую:
архив ссылок
Оставить комментарий
Linux Safari Chrome
 Santa Clara
0
0
B0P0H0K
Насчёт бэкапа, поглядите на dirvish.
У меня очень славно работает, очень инкрементно.
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Давайте уточним: если это какая-то приблуда для бэкапа файлов, то бэкап файлов не является проблемой. Проблемой является именно бэкап баз MySQL MariaDB, потому что каждый чих на сайте приводит к изменению гигабайтных файлов, и с точки зрения внешней приблуды, когда кто-то поставил вашему комменту плюсик, то это уже, грубо говоря, новый файл всех комментариев за 20 лет.

Поэтому вопрос: этот ваш dirvish точно работает с MySQL?
Linux Safari Chrome
 Santa Clara
0
0
B0P0H0K
Нет, dirvish is agnostic относительно содержимого файлов.
Но! Вы можете управлять периодичностью бэкапов и устанавливать cutoff time для возраста хранимых копий. Таким образом, средний общий размер всего занимаемого бэкапом места остаётся примерно постоянным. Сколько нового приходит, примерно столько же старого сносится.
Иными словами, чем глубже в прошлое вы хотите глядеть, и с чем более мелким шагом по оси времени, тем больше места вам надо.
Linux Safari Chrome
 Санкт-Петербург
1
0
LLeo
Ну не, работа с файлами хуйня и прошлый век. Заливать на удаленный сервер десять раз по 3гб только потому, что какому-то комменту поставили десять плюсов, это абсурд.
Mac Safari
 Швейцария
5
1
Дмитрий-3
Если такой хороший коммент, то чего бы и не залить
Firefox
 Москва
2
0
admin123
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Продвинуто: ФС zfs, бэкап в виде мгновенного снимка и встроенной синхронизации с другой zfs. Копируются только нужные блоки данных, размер которых устанавливается при создании "тома". Минус: zfs медленней. Плюс все остальной
Firefox
 Москва
1
0
admin123
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Почему-то к предыдущему комменту чужой юзерпик подтянулся
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Меня интересует бэкап баз в первую очередь. Файлы копировать не проблема, да и они достаточно редко обновляются.

Юзепик пока вы не залили свой, движок вам будет подыскивать тот, который считает похожим на вас. Этого человека не существует, это симуляция.
Firefox
 Австралия
0
0
hugene
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Zfs делает поблочный дифф, так что не будут там твои страшные гигобайты литься каждый раз. Только изменённые блоки. Хотя я сомневаюсь, что такой ретроград, как ты, захочет связываться с zfs. Может, оно и к лучшему :)
Firefox
 Москва
0
0
admin123
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Для zfs, все равно что там в томе, файлы или бд. Операции производятся с блоками сырых данных.емнип кусками до 1мб, обычно 128кб. Плюс мгновенные снимки фс, сами по себе бекап, но не удаленный
Linux Ubuntu Firefox
 Воронеж
1
0
selivan
Для MySQL/MariaDB/Percona Server есть прекрасный percona-xtrabackup https://www.percona.com/software/mysql-database/percona-xtra[...] Он же в девичестве innobackupex.

Создаёт именно инкрементальный бекап, а если ещё куда-нибудь сохранять бинлоги, можно вообще point-in-time recovery накрутить(то есть восстановление вплоть до последней транзакции в последнем сохранённом бинлоге).

Правда, лучше всего он работает с движком InnoDB, насчёт MyISAM вроде умеет, но обещать ничего не могу - не проверял. Но в любом случае держать в 2020 году MyISAM таблицы - это или какой-то ну уж очень специфичный случай, либо адское легаси, которое давно пора выжечь напалмом.

Кстати, этот ваш mariabackup судя по опциям похож на ещё один форк innobackupex, так вопрос про MyISAM остаётся открытым.
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Спасибо, буду читать.
Насчет InnoDB - у меня часть новых в InnoDB, все старые в MyISAM.
Как их перегонять в InnoDB - хз.

Кроме того, я что-то плохое слышал про InnoDB - то ли она хуже MyISAM при каких-то условиях (частая перезапись или крупные данные или мелкие - не помню уже), то ли у нее хуже со стабильностью во время самовосстановления и вероятности крэша. Надо вспомнить, что именно я слышал и от какого специалиста.
Linux Ubuntu Firefox
 Воронеж
2
0
selivan
MyISAM превосходит InnoDB в производительности на чтение при малом количестве записи.

Но у него нет построковых блокировок, только табличные целиком. Поэтому при нагрузках, где много параллельной записи разными потоками в одну и ту же таблицу, он адски тупит.

Восстановление при креше как раз лучше у InnoDB, впрочем там есть опции тонкой настройки баланса скорость/гарантированная консистентность.

Ещё MyISAM не реализует транзакции, foreign keys и какие-то ещё полезные куски стандарта SQL.

Ну и видимо innobackupex и потомки не могут сделать нормальный инкрементальный бекап MyISAM.

Для системы где много чтений и не нужна транзакционная целостность в наши дни принято уже какой-нибудь NoSQL прикручить, MongoDB или Cassandra. Они MyISAM по производительности на таких типах нагрузок бьют.
Windows Firefox
 Москва
0
0
Dimonius
А если в основном чтение, но MyISAM полностью устраивает (тем более MySQL на сервере уже стоит и используется и на других проектах), зачем городить зоопарк из БД? Тем более под него надо будет переписывать все запросы в проектах. Да и на многих выборках там победа в скорости не такая уж и впечатляющая.
Windows Safari Chrome
 Киев
2
0
Кондыбас
муисам и иннодб - это не разные бд, а разные движки внутри mysql/mariadb.

Проблема в том, что муисам не поддерживает транзакции. В иннодб эта поддержка реализована через ведение журнала ивентов, и этот же журнал используется для построения дельты инкрементного бекапа. Т.е. эффективное бекапирование возможно для иннодб, и невозможно для муисама.

Переписывать запросы при переходе с муисама на иннодб не придется, муисам-специфичный синтакс является подмножеством иннодб-специфичного синтакса. Но не наоборот.
Linux Safari Chrome
 Санкт-Петербург
1
0
LLeo
Ну, кстати, переписывать запросы мне бы особо и не пришлось: все запросы в движке делает одна процедура (она же и кэширует их через memcache). Когда я учил движок работать с php7 как mysql/mysqli, править пришлось одно лишь место.
Windows Safari Chrome
 Киев
0
0
Кондыбас
муисам быстрее иннодбы только при прямом чтении из файла. Но учитывая, что иннодб кешируется в памяти весь - и данные, и индексы, а муисам - только индексами, в реальных кейсах иннодб на чтение оказывается существенно быстрее.
Windows Safari Chrome
 Обнинск
2
0
BobaQPE
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Проблема размера инкриментального бекапа именно в МайИсам. никто не умеет их делать инкриментальным. (у него нет файла с логами, который можно забекапить).
Для переноса данных из МайИсам в ИнноДб, надо сделать бекап через MyDump, открыть файл редактором, и заменить все МайИсам на ИнноДБ. удалить все базы, и запустить восстановление из Дампа. Других способов нет.
Linux Ubuntu Firefox
 Воронеж
4
0
selivan
С чего это вдруг?

ALTER TABLE mytable ENGINE=InnoDB;
Windows Safari Chrome
 Обнинск
0
0
BobaQPE
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Согласен.
Windows Safari Chrome
 Киев
0
0
Кондыбас
Еще нужно будет my.cnf тюнить - буферизация, кеширование, вот это вот все.
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
А вот вопрос тогда: могу я каким-то способом спросить у MySQL, в каком формате сейчас у него `таблица`? Мне это нужно, чтобы написать транслирующую утилиту для админки движка, чтобы каждый мог сделать переезд своих таблиц.
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
А, вот мне подсказали: show table status
Linux Firefox
 Таиланд
0
0
1 сентября каждый день
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
как прошло "alter table "?
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
Ну не так все просто. У меня есть куча сайтов, на них куча движков, мне надо сперва в движке написать в админке софт переезда. Часть админки, работающая с MySQL, уже по возможностям приближается к PMA, но смены системы таблиц там пока не было ;)
Windows Safari Chrome
 Киев
0
0
Кондыбас
Мой опыт показывает, что в 99.99% случаев миграция с муисама на иннодб проходит прозрачно и безболезненно. Но, как говорится, "случаи бывают разные". Скажем, астериск может не пережить перевода всей БД на иннодб. Критичными, вероятно, являются только 1-2 таблицы, но мне было лениво с этим разбираться.
Windows Safari Chrome
 Киев
1
0
Кондыбас
Конечно:

SHOW TABLE STATUS FROM `mydatabase`;

Одно плохо - это не запрос, и он возвращает не таблицу, которую можно использовать, как сабселект. И поля выбрать нельзя.

Но зато можно все это вычитать скриптом в шелл, там распарсить и уже дальше действовать.

mysql -u user -ppass -BNe 'SHOW TABLE STATUS FROM `mydatabase`;' > /tmp/dbtablestat.txt

while read TNAME TENGINE REST
do
. . . . .
done < /tmp/dbtablestat.txt

Как-то так
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
Спасибо, будем строить.
Mac Firefox
 Германия
2
0
karash_l
SELECT
table_name
FROM
information_schema.tables
WHERE
table_schema = '<название базы>'
AND engine = 'MyISAM';
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
Спасибо!
Windows Safari Chrome
 Обнинск
0
0
BobaQPE
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Есть один нюанс.
Нельзя перевести таблицы у которых есть полнотекстовый индекс на текстовых полях.
Так у меня пару таблиц не переехало :)
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Э-э-э... Не могу сообразить, как это?

Это полнотекстовый индекс?

`name` varchar(128) NOT NULL default '',
`text` text NOT NULL default '',
PRIMARY KEY (`name`(128),`acn`)

Или это?

`num` int(10) unsigned NOT NULL default '0' COMMENT 'id заметки',
`tag` varchar(128) NOT NULL default '' COMMENT 'имя тэга',
`acn` int(10) unsigned NOT NULL default '0' COMMENT 'Номер журнала',
PRIMARY KEY (`num`,`acn`,`tag`(128)),
KEY `acn` (`acn`)
Windows Safari Chrome
 Киев
2
0
Кондыбас
Все плохое, что говорилось об иннодб, по сравнению с муисамом, было справедливо лет десять тому. На сегодняшний день все болячки поправлены, все боттлнеки обойдены. Собсно, использовать муисам нет необходимости вообще, за исключением редких случаев, когда через блокировку целой таблицы реализуется неявная сериализация транзакций. Но это довольно узкоспецифичный прием, сайтостроителям оно точно не нужно.
Linux Safari Chrome
 Москва
2
0
vivliofika
Ещё есть ключевая проблема.

Часто накопительный формируется отлично. А обратно не восстанавливается. Это тоже надо проверить всячески и дотошно. Чтобы не получить корыто.
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
И как это всякий раз проверять?
Windows Safari Chrome
 Киев
0
0
Кондыбас
Нужно каждый раз после снятия инкремента делать mariabackup --prepare ... и парсить выхлоп. Если все ок - надеемся, что таки да. А если не ок, то нужно делать заново полный текущий бэкап.

Подробности письмом здесь: https://mariadb.com/kb/en/incremental-backup-and-restore-wit[...]
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Спасибо...
Linux Ubuntu Firefox
 Воронеж
1
0
selivan
ИМХО каждый раз проверять - оверкилл.

Достаточно разово проверить, что получается восстановить. Ну и проверять при каких-то изменениях в бекапе.

Если делать инкрементальные бекапы поверх друг друга, а не поверх полного, то после прогона --prepare поверх первого инкрементального, восстановить базирующиеся на нём другие инкрементальные уже не получится. Надо --prepare --apply-log-only.

Ну и конечно не надо копить инкрементальные бекапы за год, стоит всё-таки периодически снамать полный и базировать новые инкрементальные уже на нём.
Windows Safari Chrome
 Москва
0
0
vivliofika
теперь ты чуешь реальный, а не маркетинговый размер жопы.

Наличие инкремента не подразумевает наличие возможности восстановитсья.
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
И как это всякий раз проверять?
Linux Safari Chrome
 Москва
1
0
vivliofika
А ты не думал о реплике базы?

Она работает и создаёт реплику "рядом". Да, две быстрых СУБД. Зато для обеспечения работоспособности достаточно сторожок поставить и переключить. И когда возникает срабатывание, делать третью реплику в третьем месте до включения основной
Linux Ubuntu Firefox
 Воронеж
0
0
selivan
Фаулт толеранс это хорошо, но это не защищает от программных ошибок, бекап всё равно нужен.
Windows Safari Chrome
 Москва
0
0
vivliofika
согласен.

Я вообще не специалист тут. Поэтому, опираюсь на ваше мнение.
Windows Safari Chrome
 Киев
1
0
Кондыбас
Мария изрядно отклонилась от исходного форка мускля, и с версии 10.2 перконовский xtrabackup несовместим с ней. Поэтому экстру форкнули в mariabackup.
Mac Safari Chrome
 Washington
0
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Из-за 2-3 ГБ городить огород по-моему смысла нет никакого. Копировать весь файл на отдельный SSD - вопрос секунд, можно делать так часто как хочется. А реально достаточно раз в день наверное, и хранить версии за последнюю неделю.

Если основная опасность - поломка хардвера, то тогда софтверный RAID1, тогда вообще ничего бэкапить не надо. Когда один из двух дисков дохнет, покупать и втыкать замену.
Linux Ubuntu Firefox
 Санкт-Петербург
3
0
LLeo
При чем тут вообще втыкаемые диски? Речь не про домашний десктоп, а про хостинговый сервер за океаном.
Mac Safari Chrome
 Washington
0
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
> При чем тут вообще втыкаемые диски? Речь не про домашний десктоп, а
> про хостинговый сервер за океаном.

А какая разница? Поставить на сервер реальный или виртуальный SSD на несколько гигабайт, и бэкапить туда.

Против чего защищаться хотите: против поломки железа, или против своего ошибочного действия? Ваш сервер - это реальный сервер, или виртуальная машина вроде AWS instance?

1. Если это виртуальная машина с виртуальными дисками, то беспокоиться о поломке железа не нужно, об этом хостер позаботится. Можно считать, что ваш "диск" никогда не сломается. Тогда нужно защищаться только от нечаянного удаления. Значит нужен второй независимый диск, на который время от времени будет копироваться файл.

2. Если сервер - реальная физическая коробка с хардвером, то RAID1 для поломки плюс отдельный SSD диск для копирования файла.

Может я что-то не понял в вашей задаче?
Linux Safari Chrome
 Новосибирск
3
0
neko.aino
"1. Если это виртуальная машина с виртуальными дисками, то беспокоиться о поломке железа не нужно, об этом хостер позаботится. Можно считать, что ваш "диск" никогда не сломается."
Вы серьёзно?
Сам-то "диск" никогда не сломается, а данные могут и потеряться.
Mac Safari Chrome
 Washington
0
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Пока не знаем, что именно Ллео имеет ввиду под сервером. Если б мы говорили о AWS, то можно было бы просто делать image диска с файлом раз в день, и все.
Linux Safari Chrome
 Санкт-Петербург
2
0
LLeo
Я имел в виду инкрементальный бэкап базы, его мы обсуждаем. Рассуждения про сервер не решают проблему инкрементального бэкапа, а предложение бэкапиться на ту же самую машину непрофессионально. А если с сервером что-то случилось (пожар в датацентре, украли, перепутали с другим и отформатировали, конфисковала полиция, блок питания сгорел и подал на все шины 220) - то данные гибнут вместе с бэкапом?
Mac Safari Chrome
 Washington
1
1
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
> Я имел в виду инкрементальный бэкап базы, его мы обсуждаем.
> Рассуждения про сервер не решают проблему инкрементального бэкапа, а
> предложение бэкапиться на ту же самую машину непрофессионально. А
> если с сервером что-то случилось (пожар в датацентре, украли,
> перепутали с другим и отформатировали, конфисковала полиция, блок
> питания сгорел и подал на все шины 220) - то данные гибнут вместе с
> бэкапом?

Да обсуждайте что угодно, я буду следовать своему недавно заявленному принципу, что непрошенных советов не даю. Впрочем, вы и прошеный умудряетесь принять неучтиво. Ваш ответ намекает, что вы не поняли моего совета, ну да ладно.
Linux Safari Chrome
 Санкт-Петербург
1
0
LLeo
Простите, но вопрос был, как настроить инкрементальный бэкап MySQL. Мне на него ответили в комментах, правильный ответ: инкрементальный бэкап не будет работать до тех пор, пока базы не перевести из устаревшего формата MyISAM в формат InnoDB. Ваш же совет был не по теме, вдобавок технически невыполним. Поэтому, извините, не подошёл. Что обижаться?
Windows Safari Chrome
 Мытищи
0
0
2:5020/321
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Вероятность пожара в ДЦ невелика по сравнению с отказом диска. Поэтому, ежденевный бакап вполне можно делать на той же машине, на другой диск. И раз в неделю сливать его себе домой. И раз в полгода отвозить копию друзьям. Это наиболее дешевая и ненапряжная стратегия бакапа. Лить в облака это сразу и дорого и ненадежно.
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
Вероятность вообще штука сложная. Например, я за 30 лет не встречал ни одного (!) отказа диска. Да, я выбирал себе модели дисков крайне тщательно по рекомендации друзей из гарантийного отдела oldi, но факт остаётся фактом: за 30 лет я не видел ни одного отказавшего диска в своем парке. Поэтому лично для меня вероятность потерять данные выглядит в порядке убывания так:
1. Ошибочное удаление собственных данных
2. Проблема при переезде на новую систему или диск
3. Утрата физического доступа к носителю
4. Прочие маловероятные факторы: пожары, наводнения, кражи, изъятия, появление 380 вольт вместо 220, взлом хакера, неисправность диска и другое.

Это что касается домашнего парка. Что касается сервера, о котором речь, то самая вероятная проблема - номер 3. Сервер за океаном, датацентр неофициальный, если что-то произойдет на стойке серверов или на что-то отвлечется друг, который мне дал хостинг, - мне даже об этом и узнать будет негде. И - нет, никакого физического доступа к серверу (виртуалке) в Канаде у меня нет, не было и не будет. Возить в сумке переносные диски к серверу - не мой случай вообще, зачем это обсуждать?
Windows Safari Chrome
 Мытищи
0
0
2:5020/321
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Я потерял один свой диск по причине того что ребенок подполз и выключил сервак. Примерно через пару лет баг в FSCK поправили, диск поднялся. Дочка потеряла диск по непонятной причине, обнулился SSD и все, как будто secure erace сделали. Спас бакап месячной давности на диск в той же машине. По работе видел много дисков померших, один раз сам убил данные на живом диске. Возить диски в Канаду я не предлагал, вообще не в курсе был где у тебя сервак и какой.
Linux Safari Chrome
 Санкт-Петербург
0
1
LLeo
Не вдаваясь в подробности, манипуляции с сервером исключены. Вопрос был про инкрементальный бэкап MariaDB.
Mac Safari
 Израиль
3
0
braintunic
> Но блин, остается страшной загадкой, как оно у меня работало все это время — полгода, год?

> либо обновился mount, раньше он каким-то образом понимал, что строчка ошибочна, и монтировал как надо, а после обновления перестал

Нет, это невозможно.
Юниксовый mount испокон века тупо монтировал первую директорию на вторую, ещё до изобретения опции “-o bind” и даже до рождения Linux.

> Либо я вписал это в fstab и не перегружал никогда машину (не верится)

Вот это как раз самое вероятное.
Дело было так:
Ты остановил сервис базы данных, потом смонтировал эту лабуду вручную (запустил “mount -o bind /R /home/www“), потом запустил сервис базы данных, проверил, что всё работает правильно, а затем внёс твою ошибочную строчку в fstab, и больше не перезагружался.

Ну либо явная команда “mount -o bind /R /home/www” была у тебя в одном из “startup” скриптов (а может и до сих пор есть, только почему-то на этот раз не сработала).

Перед нынешним исправлением fstab, разве ты не проверил её дату модификации и не сравнил с датой последнего ребута?

В любом случае, и сейчас ещё можно поискать даты реально выполненных ребутов и маунтов в syslog, и там же будет видно что-на-что монтировалось.
В зависимости от твоей конфигурации syslog это могут быть файлы: /var/log/syslog , /var/log/messages , /var/log/kern.log , /var/log/kernel .
Windows Safari Chrome
 Киев
5
0
Кондыбас
"..разве ты не проверил её дату модификации и не сравнил с датой последнего ребута?.."

Бессердечный мерзавец!
Mac Safari
 Израиль
6
0
braintunic
> я пришел в неописуемый ужас и час страшно горевал, потому что там было всё: весь lleo,me, весь binoniq,net, все базы, вообще всё!

Все, что нажито непосильным трудом…
Три магнитофона, три кинокамеры заграничных, три портсигара отечественных, куртка замшевая… три

©
Linux Safari Chrome
 Санкт-Петербург
0
0
Сфи
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Спокойствие, только спокойствие. Должны же быть специально обученые люди, которые помогут.
Windows Firefox
 Сумы
7
0
Fisher123
Ну или в крайнем случае скажут: "Вот, господа, пусть это послужит для всех хорошим уроком..."
Windows Safari Chrome
 Amsterdam
1
0
mister-grim
«И без бэкапа фактически, ну то есть, с бэкапом, но полугодичной давности.»
Пытаюсь весь текст осилить, но почему-то взгляд цепляется за эту фразу.
Windows Safari Chrome
 Мытищи
0
0
2:5020/321
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
То есть люди делятся на две категории, те кто не делает бакапы и те кто не делает бакапы ежедневно?
Mac Firefox
 Эстония
0
0
mm3
Надеюсь логин и пароль в приведённых примерах не реально используемые и не имеют с реально используемыми ни какого совпадения. Светить в сети пароли путь даже и от внутренних сервисов не самая удачная идея.
Linux Ubuntu Firefox
 Израиль
0
0
200-1.95M
не бегать собирать кусочки в папках сраных -
заботу облегчить о данных и o посетителях биноника и дневника кто любит Леонида в разных странах
что посоветовать? не программист я, рифмоплёт
чтоб данных не произошёл вдруг неожиданно улёт
количество яиц как можно увеличить больше
в корзинах разных их держать-ценить хоть вечно хоть до следующего неминуемого (потенциального) бля краха дольше
Windows Safari Chrome
 Израиль
0
0
coolwolf0
Позволю вставить свои 5 копеек.
1. Общее замечание: базу надо разделить на метаданные и изменяющуюся часть. Во-первых, это упростит бекап, во-вторых позволит отделить мух от котлет в плане анализа и управления

2. Из личного опыта (правда с небольшими объемами базы) очень удачно работал такой приемчик: снимать копию базы через sqldump в текстовом виде и хранить diff-ы. Это потребует немного ресурсов на диске в момент бекапа/восстановления, зато надёжно и очень наглядно: можно просмотреть изменения глазами.
Windows Firefox
 Россия
0
0
Некто8
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
даже для больших баз (но не очень, гигабайты и десятки гб) отлично работает rdiff. Бинарный. На сотнях Гб тоже ничего, но очень много свободного места на операцию надо, он не умеет в пайпы
Windows Safari Chrome
 Mt Laurel
0
0
Alek
Я - не специалист по MariaDB, но все базы данных вроде работают по одной схеме: периодически делается полный бэкап, а между тем делается инкрементальный (чтобы восстановить сломаный сервер, сначала восстанавливают полный бэкап, а потом инкрементальные). Частота зависит от того, как часто происходят изменения, и как вам важны данные. В условиях корпорации, например, важная база данных сохраняется, допустим, ежедневно (или 2-4 раза в день), а инкрементальные данные сохраняются, допустим, каждые 15 минут). Для домашнего сервера, можно делать реже. В MariaDB, вроде такая же процедура: https://mariadb.com/kb/en/incremental-backup-and-restore-wit[...]
Linux Ubuntu Firefox
 Израиль
0
0
200-1.95M
как это можно папки сраными назвать
не Рашкой и не трактором ведь папке не бывать
Linux Ubuntu Firefox
 Израиль
0
0
200-1.95M
О блин ведь папка же отец
Вообще пиздец
А папки ведь отцы
Ну типа сраные ну типа пиздецы
Linux Ubuntu Firefox
 Израиль
0
0
200-1.95M
Алло Чмырнович и Андрюша! Нет
Я сраный, не обласканный поэт
Но как и вы, как все, был рад помочь бы Леониду
На сраные стишки мои никто пусть не таит обиду
Firefox
 Киев
0
0
LintruderX
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
По памяти работы с другими БД: для инкрементального бэкапа база должна работать в особом режиме - архивлог. Тогда можно создать полную копию БД, а потом "накатывать" на неё журнальные файлы.
В обычном же режиме журнальные файлы затираются, работая "по кругу".
Windows Safari Chrome
 Telefonica Germany GmbH & Co. OHG
1
0
Alexandr K
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Я, конечно, извращенец, но это похоже на задачу для git :) Что если выгружать дамп целиком, а потом гитом его анализировать и бекапить уже папку гита?

upd. Хотя, провёл эксперимент со своей базой лайков. Дамп всего содержимого одной таблицы в самом дампе умещается в одну строку, поэтому и гитом воспринимается как изменившийся целиком, так что гит распухает в два раза после добавления в базу хотя бы ещё одного лайка пользователя. Надо писать что-то своё :(
Mac Firefox
 Германия
0
0
karash_l
На самом деле, вполне себе рабочее решение. mysqldump умеет генерировать дампы построчно (каждая запись в таблице - отдельный INSERT отдельной строкой в дампе).

Гугл подсказывает разные флаги:

--extended-insert=FALSE
--opt --skip-extended-insert

В принципе, при желании поиграться можно.
Windows Safari Chrome
 Германия
1
0
Alexandr K
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Точно. Проэкспериментировал на своей базе. У меня, правда, размер базы небольшой - дамп весил около 7 метров. После добавления параметров --opt --skip-extended-insert дамп стал весить 11 метров, но зато разбит на отдельные строки и гит вполне нормально показывает разницу между базами.
Разница в объёме папки с коммитами гита в моём случае при добавлении одного лайка к фоткам (один инсерт и один апдейт строки) прибавляет примерно 2 мегабайта. Причём, пара десятков лайков тоже прибавляют примерно такой же объём. Видимо, это просто размер коммита в моём случае.

Леонид, вполне рабочая схема. Инкрементальней некуда :)
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Ну это тогда средствами движка мне делать надо, так будет правильней. Но пока нет времени.
Linux Ubuntu Firefox
 HavinghastraatDA Alkmaar (The Netherlands)
1
0
Чук


Windows Safari Chrome
 Москва
2
0
vivliofika
очень точное замечание. Я сначала не понял даже, думал, это птичка в подставке... Но потом полёт мысли до меня дошёл
Windows Firefox
 Сумы
0
2
Fisher123
ORACLE поставить уже советовали? Там все работает.
Linux Firefox
 Азербайджан
0
0
morra
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Оракулы жадные, денег хотят :)
Windows Firefox
 Сумы
1
0
Fisher123
Столь же логично можно сказать, что жадные - именно пользователи MySQL: денег платить не хотят.
Linux Firefox
 {#countryname}
1
1
nobody
Что если переделать движок так чтобы он мог писать в несколько баз? Основная база тогда в режиме чтение-запись, запасные - только запись.
Mac Firefox
 Киев
2
0
gul
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Совет не по непосредственному вопросу, а попутно.

Mariadb умеет table partitioning (хранение одной таблицы в нескольких файлах) и table engine "merge". Любым из этих способов большую таблицу комментариев можно разбить по годам или по месяцам, и тогда изменяться будет только один из этих файлов. Дополнительным бонусом будет то, что максимум обращений делается к свежим комментариям, и эта относительно небольшая таблица будет лучше кешироваться, т.е. увеличится эффективность.

Ограничение у partitioning: только innodb, и не поддерживаются foreign keys (их сейчас и нет, потому что myisam). Для "merge" - новые таблицы нужно создавать и подключать явно (скриптом, раз в месяц по крону).

И ещё вариант бекапа - реплика. Она не защитит от случайного удаления информации на мастере, зато в любой момент будет совсем свежий бекап на случай падения основного сервера. Можно делать реплику с задержкой, скажем, час - для защиты от ручных ошибок. И дамп, кстати, лучше делать уже с реплики, чтобы не грузить этим мастер.
Windows Firefox
 Москва
1
0
Некто7
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
partitioning работает НЕ только для innodb
Mac Firefox
 Дания
0
0
HowToRegister
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Попробуйте restic - он сохраняет файлы по частям и прямо заточен на сохранение только изменившейся части файла.
Linux Safari Chrome
 Молдова
0
0
Кирилл Цуканов
Советую попробовать borg (https://github.com/borgbackup/borg). Да, он занимается инкрементальным бэкапом именно файлов, но: каждый файл он режет на небольшие куски, каждый кусок хеширует и хранит только один раз. Эффективность будет сильно зависить от того, как часто и в каких местах меняется файл базы данных, так что я не гарантирую, что это будет очень супер-эффективно, но попробовать стоит
Linux Ubuntu Firefox
 Москва
0
0
Adamos
Разве не то же самое сто лет как делает штатный rsync?
Mac Firefox
 Дания
0
0
HowToRegister
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Нет, rsync целиком файлы передаёт.
Linux Safari Chrome
 Санкт-Петербург
1
0
LLeo
Друзья, я честно сказать, не вижу в этом смысла. Достаточно добавить один бит или байт начало 3-гигабайтного файла, и вот он уже другой весь, всеми своими блоками, с точки зрения всех этих файловых утилит. А что делает MySQL со своими бинарными файлами мы не знаем.
Mac Firefox
 Дания
1
0
HowToRegister
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
А вы попробуйте! Ситуация, когда добавился байтик в начало файла и все блоки съехали возможная, но чисто умозрительная. В подавляющем большинстве случаев MySQL будет менять именно небольшие блоки в файлах, оставляя все прочие блоки без изменений на своих местах.
Linux Firefox
 Кемерово
0
0
Аноним937471
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Вы просто немного не в курсе. В современных средствах бэкапа используются rolling hash и на нём основанный content-defined chunking.
https://restic.net/blog/2015-09-12/restic-foundation1-cdc
Кратко: если добавить/удалить байт в начале файла, надо будет перебэкапить единственный блок из начала файла, потому что блоки не фиксированной длины, а нарезаются с учётом содержимого.
Mac Firefox
 Киев
0
0
gul
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
rsync смотрит по блокам (по умолчанию).

"It is famous for its delta-transfer algorithm, which reduces the amount of data sent over the network by sending only the differences between the source files and the existing files in the destination".
Mac Firefox
 Дания
0
0
HowToRegister
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Очень похоже на restic. Но restic умеет ещё и пользоваться S3/BackBlaze и другими cloud-сервисами в качестве хранилища.
Linux Safari Chrome
 Молдова
0
0
Кирилл Цуканов
Да, вы правы: похоже, restic работает по схожему принципу и у него куда больше функционала. Я просто для домашнего бэкапа использую borg, а детальнее вопрос не исследовал
Windows Safari Chrome
 Мытищи
0
1
2:5020/321
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Напрашивается мысль, иметь вторую базу данных. То есть чтобы плюсик вносил изменение сразу в две базы.
Linux Safari Chrome
 Санкт-Петербург
1
0
LLeo
Честно говоря, для плюсиков у меня вообще отдельная база с историческим названием dnevnik_plusiki, но суть не в этом.
Linux Safari Chrome
 New York
1
0
Кто здесь?
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Что-то тут не то.

NGINX прекрасно работает с любыми каталогами, указанными в
конфиге. Зачем непременно /home/www ? Какая религия мешает указать сразу смонтированный диск?

Mysql прекрасно работает с любыми каталогами, указанными в конфиге. Зачем симлинки? Что мешает указать сразу смонтированный диск?

И наконец, MyISAM прекрасно работает с разными версиями Mysql.
А вот когда после пары апгрейдов сервера mysql вы попробуете восстановить бекап в InnoDB от предыдущей версии - вот это будет секас...

А, ну и конечно, если плюсик к каменту приводит к обновлению 20-гиговой таблицы - надо пересмотреть структуру своих таблиц...
Mac Safari Chrome
 Днепропетровск
0
0
nick.c
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
rdiff-backup
Windows Firefox
 Молдова
0
0
DuplicacyMarketing
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Вижу, что вам не нужен бэкап файлов, но не вижу каких-то доказательств, что ваша БД имеет обыкновение дописывать байты в начало файла, смещая файл целиком.

В свою очередь хочу порекомендовать duplicacy - он дедуплицирует и хеширует данные, т.е. если в гигабайтный файл дописать байт с конца, он отошлёт только последний блок.
Чем лучше других: он из коробки поддерживает кучу облачных сервисов, консольная версия бесплатна.
И по моим наблюдениям, он очень надёжен.
Windows Safari Chrome
 Челябинск
5
0
vinny-the-poo
Ну,теперь, когда всё благополучно разрешилось, можно и позубоскалить.

— Вставай, Лёня, мы там всё уронили. Мы уронили вообще всё, честно.
Windows Firefox
 Израиль
3
0
braintunic
> mysql очень не любят, когда их данные хранят не в /home/www, где они привыкли. И симлинк тоже не устраивает капризного mysql. Поэтому единственный способ вынести базы и сайты в корневую папку — это монтировать ее как bind в /home/www Поэтому у меня в fstab всегда было написано: «/home/www /R none bind 0 0»

Я таки вспомнил, где я уже видел этот самый bind-mount, эту самую строчку в fstab.
Вот оно, год назад! :




Самое смешное: тогда, год назад, ты жаловался, что mysql категорически отказывается работать с /home/www и нужны были дикие пляски с бубном, чтобы его заставить.
А сегодня, ровно наоборот, ты утверждаешь, что mysql привык работать только с /home/www и нужны новые пляски с бубном, чтобы его от этого отучить!

> Оказалось, «/home/www /R none bind 0 0» конечно монтирует первое во второе, поэтому вместо /R появилась пустая /home/www, а его реальное содержимое стало невидимым. Правильно наоборот: «/R /home/www none bind 0 0» Но блин, остается страшной загадкой, как оно у меня работало все это время — полгода, год?

Ну, можно представить несколько сценариев, как это случилось.
Скорее всего, где-то в промежутке между маем 2019 и июнем 2020 ты перенес физическую базу данных с /home/www в /R, вручную перемонтировав файловые системы, но забыв поправить fstab, и не делая reboot.
А может быть, ты поправил fstab, но он по какой-то причине восстановился с прежней копии (был апгрейд операционки?)

В любом случае, как я уже говорил, есть возможность поизучать syslog и выяснить, что же произошло в реальности (и это может спасти в будущем).
Но я подозреваю, что ты не воспользуешься такой возможностью ;)
Linux Ubuntu Firefox
 Санкт-Петербург
1
0
LLeo
Да, именно так - ошибочная строчка была в fstab с самого начала, но почему-то все работало. Конечно я перегружался за эти месяцы неоднократно.

Как именно искать в syslog даты перезагрузок, я, право, не знаю. Он огромен, там рядом еще его запакованные архивы во множестве. Мне было лень разбираться. Если напишете, как посмотреть по syslog и всем его архивам - посмотрю.
Linux Safari Chrome
 Израиль
0
0
braintunic
А какая там операционка?
Ubuntu? CentOS? Что-то другое?

Можешь сделать 'ls -lR /var/log' и положить результат в доступный текстовый файл?
Linux Ubuntu Firefox
 Санкт-Петербург
0
0
LLeo
Ubuntu
Windows Firefox
 Fremont
0
0
Korj
Например:
sudo zgrep "Linux version" /var/log/syslog.*.gz
Linux Safari Chrome
 New York
0
0
Кто здесь?
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Но зачем такое шаманство?

Указать в конфиге datadir = /DatabaseVolume и не париться.

У меня все работает (с)
Включая докеры, где смонтированный раздел может быть вообще чем угодно, от файла до удаленной корзины по ISCSI
Mac Safari
 Великобритания
1
1
Яссир
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Неужели не проще просто все вынести в public cloud типа Aws где бэкапы сами делаются и никогда больше не заморачиваться такой херней
Linux Ubuntu Firefox
 Санкт-Петербург
5
0
LLeo
Mac Safari Chrome
 Washington
1
0
Гена
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
> [фотка с Шариковым и Преображенским]

Интересно, что одинаково хорошо работает в обе стороны, и обе стороны убеждены, что уж оне-то уж точно не Шариков
Mac Safari
 Великобритания
1
2
Яссир
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Какой убойный аргумент! Спасибо, все понял теперь. Приятного времяпровождения с бубном:)
Linux Ubuntu Firefox
 Одесса
0
0
crispoid
Ну, не знаю, мы люди простые. Мой 1С-сервер по крону раз в день (в 3 утра) делает zip -r /...`date "+%Y-%m-%d-%H-%M"`.zip для папки с базой, после чего шлет архив на другой сервер. Не вижу, почему бы удаленный хостинговый сервер не мог делать то же самое с /var/lib/mysql/ или где оно там у вас лежит.
Хотя если так критичны плюсики за последние 40 минут, то да, надо заморачиваться.
Windows Firefox
 Москва
0
0
sirlexx
Тоже не могу не поделиться опытом, была когда-то задача сделать простой бэкап файлов и базы таким образом, чтобы в итоге получались обычный файлы с инкрементальными изменениями, которые можно раскидывать обычными средствами

В итоге с нативным инкрементальным бэкапом как-то странно получалось, и в части БД такая конструкция получилась
Работает много лет уже, база 3.5 гига, полёт нормальный, несколько раз делал тестовое восстановление

[ -f "db-all-bak.sql" ] && mv "db-all-bak.sql" "db-all-bak.sql.old"
/usr/local/bin/mysqldump --defaults-extra-file=${mycnf} --skip-extended-insert -q --all-databases > "db-all-bak.sql"
if [ -f "db-all-bak.sql.old" ] ; then
diff "db-all-bak.sql.old" "db-all-bak.sql" > "db-all-bak-$dt.diff"
[ -s "db-all-bak-$dt.diff" ] && /usr/local/bin/7z a -bd -p${pass} -mx=5 "${back}/db-all-bak-${dt}.diff.7z" "db-all-bak-$dt.diff" >/dev/null
[ -f "db-all-bak-$dt.diff" ] && rm "db-all-bak-$dt.diff"
else
/usr/local/bin/7z a -bd -p${pass} -mx=5 ${back}/db-all-bak-$dt.sql.7z db-all-bak.sql >/dev/null
fi
Mac Safari Chrome
 Нижний Новгород
1
0
tartaglia
При работе с базами нужно избегать лишнего креатива. Это понимание ко мне пришло при знакомстве с Ruby/Rails, точнее, с ActiveState.

В каждой таблице должны быть поля created_at и updated_at, содержание их определяется названием.

В MySQL поле updated_at может быть задано с MySQL-типом TIMESTAMP, тогда движок сам будет обновлять это поле при каждом изменении записи.

Поле updated_at может также изменяться используемым фреймворком. Если вы используете фреймворк, но SQL-запросы формируете сами в текстовом виде, то вы ни черта не поняли в своем фреймворке.

Поле updated_at позволяет легко запрограммировать минимальный инкрементальный бакуп или инкрементальную синхронизацию таблиц.

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

Каждая таблица должна содержать числовое поле id, и только это поле должно использоваться при ссылке на записи таблицы. Это же поле должно быть первичным уникальным индексом таблицы. (MySQL и Oracle позволяют автоматически заполнять такое поле при добавлении записей.)

Если таблица содержит сведения о юзерах, она должна называться users. Поля ссылок на записи этой таблицы из других таблиц должны называться user_id и ссылаться на поле id таблицы users.

При соблюдении этих ограничений многие программные продукты поймут структуру вашей базы автоматически.

А вы сами сможете не отвлекаться на ненужный креатив и сосредоточиться на более существенных вещах.
Linux Safari Chrome
 Санкт-Петербург
0
0
LLeo
Совершенно с вами согласен. Но почему вы мне это не объяснили сразу в 2000 году? :)
Linux Safari Chrome
 Москва
0
0
Стeпан
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Это все прописные истины, известные задолго до 2000 года. То что кто-то гордится изобретением велосипедов, поплевывая через губу пишет "Не люблю использовать шаблоны, конструкторы и типовые решения", как раз и приводит к таким вот проблемам.
Linux Safari Chrome
 Москва
0
1
LLeo
Ой, обиженки прибежали :)

Если вы в 2000 только пошли в школу, ваше высказывание смешно.

Если вы в 2000 уже профессионально работали с базами данных MySQL - вдвойне смешно, когда профессионал с 20-летним стажем пытается учить писателя-фантаста, какие тому использовать фреймворки в качестве домашнего хобби, причем делает это посредством его же движка :) Вы же мой программный продукт используете, а не я ваш ;)
Linux Safari Chrome
 Якутск
2
0
Стeпан
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Кхм. Даже не ожидал что тривиальное замечание настолько заденет. Настолько все плохо? Не в первый раз наступаете на грабли? Ну хотя да, много же было заметок про это тут.

Но не переживайте, с говнокодом тоже живут. Мы вас любим совсем не за навыки в области IT.

всего комментариев: 124

<< предыдущая заметка следующая заметка >>