Cloud DB - Есть вопросы

[Privet]

Для целей дублирования хотел бы завести себе где-нибудь cloud MySQL db. Предполагаю настроить репликацию на БД форума и не париться больше со вторым локальным сервером.
Пытаюсь определить во сколько это мне обойдётся, но сразу упёрся в несколько непоняток.

1. Как оценить необходимый объём? Если посмотреть информацию по базе данных, то там показывается приблизительный объём 14.4GB., но по факту, если смотреть суммарно объём всех файлов 19.2GB. Причём, это зависит от предыстории и настроек.
Вопрос:На какой объём мне нужно заказывать БД?

2. Стоимость БД указана в $ за час. Других вариантов я не видел. Цены на Amazon начинаются примерно с $0.3 за час. Вроде не так много. Однако, если посчитать за месяц непрерывной работы, но вылетает уже больше $200.
Вопрос: Какое время имеется в виду? Время пока кто-то залогинился на БД или другое?
Меня пугает тот факт, что по рассеянности я запросто могу забыть отключится. Вот, и будет она мне мотать. По идее, мне часа в неделю при хорошей сети должно хватать, чтобы докатить удалённую ДБ.

3. Может, кто посоветует подобный сервис с относительно демократичными ценами. Нужна MySQL или MariaDB.

[mskmel]

Стоимость БД указана в $ за час. Других вариантов я не видел. Цены на Amazon начинаются примерно с $0.3 за час. Вроде не так много. Однако, если посчитать за месяц непрерывной работы, но вылетает уже больше $200.

"Дешевый" Cloud как есть
GCP дешевле выглядит, но всё-равно дорого: https://cloud.google.com/sql/pricing
Можно включать раз Х минут для синхронизации и выключать.

[mavr]

Для целей дублирования хотел бы завести себе где-нибудь cloud MySQL db. Предполагаю настроить репликацию на БД форума и не париться больше со вторым локальным сервером.
Пытаюсь определить во сколько это мне обойдётся, но сразу упёрся в несколько непоняток.

1. Как оценить необходимый объём? Если посмотреть информацию по базе данных, то там показывается приблизительный объём 14.4GB., но по факту, если смотреть суммарно объём всех файлов 19.2GB. Причём, это зависит от предыстории и настроек.
Вопрос:На какой объём мне нужно заказывать БД?

2. Стоимость БД указана в $ за час. Других вариантов я не видел. Цены на Amazon начинаются примерно с $0.3 за час.

За MySQL начинаются с $0.09 за час

[John Smith]

https://www.ec2instances.info/?filter=large

m5.large если купить reserved выйдет в 6.1 цента в час, базу правда придется развернуть и поддерживать самостоятельно, в отличии от RDS

[mavr]

https://www.ec2instances.info/?filter=large

m5.large если купить reserved выйдет в 6.1 цента в час, базу правда придется развернуть и поддерживать самостоятельно, в отличии от RDS

И базу держим на ephemeral дисках?

[John Smith]

на ebs, 10 центов за гигабайт в месяц (или даже дешевле) + есть возможность делать снэпшоты в s3 по 5 центов за гигабайт в месяц

[John Smith]

я бы поигрался с t2.medium для начала — может его хватит, reserved price будет 2.9 цента в час

[StrangerR]

Я бы тоже, взял свой линукс, все поставил и посмотрел на объемы. Тем паче за трафик В АМАЗОН платить не нужно.

[Privet]

Я бы тоже, взял свой линукс, все поставил и посмотрел на объемы. Тем паче за трафик В АМАЗОН платить не нужно.

Не понял. Вы имеете в виду развернуть виртуальный Линукс на cloud? У меня это уже стоит на Линуксе. Объёмы я вижу. Вопрос только как они считают?

[John Smith]

амазон для ec2 считает либо on-demand - когда инстанс в состоянии running (с точностью до часа), либо reserved - когда цена сразу за год платится за инстансы опрелеленного типа, неважно, запущены они или нет
ebs volumes/snapshots в зависимости от того сколько места занимают, с точностью до минуты - SSD volume на 50 гигабайт обойдется в $5 в месяц

[katit]

Вопрос: Какое время имеется в виду? Время пока кто-то залогинился на БД или другое?
Меня пугает тот факт, что по рассеянности я запросто могу забыть отключится. Вот, и будет она мне мотать. По идее, мне часа в неделю при хорошей сети должно хватать, чтобы докатить удалённую ДБ.

Борис, может для баз по другому (пусть поправят) но с виртуалками там платить надо за час работы. Т.е. если выключить то счетчик не идет. Но я не уверен что вам это подойдет, т.к. получается что надо будет писать скрипт чтобы включать, потом накатывать, потом выключать.

А в итоге какой смысл? С таким же успехом можно просто делать бэкапы в облако. А для этого много вариантов. Я лично дату бэкаплю в Amazon S3 (это просто их storage). Также я использую Crashplan. Стоит он копейки и ставить можно на Линукс что плюс.

[Palych]

с виртуалками там платить надо за час работы. Т.е. если выключить то счетчик не идет.

А можно глупый вопрос?
Они up time считают или CPU time?

[katit]

с виртуалками там платить надо за час работы. Т.е. если выключить то счетчик не идет.

А можно глупый вопрос?
Они up time считают или CPU time?

Кто как, но в случае с Амазоном up time. Т.е. надо запускать виртуалку скриптами/API/руками.

[Privet]

с виртуалками там платить надо за час работы. Т.е. если выключить то счетчик не идет.

А можно глупый вопрос?
Они up time считают или CPU time?

Кто как, но в случае с Амазоном up time. Т.е. надо запускать виртуалку скриптами/API/руками.

А скрипт где работает? У меня на сервере? Т.е. БД запускается удалённо с моего сервера, выполняется какая-то работа и БД гасится?

[katit]

с виртуалками там платить надо за час работы. Т.е. если выключить то счетчик не идет.

А можно глупый вопрос?
Они up time считают или CPU time?

Кто как, но в случае с Амазоном up time. Т.е. надо запускать виртуалку скриптами/API/руками.

А скрипт где работает? У меня на сервере? Т.е. БД запускается удалённо с моего сервера, выполняется какая-то работа и БД гасится?

Скрипт конечно у вас. Но я не уверен что это хорошая идея. Вам придется учить специфику именно Амазоновского API. Запустить целую виртуалку на Линуксе намного более "универсально". Там внутри будет все как у вас. ОS/DB, etc. И тогда тоже придется скрипт писать чтоб ее запускать перед репликацией а иначе часы будут тикать 24/7

Т.е. давайте вернемся к изначальной цели. Что именно вы хотите достичь? Если бэкап в real-time базы то надо IMO 24/7 крутить. Если нет то зачем репликация когда можно просто incremental backup into the cloud сделать?

[Privet]

...
А в итоге какой смысл? С таким же успехом можно просто делать бэкапы в облако. А для этого много вариантов. Я лично дату бэкаплю в Amazon S3 (это просто их storage). Также я использую Crashplan. Стоит он копейки и ставить можно на Линукс что плюс.

Это не очень рационально. В этом случае я должен перегонять на облако всякий раз всю БД. Причём, форум в это время работать не будет, а при репликации я перегоняю лишь обновление. Поэтому, репликацию я могу делать чаще. В идеале, она должна работать непрерывно, но цена! Проще дома сервер для этого держать. Наверное, так и придётся.

Ещё один такой момент. При репликации на DB master-server создаётся binlog, куда записываются все запросы, которые изменяют состояние БД. Удалённый DB slave-server лишь считывает информацию из этого binlog и прокручивает все запросы у себя. Я всё думаю о том, что теоретически должно быть достаточно просто скопировать с DB master-server эти файлы, а потом где угодно их прокрутить и получить полную БД. Беда в том, что я не знаю как это организовать технически. Никто не может подсказать? Получится просто подсунуть эти бинлоги под какой-нибудь якобы DB master-server и натравить на него slave?
Тогда на фиг не нужна эта удалённая БД, а нужно только относительно небольшое пространство для бинлогов.

[katit]

...
А в итоге какой смысл? С таким же успехом можно просто делать бэкапы в облако. А для этого много вариантов. Я лично дату бэкаплю в Amazon S3 (это просто их storage). Также я использую Crashplan. Стоит он копейки и ставить можно на Линукс что плюс.

Это не очень рационально. В этом случае я должен перегонять на облако всякий раз всю БД. Причём, форум в это время работать не будет, а при репликации я перегоняю лишь обновление. Поэтому, репликацию я могу делать чаще. В идеале, она должна работать непрерывно, но цена! Проще дома сервер для этого держать. Наверное, так и придётся.

Ещё один такой момент. При репликации на DB master-server создаётся binlog, куда записываются все запросы, которые изменяют состояние БД. Удалённый DB slave-server лишь считывает информацию из этого binlog и прокручивает все запросы у себя. Я всё думаю о том, что теоретически должно быть достаточно просто скопировать с DB master-server эти файлы, а потом где угодно их прокрутить и получить полную БД. Беда в том, что я не знаю как это организовать технически. Никто не может подсказать? Получится просто подсунуть эти бинлоги под какой-нибудь якобы DB master-server и натравить на него slave?

Когда я говорил об "incremental backup" это и имел в виду.
https://stackoverflow.com/questions/441 ... p-in-mysql

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

[StrangerR]

Кстати могу подарить (это опен соурс) апплаенс - VM-ку (линукс внутри) для VTI IPSEC туннелей с Амазоном. То есть можно амазоновскую VPC сделать частью своей сети. Мы это доотладили, сделали апплаенс и скрипты, и опубликовали как опен соурс (версию с убранной корпоративной спецификой). У меня их около 20 крутится (с разными облаками связь из разных зон для разных кастомеров). Если это сделать то отпадет проблема защиты, адресации и всего прочего - просто из внутренней сети на приватных адресах будет прямой доступ в амазоновскую сеть на приватных адресах, ну и обратно. Правда, у них этот сервис (VPN) стоит $40 в месяц и нельзя его динамически поднимать или опускать.

[mavr]

с виртуалками там платить надо за час работы. Т.е. если выключить то счетчик не идет.

А можно глупый вопрос?
Они up time считают или CPU time?

Кто как, но в случае с Амазоном up time. Т.е. надо запускать виртуалку скриптами/API/руками.

А скрипт где работает? У меня на сервере? Т.е. БД запускается удалённо с моего сервера, выполняется какая-то работа и БД гасится?

Скрипт конечно у вас. Но я не уверен что это хорошая идея. Вам придется учить специфику именно Амазоновского API. Запустить целую виртуалку на Линуксе намного более "универсально". Там внутри будет все как у вас. ОS/DB, etc. И тогда тоже придется скрипт писать чтоб ее запускать перед репликацией а иначе часы будут тикать 24/7

Т.е. давайте вернемся к изначальной цели. Что именно вы хотите достичь? Если бэкап в real-time базы то надо IMO 24/7 крутить. Если нет то зачем репликация когда можно просто incremental backup into the cloud сделать?

Чего там учить? Одна cli команда.

stop-db-instance --db-instance-identifier mydbinstance