Нет — но это и не продакшн — в статье описана stage-среда основанная на реплике от мастер продакшн базы, но которая (реплика) не участвует в бизнес процессах. Поэтому тут важнее не сама остановка, а скорость при остановке и запуске для того чтобы реплика как можно быстрее восстанавливала отставание от мастера.
InnoDB’s background threads continue to work even if you’ve locked all tables, so it
is probably still writing to its files even as you take the snapshot. Also, because InnoDB
hasn’t performed its shutdown sequence, the snapshot’s InnoDB files will look the way
these files would have looked if the server had lost power unexpectedly.
При небольшом объеме подобных данных можно делать сразу после старта реплики на снапшоте обфускацию приватных данных скриптом — но это пока только в планах, и реализация конечная пока не продумана, возможно есть лучше решения.
Спасибо за подробный экспертный комментарий!
п.1 однозначно попробуем
п.2-3 делали по рекомендациям Perconа из вот этой статьи — при замере l2arc в shm особого прироста или регресса не заметил, но решили оставить исходя из рекомендаций.
п.4 попробуем
Да, у нас основная production fs это ext4, не поддерживающия COW, да и основное LTS ядро у нас пока без поддержки reflinks. Интересно было бы посмотреть не просто холодные снапшоты а именно под нагрузкой в 2-3 активных снапшота на одном сервере — возможно cо временем проведем такие эксперименты на xfs на свежем ядре.
п.1 однозначно попробуем
п.2-3 делали по рекомендациям Perconа из вот этой статьи — при замере l2arc в shm особого прироста или регресса не заметил, но решили оставить исходя из рекомендаций.
п.4 попробуем