Re: approach to logging complete statements
От | Sergey Konoplev |
---|---|
Тема | Re: approach to logging complete statements |
Дата | |
Msg-id | CAL_0b1tGgK1WTUmMnzEBgQ0QKfVq59PxZcX8Th_wQUEWbr8iNA@mail.gmail.com обсуждение исходный текст |
Ответ на | approach to logging complete statements (Michael Swierczek <mike.swierczek@gmail.com>) |
Ответы |
Re: approach to logging complete statements
|
Список | pgsql-novice |
Hi, On Mon, May 20, 2013 at 11:18 AM, Michael Swierczek <mike.swierczek@gmail.com> wrote: > Hello. I have a web surveying system backed by PostgreSQL. A common > use case is for internal staff to make a series of changes to some > survey templates (questions, question order, calculations based on > answers, translations, etc...) through the web interface. Then those > changes are tested, and then manually reproduced through the web > interface on production servers. The manual reproduction wastes time > and causes errors, so instead I would like to capture all of the SQL > that affects the modified tables on development machines so we can run > it on the production servers. You can use a replication tool, eg. londiste, to replicate changes of particular tables to the production database. Keep the replication service stopped all the time when you do not need to mirror your changes, it will still collect the changes in the internal tables on the testing server side. When you are ready to apply the changes to the production start the replication, wait until all the data is replicated and stop it again. Note, that this approach requires you to have separate tables for metadata (ones that only internal stuff will change) and user tables, so you are assumed to replicate metadata tables from testing to production. -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA Profile: http://www.linkedin.com/in/grayhemp Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979 Skype: gray-hemp Jabber: gray.ru@gmail.com
В списке pgsql-novice по дате отправления: