
Alexey
14.05.2016
14:09:46
и особо эти нововедение не распробовал

Alexander
14.05.2016
14:31:42

Александр
14.05.2016
14:32:31

Phil
14.05.2016
14:37:56

Google

Александр
14.05.2016
14:41:00
Ну и вроде это не зазорно?
Или да?

Pavel
14.05.2016
14:44:04

Александр
14.05.2016
14:44:12
Ни

Pavel
14.05.2016
14:45:14
Сейчас не зазорно, тем более что видна начала мутировать в линукс

Александр
14.05.2016
14:45:19
У меня гетерогенная среда, например
Да не важно, что в кого мутирует. Не будешь же ты, будучи в здравом уме поднимать астериск на винде?
Хотя это возможно
Под каждую задачу есть наиболее подходящий инструмент

Alex
14.05.2016
14:52:19
Да использование винды незазорно, но если ты вроде как системный администратор вроде как в хостинговых компаниях то вероятно знания юникса не сильно излишне.
*unix-like систем для особых эстетов

Vasily
14.05.2016
15:42:48
смотри, если нет хотя бы 10 тыщ rps то тарантул не нужне
Чат конечно не тот, но вот пытаюсь понять - Вы хотите в нишу CouchBase-а? Их вроде как используют как основную базу, у них синхронный коммит на столько нод, на сколько укажешь и т.д. Если Тарантул будет таким же - то это будет хорошо.

Konstantin
14.05.2016
15:48:16
Ыыыы... Ниша каучбейса. У него есть ниша? Это Франкенштейн из couchdb и memcache на стероидах ) И мы быстрее элак раз в 5 их.

Google

Vasily
14.05.2016
15:52:11

Konstantin
14.05.2016
16:00:30
Мы не кеш.

Vasily
14.05.2016
16:00:53

Konstantin
14.05.2016
16:00:55
Наша ниша сегодня - backend-free microservice

Александр
14.05.2016
16:01:01
Мы не сеем

Konstantin
14.05.2016
16:01:20
Когда база она же апп сервер и она же бэкенд для нагруженного проекта
Кэширование - антипаттерн если есть Тарантул

Vasily
14.05.2016
16:04:16

Konstantin
14.05.2016
16:09:20
Кэширование - это не вынос нагрузки. Для выноса нагрузки Тарантул и создавался. Но нагрузку надо выносить вместе с данными. Иначе такой вынос - ло первого холодного рестарта
Или до первой баги синхронизации кэша и первоисточника

Vasily
14.05.2016
16:15:33


Konstantin
14.05.2016
17:26:15
Это не совсем пример кэширования. А "возможность потерять данные" это исключительно вопрос масштаба. Вот допустим есть такая штука, которая работает в 99.9% случаев. пока этот 0.1% не превращается в сотни недовольных пользователей, которые жмут Refresh потому что не видят progress bar - подход вроде как работает. А потом оказывается, что никто не оттестировал случай, когда кэш недоступен, что у ситуации ещё есть 100500 непредусмотренных последствий, т.к. в 99% случаях всё работает и никто не заморачивался на оставшийся 1%


Vasily
14.05.2016
17:37:42
Это не совсем пример кэширования. А "возможность потерять данные" это исключительно вопрос масштаба. Вот допустим есть такая штука, которая работает в 99.9% случаев. пока этот 0.1% не превращается в сотни недовольных пользователей, которые жмут Refresh потому что не видят progress bar - подход вроде как работает. А потом оказывается, что никто не оттестировал случай, когда кэш недоступен, что у ситуации ещё есть 100500 непредусмотренных последствий, т.к. в 99% случаях всё работает и никто не заморачивался на оставшийся 1%
Я согласен - на 1% или на 0.1% случаев есть система которая сама разошлёт письма, смс, позвонит и скажет нежным женским голосом - не все сервисы доступны в данное время, приносим извинения за временные неудобства ;) . Невозможно держать даже самую стабильную систему 100% uptime - иногда бывает форс-мажор. Поэтому всегда есть не технический бекап :) Но на 99% мне нужна система, которая легко ставится, настраивается, мониторится, интегрируется с существующей системой ( читай, есть библиотеки под множество языков ) и имеет более менее человеческий интерфейс ( сказывается моя Виндовая "закалка" ) - отсюда и Каучбейз.


Roman
14.05.2016
19:37:24
https://youtu.be/LXC15K4pV0o?list=PLaFqU3KCWw6KzGwUubZm-9-vKsi6vh5qC
#backup #video
16, 17 тема по ссылке

Phil
14.05.2016
19:42:33
проставь сообщению хэштеги

Roman
14.05.2016
19:43:18
какие?

Алексей
14.05.2016
19:49:21

Google

Roman
14.05.2016
19:52:15
У меня нет, но тут есть коллеги из Postgres Professional. Возможно они ответят на твой вопрос.
В конце каждой темы есть практика
Но сделать не всегда означает понять :)

Phil
14.05.2016
19:56:16
какие?
ну а что там? :) по тэгам удобно искать потом в чатике

Roman
14.05.2016
19:57:09
А где ты все теги можно посмотреть, которые уже были?

Aleksandr
14.05.2016
19:57:23

Roman
14.05.2016
19:57:28
:)

Aleksandr
14.05.2016
19:57:29
не благодарите

Phil
14.05.2016
19:57:56

Roman
14.05.2016
20:00:50
Круто! Добавил #backup

Phil
14.05.2016
20:03:14
и video и tour

Dmitry
15.05.2016
07:42:55

Руслан
15.05.2016
16:36:23
Postgesql+1c+linux
Николай, может подскажите адрес чата. Спасибо)

Александр
15.05.2016
16:49:10
А что с 1с, постгрес и линуксом?
Мне тоже интересно, мне тоже скажите

Dan
15.05.2016
16:56:37

Grisha
15.05.2016
16:57:46
http://m.cnews.ru/news/top/2015-11-05_novyj_rossijskij_linux_obkatyvaetsya_v_armejskih

Alexandr
15.05.2016
19:16:46
Ребят, подскажите пожалуйста, есть какая-то разница между pg_dump и какими-то другими более продвинутыми средствами?

Руслан
15.05.2016
19:22:56

Alexey
15.05.2016
19:30:32
выше была ссылка на документ где вроде вполне подробно и понятно описали про логический бэкап

Google

Alexey
15.05.2016
19:30:47
pg_dump это инструмент для логического бэкапа

Denis
16.05.2016
05:41:45
Народ когда результаты на эльбрус будут.... А то не охота выкладывать неофициальные....

Grisha
16.05.2016
05:43:00
А какой именно Эльбрус. Они ж разные...

Denis
16.05.2016
05:45:16
401 402
Конечно желательно 402
С кпи2 и четырмя процами

Grisha
16.05.2016
05:55:54
Там 2 режима. Эмуляция Интел и нативный. Какой интересует?

Denis
16.05.2016
06:02:44
Интересуют реальные результаты..... Конечно в нативном тем более пг есть

Kirill
16.05.2016
06:46:55
про бекапы есть еще вот такое видео https://events.yandex.ru/lib/talks/3202/

Yury
16.05.2016
06:59:13
pg_dump это решение влоб. Если у вас небольшая БД (меньше нескольких гигабайт в архиве) то можете использовать смело и дальше.
Всё остальное как правило когда текущее решение вас не удволетворяет т.е. либо слишком медленно работает либо слишком долго причём долго тут может быть в смысле как бекапа так и востановления.
что то заговорился: первое это слишком много места жрёт.

Dmitry
16.05.2016
07:10:37

Yury
16.05.2016
07:11:20

Alexey
16.05.2016
07:13:57
Я считаю, что в бэкапах место - это вторичное
главное это RTO и RPO

Phil
16.05.2016
07:14:14

Alexey
16.05.2016
07:14:55
и уж если по бизнесу RPO должно быть малым (минуты, а лучше секунды), то тут никакой логический бэкап через pg_dump или аналогичное вряд ли поможет

Phil
16.05.2016
07:15:15

Alexey
16.05.2016
07:15:39
а от куда там полная блокировка?

Google

Alexey
16.05.2016
07:16:20
и уж если бизнесу/проекту нужна надежность, то ему нужен человек, который разберется изучит и построит систему резервного копирования

Phil
16.05.2016
07:17:26

Yury
16.05.2016
07:17:28

Alexey
16.05.2016
07:18:32
Recovery Point Objective - грубо говоря, сколько данных можно потерять
Recovery Time Objective - сколько времени отводится на восстановление в случае сбоя

Vadim
16.05.2016
07:19:24
даже pg_dump консистентный дамп делает, в доке написано ж)

Alexey
16.05.2016
07:19:25
если ты делаешь бэкап через pg_dump каждый день ночью, то в худшем случае ты потеряешь данные за 1 сутки работы решения
для разработчиков и множества вебсайтиков - это нормально

Phil
16.05.2016
07:20:04

Alexey
16.05.2016
07:20:06
бля биллнга или прочих денежных вещей это неприемлемо
фууух

Kirill
16.05.2016
07:21:16

Phil
16.05.2016
07:21:26

Kirill
16.05.2016
07:22:09
http://postgrespro.ru/doc/mvcc.html

Vadim
16.05.2016
07:23:06
версию базы данных

Phil
16.05.2016
07:24:02
да я уже понял

Айтуар
16.05.2016
07:24:22
http://www.postgresql.org/docs/9.5/static/app-pgdump.html
ключ —serializable-deferrable
вроде оно

Phil
16.05.2016
07:26:01
как всгда кстати из доки это сразу не очевидно. может даже есть упоминание (наизусть не помню), но глаз не остановился. ну ок. тогда он просто медленный. и возможно тормозит базу за счет реализации вот этой страшной аббривеатуры. но не факт