yopp
вы не можете с работающей ноды делать rsync
yopp
почему вы хотите делать rsync?
Alexander
https://docs.mongodb.com/manual/core/backups/#back-up-with-cp-or-rsync
yopp
а, увидел что вы потом останавливаете
yopp
зачем?
yopp
это ужасный метод
yopp
у вас есть какая-то реальная проблема с initial sync штатными методами?
Alexander
Есть - он не происходит
yopp
Какая версия монги, какие симптомы?
yopp
rsync это очень опасный костыль
yopp
он имеет смысл в случае если у вас есть отдельная нода для бэкапов и вы хотите из ближайшего бэкапа аварийно восстанавливать ноду
yopp
.2 есть смысл обновить до .12 и попробовать ещё раз
Alexander
rsync это очень опасный костыль
Нет вижу другого варианта. Этот видится с минимальным* простоем. Я так elasticsearch перетаскивал с одного диска на другой - вообще без простоя почти
yopp
вариант починить монгу, а не заклеивать дырку пластырем :)
yopp
потому что если у вас есть проблемы с initial sync, у вас уже что-то нездоровое с кластером
Alexander
Чинить можно когда более одной ноды из 3-х функционирует ).
yopp
с 3.4 синхронизация более-менее эквивалентна простому копированию из коллекции в коллекцию
yopp
фундаментально проблемы может быть две: не хватает ресурсов у праймари, не хватает ресурсов у секондари
yopp
или что-то с сетью между ними
yopp
если у праймари не хватает ресурсов на initial sync, значит read capacity ноды на грани и любой всплеск активности может её уронить
Alexander
Проапгрейдил железо у всех нод. Проблема не исчезла.
Сеть при initial sync используется в разы менее интенсивно, чем при rsync
yopp
если у secondary не хватает ресурсов на initial sync, то либо неверно расчитаны ресурсы, либо у primary слишком маленькое окно репликации
yopp
а значит необходимо увеличить размер оплога
Alexander
Это можно попробовать
Alexander
CPU не используется на полную
yopp
и не должен
Alexander
А как правильно рассчитывать я не знаю
yopp
cpu не единственное бутылочное горлышко
yopp
может не хватать сети, может не хватать iops, может не хватать памяти
yopp
посмотрите в логах что происходит
yopp
какой у вас размер oplog window?
Alexander
oplogSizeMB: 20240
Alexander
Данных 250G
yopp
var ri = db.getReplicationInfo();
var window = new Date(ri.tLast).valueOf() - new Date(ri.tFirst).valueOf();
print(window / (60*60*1000))
Alexander
68.3
🤴👷♂️🦸♂️🧚♀️
всем привет, делаю по гайду формочку, но тут возникла проблема, которую я так и не смог решить
app.post('/notes', (req, res) => {
const note = { text: req.body.body, title: req.body.title };
db.collection('notes').insert(note, (err, result) => {
if (err) {
res.send({ 'error': 'An error has occurred' });
} else {
res.send(result.ops[0]);
}
});
});
ошибка - db.collection is not a function
Костяныч
var ri = db.getReplicationInfo();
var window = new Date(ri.tLast).valueOf() - new Date(ri.tFirst).valueOf();
print(window / (60*60*1000))
что за язык, или у всех один просто я не в теме?
yopp
68.3
68 часов. При 250гб, выходит 250*1024/68/60/60 = при скорости выше ~1 мегабайта в секунду должно успеть
🤴👷♂️🦸♂️🧚♀️
const db = client.db('mytestingdb'); пофиксил так, но в итоге не отправляются данные сами
yopp
68.3
поднимите логи и посмотрите из-за чего ломается. можете посмотреть с какой скоростью делается дамп. у вас там дисковое хранилище какое? нжмд?
Alexander
yopp
AWS EBS io1 9000 IOPS
тогда наиболее простой способ сделать снепшот ebs и потом из этого снепшота восстановить ноду
yopp
но в aws может быть всё что угодно
Alexander
тогда наиболее простой способ сделать снепшот ebs и потом из этого снепшота восстановить ноду
Просто на время снапшота, простой на время восстановления
yopp
на время восстановления то откуда простой?
yopp
https://docs.mongodb.com/manual/tutorial/backup-with-filesystem-snapshots/#entire-disk-image
Alexander
Ну там время чисто на перемонтировать. Да, можно это не считать.
yopp
эээ
yopp
ebs снепшоты делает в s3
yopp
потом если у вас WT и журнал включен, то вам и останавливать ноду не надо
yopp
К тому что вы собрались и куда монтировать
Alexander
потом если у вас WT и журнал включен, то вам и останавливать ноду не надо
Это как же? Кеш в нём будет отсутствовать, целостность не гарантируется
yopp
Эээ
yopp
https://docs.mongodb.com/manual/tutorial/backup-with-filesystem-snapshots/#entire-disk-image
^ почитайте вот этот плейбук
yopp
Если у вас dbpath на одном разделе, включён журнал и используется wiredtiger, то вы можете сделать снепшоты без дополнительных действии, при условии что снепшоты атомарны
yopp
А у EBS снепшоты атомарны
Alexander
Они блочные, кеш ОС они не учитывают
yopp
Дальше вы разворачиваете снепшот по вот этому плейбуку на новом хосте: https://docs.mongodb.com/manual/tutorial/restore-replica-set-from-backup/
yopp
По этому есть требование к журналу
Alexander
Хотя, если монга Page Cache на диск сбрасывает, то да
yopp
Без журнала по этой причине и требуется fsync
yopp
Вы сами себе придумали проблему
yopp
Которой не существует
[object Object]
У меня проект с использованием MySQL. В один момент возникла необходимость в хранении данных, структура которых заранее неизвестна, а именно: есть таблица Person и теперь надо каждой персоне прикрепить набор характеристик, количество которых переменно.
В sql можно было бы решить такое с использованием EAV таблицы, но там свои осложнения есть.
У меня возникла мысль и одновременно вопрос: будет ли разумно реализовать гибридную систему хранения данных MySQL + MongoDB? Оставить персон в SQL, а в MongoDB хранить характеристики к каждой персоне?
С монго не имел дела, как и с NoSQL в целом. Спасибо.
yopp
У меня проект с использованием MySQL. В один момент возникла необходимость в хранении данных, структура которых заранее неизвестна, а именно: есть таблица Person и теперь надо каждой персоне прикрепить набор характеристик, количество которых переменно.
В sql можно было бы решить такое с использованием EAV таблицы, но там свои осложнения есть.
У меня возникла мысль и одновременно вопрос: будет ли разумно реализовать гибридную систему хранения данных MySQL + MongoDB? Оставить персон в SQL, а в MongoDB хранить характеристики к каждой персоне?
С монго не имел дела, как и с NoSQL в целом. Спасибо.
Сильно зависит от того, как вы с этими атрибутами потом взаимодействуете
Max
не забудьте после восстановления из снапшота прогреть диск.
иначе будет очень, очень медленно
Max
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html
Лучше брать fio
Dmitriy
У меня проект с использованием MySQL. В один момент возникла необходимость в хранении данных, структура которых заранее неизвестна, а именно: есть таблица Person и теперь надо каждой персоне прикрепить набор характеристик, количество которых переменно.
В sql можно было бы решить такое с использованием EAV таблицы, но там свои осложнения есть.
У меня возникла мысль и одновременно вопрос: будет ли разумно реализовать гибридную систему хранения данных MySQL + MongoDB? Оставить персон в SQL, а в MongoDB хранить характеристики к каждой персоне?
С монго не имел дела, как и с NoSQL в целом. Спасибо.
А зачем? Что вам мешает хранить набор серелизованных в json полей в отдельном поле а mysql? Или по полям предполагается поиск?
[object Object]
А зачем? Что вам мешает хранить набор серелизованных в json полей в отдельном поле а mysql? Или по полям предполагается поиск?
Предполагается поиск, однозначно.
[object Object]
Сильно зависит от того, как вы с этими атрибутами потом взаимодействуете
Меня больше всего волнует вопрос целостности данных. Например, если в монго содержится документ, "принадлежащий" какой-либо персоне из таблицы person, то при удалении этой персоны, в коллекции останется висеть документ с битой ссылкой на несуществующую строку.
Dmitriy
Предполагается поиск, однозначно.
Не знаю какая у вас версия мускула, но вообще с 5.7.8 там подвезли функции для поиска по json. А перформанс надо проверять конечно, но и время программиста не бесплатно)
[object Object]
Не знаю какая у вас версия мускула, но вообще с 5.7.8 там подвезли функции для поиска по json. А перформанс надо проверять конечно, но и время программиста не бесплатно)
json это конечно хорошо, но там проблемы с индексацией
[object Object]
В общем, прихожу к выводу, что гибрадная архитектура - это плохо, если данные в таблицах и коллекциях связаны, верно?