Vitaly Karasik

Касательно mysql знаю три варианта:

1. Утилита pt-online-schema-change. Создаёт пустую копию исходной таблицы, делает на ней alter, копирует данные из исходной таблицы и в конце меняет местами старую и новую таблицы.

Пользовался этой утилитой пару раз. Хорошо работает.

2. В mysql 5.6 появилась возможность делать alter без блокировок средствами самой субд. Нужно в alter добавить парочку новых параметров:

ALTER TABLE tbl_name ADD PRIMARY KEY (column), ALGORITHM=INPLACE, LOCK=NONE;

Этот вариант я сам не пробовал, поэтому прокомментировать не могу.

3. Самый сложный вариант с использованием двух инстансов mysql, связанных master-master репликацией:

1. Делаем alter на втором сервере
   
2. Ждём, когда второй сервер догонится по репликации
   
3. Переключаем сервис на вторую базу
   
4. Ждем какое-то время, смотрим, нормально ли приложение работает с новой схемой, нет ли деградации или ошибок
   
5. Делаем alter на первой базе
   
6. Ждём догона репликации
   
7. Возвращаем сервис на первую базу
   

С этим вариантом я работаю постоянно. Выглядит просто, но на деле много нюансов.

Нужно обязательно пропускать alter мимо репликации:

SET sql_log_bin = 0;
ALTER TABLE tbl_name ...;

Важно не забыть про sql_log_bin = 0, иначе alter по репликации переедет на соседний сервер и залочит таблицу уже там. А переключать сервис нельзя, пока репликация не догонится.

Если меняется структура таблицы - добавляется/удаляется колонка или меняется их порядок, нужно обязательно проследить чтобы тип репликации обязательно был STATEMENT. Иначе репликация приляжет на первом же запросе в формате ROW с примерно такой странной ошибкой:

Column 25 of table 'mydb.mytable' cannot be converted from type 'varchar(255)' to type 'bigint(20) unsigned'

А со STATEMENT нужно следить чтобы приложение нигде не понижало уровень изоляции ниже REPEATABLE READ, иначе получит ошибку:

Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.

Погуглил:
https://stackoverflow.com/questions/35211716/store...
Кроме того, выдержка из man df:

--output[=FIELD_LIST]
              use the output format defined by FIELD_LIST, or print all fields if FIELD_LIST is omitted.

И далее внизу:

       FIELD_LIST is a comma-separated list of columns to be included.  Valid field names are: 'source', 'fstype', 'itotal', 'iused', 'iavail', 'ipcent', 'size',
       'used', 'avail', 'pcent', 'file' and 'target' (see info page).

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

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

Чтобы восстановить нужную версию инкрементального бакапа, необходимо пройти по всей истории изменений, восстанавливая шаг за шагом. Ваш заказчик должен это понимать либо получит бомбу замедленного действия и невозможность оперативно воспользоваться бакапом (к примеру у вас 100-тб архив, с ежеденевными инкрементальными бакапами, хранящими по паре сотни гигабайт в дифах, чтобы восстановить данные за год архивации, потребуется загрузить с aws порядка трех петабайт данных, понятно делать это лучше внутри самого амазона, так как трафик у них прямо золотой).

Чтобы не хранить и не пробегать по всей истории, каждый раз когда делаешь бакап, нужно обновлять хвостовой (стартовый) сдвигая его на самый старый дифф (и удаляя его).

p.s. убери из требований zip архив (точнее не храни его так, формируй по требованию), тогда резервирование можно оптимизировать на уровне файлов или даже файловой системы (например btrfs позволяет получать диф снапшота на лету в виде файла и вносить эти изменения в другом месте)

Как чисто "наколенный" вариант, использовать:

EC2 инстанс с запускаемым софтом:
1. Монтирование S3 (source, target) в качестве папки: goofys или s3fs.
2. В качестве резервирующего ПО: Bup для дедупликации. Умеет подобно Git...
На входе папка исходного бакета, а на выходе - целевая.

Сам не пробовал. Просто как идея.

Ты веcь такой кругом молодец, то знаешь, это знаешь. А теперь представь себе среднестатистический проект, который должен приносить бизнесу деньги. За две недели работы ты едва напишешь хлипкий CRUD для данных, неправильно смаппив бизнес-сущности в объекты ORM, ещё через месяц натянешь какой-то слайдер на jQ, попутно захватив 2мб JS кривых библиотек, а через два заказчик поставит тебе плохую оценку, потому что твой ценник он оплатил не за то, что ему нужно, а потому что ты знаешь монады, которые ему даром не сдались.

А теперь давай представим простого программиста. Из алгоритмов он с трудом вспоминает сортировку пузырьком, а двусвязный список — предел его знаний о структурах данных, и даже этим списком он пользовался два раза в жизни. Хаскель он никогда не видел в глаза, C++ учил только в школе, вместо этого пишет неэффективный код на PHP. И у него есть опыт. За день он распишет сущности, за второй сделает универсальный CRUD, на третий день поднимет фронт на React'е с SSR. Да, внутренности проекта будут "медленными". Вместо O(logN) что-то будет выполняться за O(N) или даже O(N^2), но всем похер. Пока всё работает на приемлемом уровне — бизнес радуется.

Кстати, к чему эта поучительная лапша? Я хотел сказать, что всеми этими модными словами можно пугать друзей и преподавателей, но в реальной жизни все алгоритмы уже реализованы, все типы данных уже подобраны оптимально. Знать их полезно для себя (чтобы мозг не атрофировался), но не для работы. Для работы тебе нужны такие навыки как:

* Оптимальный баланс между говнокодом и идеальным кодом
* Оптимальный баланс между скоростью разработки и оптимизацией кода
* Оптимальный баланс между поддерживаемым кодом и костылями
* Умение использовать те инструменты, с которыми ты работаешь. Опять же, для того, чтобы писать быстро, при этом имея минимальное количество говнокода и обеспечивая максимальную поддерживаемость (в пределах сроков). Например, можешь выкинуть в помойку свой Vim, как бы круто ты себя не чувствовал, разрабатывая в консольном редакторе, если продукты от JetBrains позволят за это же время сделать что-то лучше или чего-то больше
* Чувство "знаю больше менеджеров". Это то чувство, когда тебе кажется, что "вот эта фича скоро изменится" и надо сделать архитектуру заранее более гибкой. Или "вот эту фичу мы через месяц выпилим" и не надо тратить на неё силы — напиши костыль и через месяц с чистой совестью удали его
* Знания, как сделать ту или иную фичу. Потому что фичи повторяются (немного видоизменяясь) от проекта к проекту. И если ты сделал что-то за два дня, в следующий раз ты похожее сделаешь за три часа

Что касается инструментов, выбери любой полноценный фреймворк, который умеет решать 90%+ потребностей "из коробки": Symfony, Django, Laravel

Всякие "минималистичные" поделия вроде Falcon, Flask (в PHP не знаю, я на питоне пишу) оставь хипстерам. Пусть они говорят: "Мой фалкон такой быстрый, он написан на Cython". Тебя это не должно волновать, потому что бизнес с твоей скоростью разработки уже заработал достаточно денег, чтобы купить ещё десять серверов, пока фалконисты неделю гуглили, как прикрутить миграциии и запустить юнит-тесты на VPSке за пять баксов.

Есть, но я бы не сказала, что много. И нужно как-то подтверждать квалификацию. Иначе вам предложат только место помощника вроде клавиатурной обезьяны. Типа не анализировать данные, а лазить собирать...
Вы бы лучше по фриланс-сайтам и полазили, чем тут спрашивать. Кстати, навыки анализа как раз пригодятся. Смотрите два направления:

1. Лента проектов. Очень часто выполненный проект не закрывается, а так и продолжает висеть. То есть вы можете отматывать ленту и на месяц, и на полгода... И смотреть, кого там ищут.
   
2. Каталог фрилансеров. Выбираете интересующее вас направление, смотрите, какие у аналитиков навыки, как они опсываются, за что этих людей благодарят в отзывах. И чего лежит в их портфолио.
   

Профит.

Нужно понимать принципиальную разницу подхода:

apt - установка из маленьких пакетов, вместе образующих большую и сложную систему, при этом софт может массово совместно использовать одни и те же файлы и библиотеки, благодаря чему экономится место на диске, оперативная память итд итп. Надо понимать, что apt - это пакетный менеджер для определённого вида пакетов (deb), хотя в своё время существовал вариант для rpm (может и сейчас существует, просто смысла в нём мало после появления yum).

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

snap по большому счёту часто используют для установки тяжёлых приложений, которые может бысть сложно опакетить, особенно учитывая разнообразие присутствующих в мире дистрибутивов (debian/ubuntu и их клоны) разных версий. В то время как большинство штатного общеиспользуемого софта чаще распространяют в виде пакетов, идущих в составе дистрибутива или отдельно (в том числе в виде разных собранных под разные варианты систем пакетов).

В общем победил...

Дело было во флаге -T к команде docker-compose exec

Для чего этот флаг читаем документацию.

В итоге команда такая:

*/5 * * * * cd /home/USER/ && /usr/local/bin/docker-compose -f prod-compose.yml exec -T mariadb /usr/bin/mysqldump -u USER -pPASSWORD --single-transaction DB_NAME | gzip > /home/USER/BACKUP/DB.sql.tar.gz

P.S.: Переход через cd обязателен...иначе не поедет...в случае, если в compose.yml пути везде относительные...а обычно так и есть...

Один из возможных вариантов:

select 
	* ,
	case 
		when role = 'boss' then 3
		when role = 'admin' then 2
		else 1
	end as weight
from gamers order by weight desc;

MySQL fiddle

или так:

select * 
from gamers 
order by role = 'boss' desc, role = 'admin' desc;

MariaDB fiddle

Это везде проблема где бизнес не имеет компетенции и ищет сотрудников. Это нормально