Спасибо
@vadimisakanov и все, кто давал советы - они иногда путали, но иногда помогали. Репликация у меня заработала в docker-compose. Сначала я увидел, что server_id на master задан верно, потом сделал на slave аналогично.
Реляционные БД придумали неглупые люди. Придумали, потому что видели великое множество эпик фэйлов, связанных с неправильным хранением данных. Каждая программа в 60е хранила данные, как умела. Чаще всего - просто бинарный дамп сишных структур. Из-за такого подхода было утеряно большое количество данных на начальном этапе становления компьютер саенса. Когда эту проблему научились решать, поняли, что данные продолжают теряться (или быть недоступными) из-за отсутствия нормализации этих данных. Ведь намного проще сохранить структуру как бинарный блоб, чем вытаскивать каждый тип данных в свою модель и создавать между ними связи. Да, нормализация данных требует мозговых усилий и знания теории. Но это как рефакторинг кода - потратить время, чтобы потом не мучаться.
Когда возникла мода на NoSQL - Google решал конкретную задачу, из-за своих объемов информации они не могли справиться стандартными решениями. Вот и сделали свой аналог сишных структур данных, только размазанных по куче компов. Народ радостно это дело подхватил и начал юзать. Замечательно. Так же, как и удобно использовать сишные структуры и их бинарный дамп на диск в виде файла. Прикрутили фэйловеры, шардинг, еще много чего. Только рано или поздно все равно придут к тому, что данные надо нормализовать. Особенно это актуально в облаках, где неэффективные способы работы с данными напрямую бьют по кошелькам. Именно поэтому тот же Google создал Spanner, и другие nosql продукты начинают двигаться в сторону структурированных данных (следующим шагом будет реляционность и потом - нормализация).
Все ИМХО ;)