- A+
所属分类：MySQL
此缩容非彼缩容
无论是在ORACLE、MSSQL中都会存在着扩容、缩容的操作，并且这个技能基本是DBA所必备的。下面是本人的一点理解：
- 扩容：数据在增长，在快达到磁盘或数据库的容量时，增加磁盘和或表空间的一种操作。
- 缩容：在delete、update、insert操作平凡的表中会产生许多的磁盘碎片，这是后需要对碎片进行整理或者对表数据进行从新生成一次，从而达到减小容量的目的。
而现在要说的扩容和缩容是结业某种业务场景的（其实就是分库分表的数据迁移）：
- 扩容：在预计访问会爆增之前。增加机器，并分库分表将数据进行迁移，让压力进行分散处理。从而能度过高频反问时期。
- 缩容：在高频访问时期过去了，再将数据进行汇集。以至于能腾出机器，从而达到减少成本的一种做法。
扩容其实在之前分库分表的时候从操作过了。只是之前我们不知道那样就叫做扩容。
缩容
下面我们演示将test_3的库数据进行迁移
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
if __name__=='__main__': # 设置公共库配置 db_config_common = { 'user' : 'root', 'password': 'root', 'host' : '127.0.0.1', 'port' : 3306, 'database': 'test' } sharding = ShardingDatabase() # 设置公共数据库配置 sharding.get_conn_cursor(db_config_common, 'common') # 获得数据存在test_3的用户 select_sql = ''' SELECT username FROM user where db_name = 'test_3' ''' sharding.cursor_select_common.execute(select_sql) username_list = [] for (username,) in sharding.cursor_select_common: username_list.append(username) for username in username_list: # 指定用户数据到 test_2库 表7 sharding.move_data(username, 'test_2', 7) # 删除库 test_3 drop_db_sql = ''' DROP DATABASE test_3 ''' sharding.cursor_dml_common.execute(drop_db_sql) |
查看迁移后数据：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
-- 库test_3已经被删除 show databases; +--------------------+ | Database | +--------------------+ | test | | test_1 | | test_2 | +--------------------+ -- 在test_2库的用户数据 SELECT * FROM test.user WHERE db_name = 'test_2'; +---------+------------+------------+------------+---------+ | user_id | username | password | table_flag | db_name | +---------+------------+------------+------------+---------+ | 3 | username3 | password3 | 7 | test_2 | | 7 | username7 | password7 | 3 | test_2 | | 55 | username55 | password55 | 6 | test_2 | +---------+------------+------------+------------+---------+ SELECT * FROM buy_order_7 WHERE user_id = 3 LIMIT 0, 2; +---------------------+---------+---------------+-------+--------+ | buy_order_id | user_id | user_guide_id | price | status | +---------------------+---------+---------------+-------+--------+ | 3794292612787081217 | 3 | 1 | 0.00 | 0 | | 3794292612803858433 | 3 | 1 | 0.00 | 0 | +---------------------+---------+---------------+-------+--------+ SELECT * FROM order_goods_7 WHERE sell_order_id = 3794292749739495425 LIMIT 0, 1; +---------------------+---------------------+---------------------+---------------+--------+------+ | order_goods_id | sell_order_id | goods_id | user_guide_id | price | num | +---------------------+---------------------+---------------------+---------------+--------+------+ | 3794293053134475265 | 3794292749739495425 | 3794292588254597121 | 7 | 630.00 | 2 | +---------------------+---------------------+---------------------+---------------+--------+------+ |
总结
分库不是DBA一个人的事。它牵扯到的太多太多，一定要和产品和开发一起慢慢琢磨。
昵称：HH
QQ：275258836
ttlsa群交流沟通(QQ群②：6690706 QQ群③：168085569 QQ群④：415230207（新） 微信公众号：ttlsacom)
感觉本文内容不错，读后有收获？
微信公众号
扫一扫关注运维生存时间公众号，获取最新技术文章~
16/03/2016 下午 3:59 沙发
缩容的原理是啥？
业务上一般不会进行物理上的删除操作的，只是逻辑上屏蔽，不在前段展示，数据库上还是存在的。
22/03/2016 上午 10:07 1层
@匿名 缩容一般和扩容要结合起来看
比如你在业务高峰期的时候像订单表会变的很繁忙为了，一张订单表会顶不住高峰期的压力。这时候就需要对订单表进行拆分，比如拆分10张表在不同库上。让业务压力分散在不同的订单表中。等高分期过去了，发现之前的分表分库占用了太多的机器等资源。那其实使用3张表就能顶住平时的压力。这时候就可以回收7张表的数据到其中三张。把资源放出来。做其他事情。毕竟购买和租用别人的资源是要花不少钱的。 :mrgreen: