LINUX.ORG.RU
ФорумAdmin

Что должен уметь делать администратор postgres?

 


3

1

Привет.

Занимаюсь изучением Postgres. Можете написать список типичных задач, которые должен уметь выполнять администратор баз данных postgres?

Типа этого:

  • Снимать дампы
  • Разворачивать дампы
  • Создавать пользователей
  • Редактировать pg_hba.conf и т.д.

Спасибо!

★★★

То, что ты перечислил - это навыки любого системного администратора.

А у DBA немного другие функции, там основное это производительность и безопасность.

https://ru.wikipedia.org/wiki/Администратор_баз_данных

vvn_black ★★★★★ ()
Последнее исправление: vvn_black (всего исправлений: 1 )

Снимать дампы
Разворачивать дампы
Создавать пользователей
Редактировать pg_hba.conf и т.д.

Это всё должен уметь мальчик, который картриджи заправляет.

gremlin_the_red ★★★★★ ()

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

crutch_master ★★★★★ ()

должен понимать что postgres хорошо, а mysql плохо и всячески это доказывать не словом, но делом...

а так, знание Postgres должно быть всего лишь одним из пунктов умений обращаться с СУБД. Вдруг завтра компания разбогатеет и тебе скажут поехали на Oracle и что ты будешь делать? топить дальше за постгрес станет не вариантом...

ukr_unix_user ★★★★ ()

Я думаю, что в первую очередь Администратор Баз Данных, должен в совершенстве владеть теорией реляционных баз данных. А дальше уже нужно изучить устройство конкретного СУБД и средства его администрирования.

ZANSWER ()
Ответ на: комментарий от crutch_master

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

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

Ну это в идеале. По факту на бекап и репликации забивают, пока что-нибудь не произойдёт. А то и забивают после этого, подумаешь, база лежит. Но это я смотрю с точки зрения своей шараги, конечно.

crutch_master ★★★★★ ()
Ответ на: комментарий от crutch_master

Повсеместное отсутствие бекапов БД это какая-то тупая байка из склепа, ни разу в жизни такого не встречал. А на счёт репликации тебе любой нормальный dba скажет, что до определенного момента это не просто не нужно, а даже вредно. Ты на реплики с точки зрения обеспечения сохранности данных, доступности или ускорения чтения смотришь?

WitcherGeralt ★★ ()

Убедиться, что /tmp смонтированна в память.

anonymous ()
Ответ на: комментарий от WitcherGeralt

Повсеместное отсутствие бекапов БД
Повсеместное

смотрю с точки зрения своей шараги

Тут даже вложенки не загоняют в vcs.

Ты на реплики с точки зрения обеспечения сохранности данных, доступности или ускорения чтения смотришь?

Тут реплика в качестве тестового сервака или если основной навернётся. Но вообще хз, я как-то косо на всё это смотрю. Чтение лучше ускорить какой-нибудь inmemory, сохранность, ну может быть, хотя это придётся обеспечивать не только в бд.

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1 )
Ответ на: комментарий от WitcherGeralt

Повсеместное отсутствие бекапов БД это какая-то тупая байка из склепа, ни разу в жизни такого не встречал.

Вам очень повезло. Из жизни. «ленточки» закончились «ответственному» за бэкап просто наплевать, что уже несколько месяцев бэкап не делается да и стораджи орут в полный голос. И всем наплевать хоть в серверной бывают. Это типа «не моя епархия» «ничего не знаю, ничего не видел». Такими «стараниями» как-то за несколько месяцев данных со скады «пролюбили» когда сервак с БД навернулся. Хотя изначально все было нормально настроено, но вот «не задача» «ответственного» «поменяли» а ему просто болт на все положить, день прошел и ладно.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1 )

Можете написать список типичных задач, которые должен уметь выполнять администратор баз данных postgres?

Бухать, закусывать, играть в танчики.

anonymous ()
Ответ на: комментарий от WitcherGeralt

Повсеместное отсутствие бекапов БД это какая-то тупая байка из склепа

Насчет повсеместного отсутствия - согласен, сказки. Но лично мне, к сожалению, приходилось сталкиваться и с отсутствием бекапов, и с бекапами, содержащими битые данные, в то время как местные админы были уверены, что у них все в порядке - никто никогда не пробовал тестировать сценарий восстановления в реальных условиях. Бывали и ситуации, когда в теории все хорошо (бекап на СХД, расположенную в 40 км от сервера), а в реальности полное восстановление заняло 3(!) суток (канал между площадками 20 Mb).

Это я к тому, что мало просто разработать грамотную стратегию бекапа, нужно обязательно соотносить ее с реальными условиями, периодически проводить тренировки по восстановлению (частичном и полному). И это, на мой взгляд, и является основной задачей ДБА - защита данных и минимизация простоя при аварии.

Serge10 ★★★★★ ()
Ответ на: комментарий от crutch_master

По факту на бекап и репликации забивают

Это говорит только об одном - DBA надо срочно менять.

А то и забивают после этого, подумаешь, база лежит.

Если база не нужна для нормального функционирования конторы, то зачем она вообще ей? Вместе с DBA? Не проще ли сократить эту должность, а освободившиеся деньги пропить?

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

Борьба за производительность - это второй вопрос, который к тому же чаще решают разработчики, а не администратор БД

они это героически решают в своём кокоде, но в 95% они это могут лишь когда им одмин эскьюэлы готовые принесет в клювике.

anonymous ()
Ответ на: комментарий от WitcherGeralt

А его и нет.

Хм, тогда не очень понятно, что мы тут обсуждаем ;).

Serge10 ★★★★★ ()
Ответ на: комментарий от crutch_master

смотрю с точки зрения своей шараги

Ну, байка довольно распространенная.

Чтение лучше ускорить какой-нибудь inmemory

По-идее на нормальном железе, что PostgreSQL, что MySQL, при грамотном использовании и преимущественном чтении должны вообще без проблем и dba-рокетсайнса десятки тысяч запросов в секунду лопатить.

У меня как раз, кстати, есть потенциальная задачка под in-memory БД на ближайшее время, нахожусь пока в замешательстве. С одной стороны у меня довольно простые сценарии работы с postgres и далеко не самые большие объёмы данных, а с другой нужно будет гонять тяжелые аналитические запросы буквально по каждому событию. Вот думаю, закостылять это с помощью загрузки горячих данных в оперативу, или вообще поделить/дублировать данные и часть хранить в специальной аналитической БД. Я как-бы и понимаю, что постгрес это всё нормально прохавает, у меня даже данные под такие вещи перевентифно денормализованы, но это капец как неэффективно будет, рано или поздно с таким подходом БД колом встанет.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

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

Ну так а чем стандартное решение в виде отдельной реплики для OLAP не подходит?

no-such-file ★★★★★ ()
Ответ на: комментарий от no-such-file

Может быть и подходит. Но есть желание, а потенциально и необходимость, творить жуткий беспредел с которым лучше справится именно аналитическая (столбцовая) БД. И пока проект на ранней стадии, это ещё можно безболезненно реализовать.

Не знаю, я никогда аналитические сисетемы не разрабатывал и в конторе таких специалистов в принципе нет, вопрос ещё предстоить изучить. Если советуешь такой вариант, буду смотреть в первую очередь в его сторону, ибо выглядит как наиболее простое и естественное решение.

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 3 )
Ответ на: комментарий от WitcherGeralt

По-идее на нормальном железе, что PostgreSQL, что MySQL, при грамотном использовании и преимущественном чтении должны вообще без проблем и dba-рокетсайнса десятки тысяч запросов в секунду лопатить.

Ну, это если база не большая, все запросы тупые уровня select value from tbl where id = 42 и бд еще не засрана в процессе работы какой-нибудь дичью. У нас, например, недавно выяснилось, что записи с большим id не обязательно говорят о том, что запись добавлена позже и простая задача превратилась в блудный цирк.

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1 )
Ответ на: комментарий от Serge10

Борьба за производительность - это второй вопрос, который к тому же чаще решают разработчики, а не администратор БД

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

autonomous ★★★★★ ()
Последнее исправление: autonomous (всего исправлений: 1 )
Ответ на: комментарий от autonomous

кластеризацию, бекап и репликацию должен уметь обычный системный администратор

Не слишком ли ты многого от админа хочешь? Он не может уметь всё на свете. Базовых мастхев навыков для хорошего админа и так целый вагон, а ты ему ещё умение в БД вменяешь, где скилов нужно ещё на два вагона, БД-то много разных.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

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

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

autonomous ★★★★★ ()
Ответ на: комментарий от gremlin_the_red

Это всё должен уметь мальчик, который картриджи заправляет.

pg_hba.conf редактировать? заправщик картриджей? мда.

Alve ★★★★★ ()
Ответ на: комментарий от Alve

pg_hba.conf редактировать? заправщик картриджей?

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

autonomous ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

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

autonomous ★★★★★ ()
Ответ на: комментарий от autonomous

а кластеризацию, бекап и репликацию должен уметь обычный системный администратор

Хм, а ничего, что СУБД на свете много? И что, системный администратор должен знать тонкости администрирования Oracle, DB/2, MS SQL server, PostgreSQL, MariaDB и др.? И все это одновременно? И не просто знать, а держать эти данные в актуальном состоянии, следя, что появляется в новых версиях?

IMHO, это нереальная задача. С другой стороны, кому как не разработчику, работающему с конкретной СУБД, знать ее тонкости, узкие места, алгоритмы и скорость обработки различных запросов?

также дба следит за качеством запросов в базе, ловит медленные и предлагает варианты ускорения.

Могу еще как-то с первой частью Вашего утверждения согласиться, хотя, повторюсь, главной задачей DBA является не производительность, а сохранность и доступность данных. Но варианты ускорения - это точно проблемы разработчика. Просто потому, что во многих бизнес-приложениях на долю SQL-запросов приходится большая часть кода. Особенно, если логика реализована в самой базе, а не вынесена в сервер приложений... Если их (SQL-запросы) начнет составлять DBA, то тогда и разработчик не нужен...

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

Если из-за рукожопых макак БД встанет колом, то это проблема DBA, следовательно за медленными запросами ему тоже стоит сделить.

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 1 )
Ответ на: комментарий от autonomous

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

С этим утверждением полностью согласен. Но та же кластеризация очень сильно отличается между различными СУБД. Также как и инструменты бекапа. Хорошо, когда база данных маленькая, и можно просто время от времени собирать ее дампы. А если это несколько терабайт и работает в режиме 24/7? Тут методы бекапа будут зависеть от конкретных используемых СУБД... И одним кругозором делу не поможешь, придется изучать конкретную СУБД, чтобы грамотно решить поставленную задачу. А это время, которого может у администратора и не быть (ведь других задач никто не отменял)...

Serge10 ★★★★★ ()
Ответ на: комментарий от autonomous

это отмазки, для тех кому лень расти в профессии

Я согласен с Вами в том, что никакого rocket science в работе DBA нет. И грамотный администратор в состоянии разобраться в тонкостях конкретной СУБД. Но это вопрос времени и неизбежных граблей в ходе приобретения необходимого опыта.

Попробуйте посмотреть на это с другой стороны. Вы, как владелец бизнеса, готовы нанять сотрудника, который будет учиться работать с используемой Вами СУБД в процессе работы, подвергая риску Ваш бизнес? Или все-таки, предпочтете пригласить специалиста, имеющего опыт работы конкретно с той СУБД, которую Вы используете?

Serge10 ★★★★★ ()
Ответ на: комментарий от autonomous

хочешь чтобы тебе настраивал тот, кто сечет, учись разбираться в квалификации людей, а не в названиях специальностей.

Вот это уже другой разговор :). Поэтому-то нормальные конторы не нанимают одного мегаспециалиста, который и сетевым оборудованием рулит, и СХД настраивает, и, заодно, SQL-запросы для разработчиков пишет ;). Каждую задачу должен решать специалист в своей области, как ни странно, в итоге это оказывается гораздо выгоднее одиночки-универсала...

Serge10 ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

Если из-за рукожопых макак БД встанет колом, то это проблема DBA, следовательно за медленными запросами ему тоже стоит сделить.

Следить, стоит, конечно. Но не переписывать их самостоятельно, а обращать на них (запросы) внимание тех самых макак и добиваться их переписывания...

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

И что, системный администратор должен знать тонкости администрирования Oracle, DB/2, MS SQL server, PostgreSQL, MariaDB и др.?

Ты думаешь есть такие DBA? Нет людей, которые знают все эти нюаны, но чем больше из знаешь ты, тем круче ты админ или дба, не важно.

С другой стороны, кому как не разработчику, работающему с конкретной СУБД, знать ее тонкости, узкие места, алгоритмы и скорость обработки различных запросов?

сколько я видел разработчиков, а видел я их за 10 лет стажа не мало, никто из них не знает и не должен знать тонкостей базы данных, они знают sql и максимум какие-то особенности построения запросов для конкретной базы, всё. если тупит индекс, то разработчик не будет смотреть экслпейн, а придет к в лучшем случае к дба, а в обычном случае к админу.

главной задачей DBA является не производительность, а сохранность и доступность данных

кто конкретно тебе это сказал или где ты это прочитал?

Особенно, если логика реализована в самой базе, а не вынесена в сервер приложений...

так делать вообще не надо, но это ладно

Если их (SQL-запросы) начнет составлять DBA, то тогда и разработчик не нужен...

дба не должен писать запросы за разработчиков, он должен их анализировать и принимать миграцию или отказывать.

autonomous ★★★★★ ()
Ответ на: комментарий от Serge10

Но та же кластеризация очень сильно отличается между различными СУБД. Также как и инструменты бекапа.

И одним кругозором делу не поможешь, придется изучать конкретную СУБД, чтобы грамотно решить поставленную задачу. А это время, которого может у администратора и не быть (ведь других задач никто не отменял)...

Ты говоришь о каких-то вещах в вакууме. На деле научится пользоваться системой бекапа у опытного админа удет от дня до недели, если какие-то проблемы проявятся.

На настройку и изучения репликации уйдет ну неделя или месяц, если совсем не работал с этим и одни грабли лезут. О каком времени ты говоришь? А время на изучение тем меньше, чем больше у тебя кругозор.

autonomous ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

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

autonomous ★★★★★ ()
Ответ на: комментарий от Serge10

Вы, как владелец бизнеса, готовы нанять сотрудника, который будет учиться работать с используемой Вами СУБД в процессе работы, подвергая риску Ваш бизнес? Или все-таки, предпочтете пригласить специалиста, имеющего опыт работы конкретно с той СУБД, которую Вы используете?

На рынке полно специалистов, которые умеют и субд и не субд, если коротко

autonomous ★★★★★ ()
Ответ на: комментарий от Serge10

Вот это уже другой разговор :). Поэтому-то нормальные конторы не нанимают одного мегаспециалиста, который и сетевым оборудованием рулит, и СХД настраивает, и, заодно, SQL-запросы для разработчиков пишет ;). Каждую задачу должен решать специалист в своей области, как ни странно, в итоге это оказывается гораздо выгоднее одиночки-универсала...

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

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

autonomous ★★★★★ ()
Ответ на: комментарий от Serge10

Следить, стоит, конечно. Но не переписывать их самостоятельно, а обращать на них (запросы) внимание тех самых макак и добиваться их переписывания...

как ты будешь этого добавиться, если не знаешь как работает субд? а если знаешь, что тебе мешает делать настройку кластера? ты теоретизируешь о том, с чем не сталкивался

autonomous ★★★★★ ()
Ответ на: комментарий от autonomous

сейчас их называют sre

Ну вот, уже не вася-эникей, с этим можно работать.

WitcherGeralt ★★ ()
Ответ на: комментарий от autonomous

Ты думаешь есть такие DBA?

Нет, конечно. Просто в отличие от обычных админов, есть DBA Oracle, DBA PostgreSQL и т. д.

сколько я видел разработчиков, а видел я их за 10 лет стажа не мало, никто из них не знает и не должен знать тонкостей базы данных, они знают sql и максимум какие-то особенности построения запросов для конкретной базы, всё.

Это очень странно. Я видел совершенно противоположную ситуацию. Более того, во многих вакансиях специально оговаривается, что ищется разработчик под конкретную СУБД. Не думаю, что имеет смысл приглашать в проект на Oracle человека, который всю жизнь на MariaDB писал. Если, конечно, логика в СУБД планируется, если между приложением и базой какой-либо фреймворк, тогда действительно это все неважно. Но с другой стороны, и об оптимизации тогда говорить не приходится...

кто конкретно тебе это сказал или где ты это прочитал?

Мне сложно сейчас ответить на этот вопрос. Но вот, например, оглавление из документации того же postgreSQL, содержащее список задач, входящих в администрирование данной СУБД:

III. Администрирование сервера

    16. Установка из исходного кода
    17. Установка из исходного кода в Windows
    18. Подготовка к работе и сопровождение сервера
    19. Настройка сервера
    20. Аутентификация клиентского приложения
    21. Роли базы данных
    22. Управление базами данных
    23. Локализация
    24. Регламентные задачи обслуживания базы данных
    25. Резервное копирование и восстановление
    26. Отказоустойчивость, балансировка нагрузки и репликация
    27. Конфигурация восстановления
    28. Мониторинг работы СУБД
    29. Мониторинг использования диска
    30. Надёжность и журнал предзаписи
    31. Логическая репликация
    32. JIT-компиляция
    33. Регрессионные тесты

Как видите, здесь очень много задач, непосредственно связанных с обеспечением сохранности и доступности данных, и ничего про оптимизацию SQL-запросов.

дба не должен писать запросы за разработчиков, он должен их анализировать и принимать миграцию или отказывать.

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

Serge10 ★★★★★ ()
Ответ на: комментарий от autonomous

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

И что, бизнес будет ждать эту неделю? А если на второй день факап?

На настройку и изучения репликации уйдет ну неделя или месяц, если совсем не работал с этим и одни грабли лезут.

Вы сейчас серьезно пишете или прикалываетесь? Еще раз, поставьте себя на место владельца бизнеса. Вы правда готовы ждать месяц (!), пока Ваш админ будет разбираться с репликацией??? Или все-таки наймете человека, который сможет решить вопрос за один вечер?

А время на изучение тем меньше, чем больше у тебя кругозор.

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

Serge10 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.