Довольный Айтишникъ

Я бы не рекомендовал этого делать.
У меня была такая же ситуация и я консультировался в своём банке. Сказали, что деньги придут от "Transferwise", соответственно у вас должны быть документы объясняющие происхождение денег для валютного контроля. Но у вас есть только договор с вашим заказчиком, а не с "Transferwise". Поэтому с валютным контролем может быть проблема.

Лучше не экономьте, а делайте обычный SWIFT-перевод напрямую от вашего заказчика вам. Для валютного контроля вам потребуется договор (с версией на русском) и акт/счёт на каждое поступление. Ничего сложного. Важно, чтобы в договоре были те же реквизиты с которых и на которые будет сделан перевод. Также желательно, чтобы перевод осуществлялся от юрлица, а не от физлица т.к. во втором случае де-юре вы обязаны выбить чек через онлайн-кассу.
Вся эта морока имеет смысл, если сумма достаточно большая (от $1000 хотя бы). Меньше - нет смысла. Проще через PayPal тогда сделать, можно вообще нелегально без всяких документов.

140 гб SSD это очень маленький объем. В вашем случае наверное выгоднее будет взять 8 гб озу, и накопить на хотя бы 256 гб SSD

Вы не указали самого главного - как клиентские машины получают свои адреса. Если через DHCP, значит надо смотреть настройки DHCP-сервера. Если адреса прописаны статически, значит обходить все клиентские машины и менять настройки руками.

Прям совсем с нуля, или вы за эти 12 лет какие-то успешные шаги сделали?

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

Самое важное: начните писать код прямо сейчас. Пусть это будет простенький hello world, или тупые и неэффективные решения задачки про 99 бутылок, пусть хоть самый ужасный говнокод, но это бесконечно лучше, чем вообще никакого.

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

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

Пусть это будет как "фоновое" чтение, может даже получится читать эти книги для развлечения. Никаких мгновенных преимуществ в программировании они не дадут, но однажды вы можете заметить, что понимаете ПОЧЕМУ одни алгоритмы работают быстрее других.

Для быстрого погружения в кодинг попробуйте пройти colobot, например. Он довольно легкий, ориентирован для детей. С интернете полно подсказок и готовых решений, но не стоит ими злоупортеблять и копировать код без понимания его работы.

Потом можно переключиться на codewars, делать по одной задачке в день, например. Сравнивать свое решение с решениями других людей.

Вот вам еще один список: Карта развития веб-разработчика
Здесь уже не только неустаревающие знания, но неплохо бы потратить на каждую из этих тем хоть по 10 минут, чтоб понимать о чем речь. Конечно, для нормальной работы на многие из этих тем придется потратит намного больше времени.

Pixabay, Unsplash, Pexels - этих трёх как правило хватает.

Если нет, лезу в настройки гугл-картинок, там можно уточнять тип лицензии.

С URL параметрами директивы location в nginx не работают.

Можно попробовать так:

location ^/index\.php$ {
   if ($query_string ~ "r=test") {
     proxy_pass ...
   }
   ...
}

Мультимастер СУБД - это такая замечательная штука, которую все хотят и ни у кого пока не получилось.
Потому что есть такая штука как CAP теорема, весьма мешающая сделать серебряную пулю.

Ладно, ближе к делу.
Самая большая проблема с автоматическим failover СУБД - решить, что уже пора переключаться. Для чего необходимо выяснить, а что вообще происходит, не развалилась ли сеть, не вернётся ли через пару секунд мастер обратно - если в сети в результате окажется два мастера, то нет никакого разумного способа определить, где данные актуальны. Худшее что можно представить - это split brain: когда часть приложений ходит в один мастер, часть в другой и данные стремительно расходятся в разные стороны. Есть такая байка про гуглдиск "у нас всё отказоустойчиво, все данные хранятся в 4 экземплярах. Правда, у нас была авария и мы теперь понятий не имеем, какая из копий актуальная"
Переключение мастера на 90% - решение административное и человеческое. Автоматика же добавляет головной боли. Зачастую - больше головной боли, чем без неё. Особенно если железо адекватное серверное, которое "вдруг" выпадает очень редко.

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

Если всё ещё хочется походить по граблям - посмотрите patroni. Есть пара кластеров с ним на поддержке, при наличии мониторинга особых проблем не припоминаю. До split brain по крайней мере не придумал как довести, вроде все варианты прикрыты. В худшем случае в readonly уходит.

Частота памяти может только тешить самолюбие в тестах. В обычной работе разницу на глаз просто не заметить, и разгон не имеет смысла.
Больше толку будет от ещё одной плашки во 2-ом канале.

Если на вашей https-странице просто указаны ссылки на http, то страница будет безопасной. Вот я привожу ссылку, значок на этой странице никуда не исчез.
Если же по http подгружаются какие-либо элементы страницы, то она, естественно, будет небезопасной. В этом случае надо либо искать https-аналоги этих ресурсов, либо загружать их через свой сервер, используя https между браузером и сервером, а http уже между сервером и ресурсом.