From: Abbas B. <abb...@en...> - 2013-02-28 07:58:41
|
On Thu, Feb 28, 2013 at 12:53 PM, Nikhil Sontakke <ni...@st...>wrote: > >> > >> Am sorry, if I missed any earlier discussion on this. > >> How is the backup consistent in this phase? > > > > > > Because changes to the catalog were prohibited cluster wide. > > Please note that we are only talking about the schema changes and not the > > data changes since DMLs are allowed. > > > > Ok, so the idea as you mention in another thread is to dump only the > schema changes here and restore it on a new node. > Yes > > Then the rest of the data distribution will be done by another set of > commands. Yes > What happens to DML changes happening at the time of this > data distribution? > They are treated as normal DMLs and ALTER TABLE REDISTRIBUTE takes care of data to be transfered to the new datanode. > > Regards, > Nikhils > >> > >> > >> Regards, > >> Nikhils > >> > >> On Tue, Feb 19, 2013 at 12:37 PM, Abbas Butt > >> <abb...@en...> wrote: > >> > Hi, > >> > Attached please find a patch that locks the cluster so that dump can > be > >> > taken to be restored on the new node to be added. > >> > > >> > To lock the cluster the patch adds a new GUC parameter called > >> > xc_lock_for_backup, however its status is maintained by the pooler. > The > >> > reason is that the default behavior of XC is to release connections as > >> > soon > >> > as a command is done and it uses PersistentConnections GUC to control > >> > the > >> > behavior. We in this case however need a status that is independent of > >> > the > >> > setting of PersistentConnections. > >> > > >> > Assume we have two coordinator cluster, the patch provides this > >> > behavior: > >> > > >> > Case 1: set and show > >> > ==================== > >> > psql test -p 5432 > >> > set xc_lock_for_backup=yes; > >> > show xc_lock_for_backup; > >> > xc_lock_for_backup > >> > -------------------- > >> > yes > >> > (1 row) > >> > > >> > Case 2: set from one client show from other > >> > ================================== > >> > psql test -p 5432 > >> > set xc_lock_for_backup=yes; > >> > (From another tab) > >> > psql test -p 5432 > >> > show xc_lock_for_backup; > >> > xc_lock_for_backup > >> > -------------------- > >> > yes > >> > (1 row) > >> > > >> > Case 3: set from one, quit it, run again and show > >> > ====================================== > >> > psql test -p 5432 > >> > set xc_lock_for_backup=yes; > >> > \q > >> > psql test -p 5432 > >> > show xc_lock_for_backup; > >> > xc_lock_for_backup > >> > -------------------- > >> > yes > >> > (1 row) > >> > > >> > Case 4: set on one coordinator, show from other > >> > ===================================== > >> > psql test -p 5432 > >> > set xc_lock_for_backup=yes; > >> > (From another tab) > >> > psql test -p 5433 > >> > show xc_lock_for_backup; > >> > xc_lock_for_backup > >> > -------------------- > >> > yes > >> > (1 row) > >> > > >> > pg_dump and pg_dumpall seem to work fine after locking the cluster for > >> > backup but I would test these utilities in detail next. > >> > > >> > Also I have yet to look in detail that standard_ProcessUtility is the > >> > only > >> > place that updates the portion of catalog that is dumped. There may be > >> > some > >> > other places too that need to be blocked for catalog updates. > >> > > >> > The patch adds no extra warnings and regression shows no extra > failure. > >> > > >> > Comments are welcome. > >> > > >> > -- > >> > Abbas > >> > Architect > >> > EnterpriseDB Corporation > >> > The Enterprise PostgreSQL Company > >> > > >> > Phone: 92-334-5100153 > >> > > >> > Website: www.enterprisedb.com > >> > EnterpriseDB Blog: http://blogs.enterprisedb.com/ > >> > Follow us on Twitter: http://www.twitter.com/enterprisedb > >> > > >> > This e-mail message (and any attachment) is intended for the use of > >> > the individual or entity to whom it is addressed. This message > >> > contains information from EnterpriseDB Corporation that may be > >> > privileged, confidential, or exempt from disclosure under applicable > >> > law. If you are not the intended recipient or authorized to receive > >> > this for the intended recipient, any use, dissemination, distribution, > >> > retention, archiving, or copying of this communication is strictly > >> > prohibited. If you have received this e-mail in error, please notify > >> > the sender immediately by reply e-mail and delete this message. > >> > > >> > > ------------------------------------------------------------------------------ > >> > Everyone hates slow websites. So do we. > >> > Make your web apps faster with AppDynamics > >> > Download AppDynamics Lite for free today: > >> > http://p.sf.net/sfu/appdyn_d2d_feb > >> > _______________________________________________ > >> > Postgres-xc-developers mailing list > >> > Pos...@li... > >> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > >> > > >> > >> > >> > >> -- > >> StormDB - http://www.stormdb.com > >> The Database Cloud > >> Postgres-XC Support and Service > > > > > > > > > > -- > > -- > > Abbas > > Architect > > EnterpriseDB Corporation > > The Enterprise PostgreSQL Company > > > > Phone: 92-334-5100153 > > > > Website: www.enterprisedb.com > > EnterpriseDB Blog: http://blogs.enterprisedb.com/ > > Follow us on Twitter: http://www.twitter.com/enterprisedb > > > > This e-mail message (and any attachment) is intended for the use of > > the individual or entity to whom it is addressed. This message > > contains information from EnterpriseDB Corporation that may be > > privileged, confidential, or exempt from disclosure under applicable > > law. If you are not the intended recipient or authorized to receive > > this for the intended recipient, any use, dissemination, distribution, > > retention, archiving, or copying of this communication is strictly > > prohibited. If you have received this e-mail in error, please notify > > the sender immediately by reply e-mail and delete this message. > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > Postgres-XC Support and Service > -- -- Abbas Architect EnterpriseDB Corporation The Enterprise PostgreSQL Company Phone: 92-334-5100153 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message. |