Вместо использования интерфейса командной строки / пользовательского интерфейса AWS для Создайте реплику для чтения, я хотел бы создать экземпляр БД с "достаточно близкой" схемой и УСТАНАВЛИВАТЬ это будет реплика.
Мне нужно изменить схему (изменить параметры сортировки), что невозможно сделать в MySQL. Я хотел бы внести это изменение, создав «реплику» для чтения с изменением схемы, а затем продвинуть «реплику» только для чтения.
Проблема в том, что для механизма чтения-реплики MySQL AWS RDS требуется, чтобы две схемы были точными.
Я знаю, что это вообще можно сделать в MySQL (хотя я не знаю специфики); Я хотел бы сделать это полностью в рамках AWS RDS.
Проблема в том, что для механизма чтения-реплики MySQL AWS RDS требуется, чтобы две схемы были точными.
Репликация, как правило, этого требует.
Но если ваше определение «достаточно близко» действительно достаточно близко, это можно сделать в RDS для MySQL так же, как вы всегда это делаете.
создать экземпляр БД ... и УСТАНОВИТЬ его как реплику.
Что ж, ты так не будешь делать.
И за пределами RDS это тоже не так. Вы всегда должны начинать с идентичной реплики, а затем изменять ее, потому что репликация по определению полагается на известный, конкретный момент времени, когда наборы данных, а также схемы идентичны, после чего изменения становятся возможными в той степени, в которой MySQL действительно учитывает их «достаточно близко».
Примеры «достаточно близко» могут включать реплику с большим или меньшим количеством индексов ... но, очевидно, не такие вещи, как новый уникальный ключ или ограничение внешнего ключа на реплике, где данные на главном сервере нарушают ограничение ... и изменение сопоставления может привести к нарушению существующего ограничения без фактического изменения данных. (Или нет, если вы перешли с без учета регистра на двоичный).
Добавление таблиц в реплику - это нормально, удаление таблиц - нет, и даже можно добавлять столбцы или удалять столбцы из таблиц, если и только если остальные столбцы по порядковому номеру, начиная с первого столбца, идентичны. То есть вы можете добавлять или удалять столбцы с правого края таблицы; вы не можете изменить порядок столбцов, но вы можете изменить типы данных, если возможно принуждение, например, увеличение длины VARCHAR. Вы можете переименовывать столбцы до тех пор, пока BINLOG_FORMAT на мастере установлен на ROW, который часто будет лучшим выбором при попытке внести такие изменения. В случае RDS единственной альтернативой является MIXED. Они мудро предотвращают строго STATEMENTрепликация на основе. Обратите внимание, что BINLOG_FORMAT на реплике не имеет отношения к рабской конверсии.
MySQL обычно пытается неявно выполнять преобразование типов во время репликации. Смотрите также Репликация с разными определениями таблиц на ведущем и ведомом для общей точки зрения MySQL на это.
Вам действительно может сойти с рук то, что вы планируете. Если нет, вы должны выяснить это довольно быстро.
Но, по крайней мере, с RDS достаточно легко попробовать еще раз, если вы сломаете его ... и целостность и производительность мастера не зависят от сломанной реплики.
Вот ваше исправление:
Реплики чтения предназначены для поддержки запросов на чтение, но вам могут потребоваться периодические обновления, такие как добавление индекса для ускорения доступа к реплике определенных типов запросов. Вы можете включить обновления, установив
read_onlyзначение 0 в группе параметров БД для реплики чтения.http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.MySQL
Если это ваша единственная реплика, обязательно скопируйте группу параметров в новую, примените ее к реплике, а затем измените настройку новой группы. Оставление других реплик доступными для записи в качестве побочного эффекта - рецепт для неприятностей.
Как только это будет сделано и вступит в силу, реплика станет доступной для записи. Если предложенные вами изменения действительно «достаточно близки», то после того, как вы войдете в реплику напрямую, используя те же учетные данные, которые вы использовали бы для мастера, и внесете свои изменения, реплика будет продолжена.
Или, если нет, репликация сломается.
Нет необходимости приостанавливать репликацию при изменении схемы реплики, потому что MySQL автоматически приостанавливает выполнение событий репликации, используя обычные механизмы блокировки (например, блокировки метаданных таблицы), пока выполняются операции DDL на реплике с объектами, для которых следующая репликация событие требует доступа.
В SHOW SLAVE STATUS Оператор работает идентично стандартному MySQL в RDS. Если Slave_IO_Running и Slave_SQL_Running оба показывают Yes и Seconds_Behind_Master не является NULL тогда реплика не сломана; если Seconds_Behind_Master = 0, то реплика синхронизируется с мастером в реальном времени (> 0 означает, что реплика отстает, пытается наверстать упущенное).
Вопрос: вызовет ли изменение loooonngggg (повторный сбор столбца порядка часа) проблемы на главном сервере? Я имею в виду журналы репликации с массивным резервным копированием и час трафика, заблокированный блокировкой в реплике только для чтения.
Это не будет проблемой с RDS по двум причинам.
Самая важная причина заключается в том, что репликация MySQL использует два потока - один для получения журналов от главного (поток ввода-вывода), а другой для их выполнения (поток SQL) - это потоки, статус «выполнения» которых I упомянутое выше. Когда реплика блокирует выполнение событий из-за локальных изменений, она продолжает их получать. До тех пор, пока реплике не закончится хранилище, все будет продолжаться должным образом после снятия блокировок.
Кроме того, хотя это и не имеет большого значения в этом контексте, поскольку поток ввода-вывода будет продолжать работать, RDS не использует стандартный expire_logs_days системная переменная, чтобы удалить старые бинлоги из главного. Вместо этого он сам очищает их - как только они не понадобятся ни одной из ваших реплик, но не раньше - полезно, поскольку они учитываются при распределении вашего хранилища. (Вы также можете настройте RDS, чтобы они оставались там дольше, если хотите). Я полностью остановил репликацию RDS более чем на 24 часа и запустил ее без проблем.