Vitaly Karasik

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

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

А если хочется все это автоматически с удобный GUI - использовать DBaaS (AWS RDS, Aiven и т.п.)

Платно https://www.devart.com/dbforge/mysql/studio/mysql-...

Бесплатно https://docs.percona.com/percona-toolkit/pt-table-...

Первый способ правильный. Два нюанса:
- по дороге можно очищать секретные\приватные данные
- миграции - что делаем когда на деве другая версия?

- Я советую остаться с MariaDB. Понятно, что можно разобраться и подрихтовать дампы вручную (вряд ли автоматичес ки), но зачем?
- Или же создать новый дамп с ключом "--compatible=mysql" https://mariadb.com/kb/en/mariadb-dumpmysqldump/#m...

Только временно (год) бесплатные VM в AWS/GCP и других облаках, но это нетривиально если нет опыта.

Вы проверяли время выполнения запросов и увидели что оно увеличилось?
Я совсем не уверен что различия в пинге имеют значение. (Кстати о пинге - проверил сейчас в Амазоне - 0.2 мс)
Апликация и база в одной сети? Какие ресурсы у базы старой и новой?

Лучший вариант - DBaaS в том же облаке в том же регионе. Я не знаю, как с Яндексом и Селектель, но все "большие" DBaaS (AtlasDB, aiven.io  и т.д.) позволяют выбрать AWS/GCP/Azure.

Возможно есть MyISAM в других, не ваших таблицах. ИМХО это не важно.

1) какое железо и какая конфигурация mysql?
2) Включите slow query log и посмотрите что там

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

UPDATE, после уточнения вопроса:
Как минимум два варианта для локальной базы для разработки:
- поднимать только схему, плюс какие-то тестовые данные
- если хочется реальные данные - сделать скрипт, который каждую ночь (или раз в неделю) берет дамп с сервера, и восстанавливает локально. Если тяжелый - фильтруйте при экспорте, например, только последние данные из тяжелых таблиц.

Советую точнее сформулировать, какую проблему вы хотите решить:
1)

есть боевая бд 100гб и к ней очень медленно летят запросы.. иногда она отваливается.

2)

я хотел бы чтобы у меня была данная бд локально и иногда время от времени обновлять

- зачем? для разработки? для чего-то другого?

3)

в идеале может есть какой то кеш

Посмотрите https://www.percona.com/doc/percona-toolkit/LATEST...

Нужно перенести часть данных (несколько таблиц в базе) из MariaDB в Percona.

ИМХО, идея неправильная. Или же я упустил серьезную причину по которой может понадобиться переносить часть базы на другой сервер на другой движок.
Сделайте PoC на перконе, и если понравится, переносите все.

гипотеза, что можно подключиться к бинлогам,

Направление верное. Стандартная практика для миграции на новый сервер это репликация, а репликация в mysql основана на бинлогах. Так что читать про репликацию (mysql replication).

возможность вернуться обратно на MariaDB

Очень трудно реализовать, т.к. требуется master-master replication.

При добавлении товара на RU он должен быть на BY.

Если только это, и только в одну сторону - то два варианта
- или репликация этой таблицы, как уже советовали. Не очень сложно для опытного сисадмина, непросто для неопытного человека
- экпорт из RU и импорт в BY каждые ХХ минут/часов. Немного проще и надежнее.

Два направления:
1) innodb_flush_log_at_trx_commit=0 или 2 (https://dev.mysql.com/doc/refman/8.0/en/innodb-par...) и прочие базисные настройки
2) bulkinsert как уже сказали и т.п., см. https://medium.com/@benmorel/high-speed-inserts-wi...