Andrey Shatokhin

Да сломали. Слейвы хотят кусок бинлога которого нет на новом мастере.
Чтобы работали такие цепочки репликации нужно включать log_slave_update на промежуточных серверах. Так в промежутках будут полные бинлоги. А сейчас на новом мастере есть только свои бинлоги, но в Executed_Gtid_Set есть куски от старого мастера, которых нет на старых слейвах. Вот их они и хотят. Сравните Executed_Gtid_Set на всех серверах.

У вас включены GTID поэтому ID сервера не влияет на бинлог. Бинлог подписывается Master_UUID, который генерируется автоматически.

NVME Дает большую скорость при больших IOPS. А для этого надо что бы софт асинхронно/многопоточно с блочным устройством.
Обычно IOPS большой у софта которую есть дело до скорости работы с диском. Остальные не заморачиваются и читают синхронно. Само чтение у них быстрое, но ожидания, блокировки на чтение/запись и тд занимают время.

grep "^Be" city.txt | sed 's/ //g' | xargs touch

Задержки меньше когда все на одном кристалле. Перенос контроллера памяти в процессор имеет ту же причину.

Я бы не использовал. По причини боли при мажорных обновлениях. А они бывают не редко.
1. Нужно переиндексировать все индексы в актуальную версию перед обновлением на следующую. (reindex api спасает, но все равно не приятно делать на горячей бд)
2. В мажорных обновлениях часто меняют типизацию. В NoSQL с нестрогой типизацией это всегда неожиданно.
3. Бекапы старых версий не развернуть на новых. Бекап с возрастом в пару лет становится тыквой прям по определению.
4. Проблемы производительности если хранить много лишних данных в индексах. (Кушает память на весь документ, а не только на нужные поля - часто срабатывает gc, который кушает проц. Уменьшается эффективность кеша)
5. И главное. Он асинхронный. т.е запись в выдаче появляется не сразу. Это иногда приводит к сложностям в коде

Да. Можите на бекенде добавить заголовок X-Accel-Expires и в нем время кеширования. fastcgi_cache_valid при этом игнорируется. док

Киньте его на рабочий стол или в документы. А их в icloud. Ну или в любое другое облако.
А вместо файла один раз создайте симлинк на оригинал.

Есть же Change Streams
Примеры для python есть в документации

Обновление не индексиуремых полей в одной строке и выборкой по primary key - будет очень быстрым и легким.

Если надо ftp - гуглите "iptables passive ftp"

А лучше мигруйте на sftp.

Не плодите лишние микросервисы. Вам же будет сложней в отладке и тестировании.
По Вашему вопросу - плохая практика использовать одну бд в разных микросервисах.

Внутри $GOPATH создаются src, bin, pkg. Т.е сделайте GOPATH=/var/www/go

А вообще завязывайте с $GOPATH и переходите на модули

HLS трансляция - это же динамический плейлист и статичные видео чанки. Чанки вполне можно отдавать через cdn.
Если геоцдн не нужен, а нужна только ширина канала - то можите просто поднять еще несколько новых проксирующих серверов на hetzner cloud.

В идеале - вам бы kubernetus+prometheus(ну или любые их аналоги) и в них все эти проксирующие зеркала поднимать по факту нагрузки на канал. Зеркала же stateless.