Re: Streaming Replication patch for CommitFest 2009-09
От | Greg Smith |
---|---|
Тема | Re: Streaming Replication patch for CommitFest 2009-09 |
Дата | |
Msg-id | alpine.GSO.2.01.0909141133180.1786@westnet.com обсуждение исходный текст |
Ответ на | Streaming Replication patch for CommitFest 2009-09 (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Streaming Replication patch for CommitFest 2009-09
Re: Streaming Replication patch for CommitFest 2009-09 Re: Streaming Replication patch for CommitFest 2009-09 Re: Streaming Replication patch for CommitFest 2009-09 |
Список | pgsql-hackers |
This is looking really neat now, making async replication really solid first before even trying to move on to sync is the right way to go here IMHO. I just cleaned up the docs on the Wiki page, when this patch is closer to being committed I officially volunteer to do the same on the internal SGML docs; someone should nudge me when the patch is at that point if I don't take care of it before then. Putting on my DBA hat for a minute, the first question I see people asking is "how do I measure how far behind the slaves are?". Presumably you can get that out of pg_controldata; my first question is whether that's complete enough information? If not, what else should be monitored? I don't think running that program going to fly for a production quality integrated replication setup though. The UI admins are going to want would allow querying this easily via a standard database query. Most monitoring systems can issue psql queries but not necessarily run a remote binary. I think that parts of pg_controldata needs to get exposed via some number of built-in UDFs instead, and whatever new internal state makes sense too. I could help out writing those, if someone more familiar with the replication internals can help me nail down a spec on what to watch. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-hackers по дате отправления: