Можно ли обойти ограничение на MySQL Azure?

Question

Я использую Azure MySQL версию 5.6

Когда я пытаюсь импортировать большой файл дампа MySQL из среды linux в PaaS Azure (Azure База данных для серверов MySQL) с помощью этой команды:

pv DBFILE. sql | mysql -u username@mysqlserver -h mysqlservername. mysql .database. azure .com -pPassword DBNAME

Я получаю это сообщение:

«Размер данных BLOB / TEXT, вставленных в одну транзакцию, превышает 10% размера журнала повторного выполнения. Увеличьте размер журнала повторного выполнения с помощью innodb_log_file_size.»

Есть ли способ обойти эту ошибку?

Я читал в документации Microsoft , что "innodb_log_file_size" не настраивается. Могу ли я разделить этот большой файл дампа на более мелкие и импортировать их все вместе? Какая разница?

Answer 1

Размер файла дампа не проблема. Это не поможет разделить его.

Проблема в том, что размер одного значения BLOB или TEXT хотя бы в одной строке больше 1/10 размера файла журнала innodb. Вы не можете разделить данные так, чтобы они были меньше одного значения BLOB или TEXT.

Согласно документации Azure, на которую вы ссылаетесь, значение innodb_log_file_size фиксировано и составляет 256 МБ. Это означает, что вы не можете импортировать строку со значением BLOB или TEXT более 25,6 МБ. По крайней мере, вы не можете импортировать его в таблицу InnoDB.

Причина в том, что файл журнала повторного выполнения имеет фиксированный размер, а размер файла журнала создает ограничение на количество измененных страниц в Пул буферов InnoDB (но не один к одному, потому что формат записей файла журнала повторного выполнения не такой, как у страниц в пуле буферов). Это своего рода произвольное соотношение, но цель ограничения значений BLOB / TEXT заключается в том, чтобы избежать обертывания гигантского BLOB-объекта и перезаписи его части в небольшом журнале повторов, что оставит сервер MySQL в состоянии, которое не смог восстановиться из кра sh. В MySQL 5.5 это был всего лишь рекомендуемый предел. В MySQL 5.6 это стало обязательным для InnoDB, поэтому INSERT слишком большого BLOB-объекта или ТЕКСТА просто приводил к ошибке.

В Amazon RDS раньше было такое же ограничение лет go . Они поддерживали только фиксированный размер innodb_log_file_size, напомню, что это было 128 МБ. Это было невозможно настроить.

Я был на мероприятии AWS лет go в Сан-Франциско, и я нашел возможность поговорить с менеджером по продукту Amazon RDS в холле между сеансами. Я дал ему обратную связь, что оставление этого параметра на относительно маленьком значении без возможности его увеличения было слишком ограничивающим. Это означало, что можно было вставить только BLOB / TEXT размером 12,8 МБ или меньше.

Я уверен, что я был не единственным клиентом, который дал ему такой отзыв. Несколько месяцев спустя обновление RDS позволило изменить эту переменную. Но вы должны перезапустить экземпляр MySQL, чтобы применить изменения, как если бы вы запускали MySQL самостоятельно.

Я уверен, что Azure обнаружит то же самое и получит много отзывов. от своих клиентов.