Quantcast

Altering table column family attributes without disabling the table

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Altering table column family attributes without disabling the table

techbuddy
Hi,

We need to enable replication on a live cluster. However it requires disabling the table and bringing the required column families under the scope of replication as under.

disable 'your_table'
alter 'your_table', {NAME => 'family_name', REPLICATION_SCOPE => '1'}
enable 'your_table'


This is something we really can't afford to do as disabling a table would effectively make our application unavailable for a significant time, as we have 1000s of regions per table,and disabling and enabling a table would mean closing and opening all those regions disrupting the whole Hbase cluster.


Is there any way to do this table attribute modification dynamically, without disabling the table?

-thanks
sb
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Altering table column family attributes without disabling the table

Jean-Daniel Cryans
You could always set hbase.online.schema.update.enable to true on your
master, restart it (but not the cluster), and you could do what you
are describing... but it's a risky feature to use before 0.96.0.

Did you also set hbase.replication to true? If not, you'll have to do
it on the region servers and the master via a rolling restart.

J-D
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Altering table column family attributes without disabling the table

techbuddy
Thanks for the reply JD! I came to know about this online schema setting shortly after I made the post.

And yes ,I know the hbase.replication needs to be kept set to true. However enabling that on a live cluster is not an issue for as we can do that incrementally one region server at a time after having moved all the regions on the former to a different region server (by executing the region_mover script). In other words, we always move all the regions on a given region server to a different region server before upgrading it (for co-processor changes or any config changes) that requires a subsequent restart. This makes sure that our app is not unavailable on the affected regions. And once the upgrade is complete we move the regions back to the region server using the same region_mover script.
Loading...