List:General Discussion« Previous MessageNext Message »
From:Karr Abgarian <abvk Date:March 22 2014 9:33pm
Subject:Re: Locking a Database (not tables) x
View as plain text  
Perhaps enabling read only, followed by import with super user will do what you want.   


On Mar 22, 2014, at 12:26 AM, Manuel Arostegui <manuel@stripped> wrote:

> 2014-03-21 18:42 GMT+01:00 David Lerer <dlerer@stripped>:
> 
>> Frequently, we import a production dump that contains only 1 or 2
>> databases into one of our QA instances that contains many more databases.
>> (i.e. "database" being a "schema" or a "catalogue).
>> At the beginning of the import script, we first drop all objects in the QA
>> database so that it will be a perfect match (object wise) to production.
>> 
>> Is there an easy way to lock the whole database for the duration of the
>> import - so that no developers can update the database?
>> Obviously, I can revoke permissions, but I was wondering whether there is
>> a better approach.
>> 
> 
> 
> Hello,
> 
> One more idea:
> 
> Assuming you can stop your DB - restart the database so it only listens in
> the unix socket or in a different IP (an alias of your current IP could
> work) and connect thru it do all your stuff and enabled it back to its
> original port and IP.
> Obviously I am assuming your developers connect remotely (thru port 3306 or
> whichever you use).
> 
> Manuel.

Thread
Locking a Database (not tables) xDavid Lerer21 Mar 2014
  • Re: Locking a Database (not tables) xshawn l.green21 Mar 2014
    • RE: Locking a Database (not tables) xDavid Lerer24 Mar 2014
      • Re: Locking a Database (not tables) xPeter Brawley24 Mar 2014
  • Re: Locking a Database (not tables) xManuel Arostegui22 Mar 2014
  • Re: Locking a Database (not tables) xKarr Abgarian22 Mar 2014
RE: Locking a Database (not tables) xDavid Lerer21 Mar 2014