此缩容非彼缩容
无论是在ORACLE、MSSQL中都会存在着扩容、缩容的操作,并且这个技能基本是DBA所必备的。下面是本人的一点理解:
- 扩容:数据在增长,在快达到磁盘或数据库的容量时,增加磁盘和或表空间的一种操作。
- 缩容:在delete、update、insert操作平凡的表中会产生许多的磁盘碎片,这是后需要对碎片进行整理或者对表数据进行从新生成一次,从而达到减小容量的目的。
而现在要说的扩容和缩容是结业某种业务场景的(其实就是分库分表的数据迁移):文章源自运维生存时间-https://www.ttlsa.com/mysql/mysql-distributed-database-and-table-reduce-capacity/
- 扩容:在预计访问会爆增之前。增加机器,并分库分表将数据进行迁移,让压力进行分散处理。从而能度过高频反问时期。
- 缩容:在高频访问时期过去了,再将数据进行汇集。以至于能腾出机器,从而达到减少成本的一种做法。
扩容其实在之前分库分表的时候从操作过了。只是之前我们不知道那样就叫做扩容。文章源自运维生存时间-https://www.ttlsa.com/mysql/mysql-distributed-database-and-table-reduce-capacity/
缩容
下面我们演示将test_3的库数据进行迁移文章源自运维生存时间-https://www.ttlsa.com/mysql/mysql-distributed-database-and-table-reduce-capacity/
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)
源码:reduce_capacity文章源自运维生存时间-https://www.ttlsa.com/mysql/mysql-distributed-database-and-table-reduce-capacity/
查看迁移后数据:文章源自运维生存时间-https://www.ttlsa.com/mysql/mysql-distributed-database-and-table-reduce-capacity/
-- 库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一个人的事。它牵扯到的太多太多,一定要和产品和开发一起慢慢琢磨。文章源自运维生存时间-https://www.ttlsa.com/mysql/mysql-distributed-database-and-table-reduce-capacity/
文章源自运维生存时间-https://www.ttlsa.com/mysql/mysql-distributed-database-and-table-reduce-capacity/
昵称:HH
QQ:275258836
ttlsa群交流沟通(QQ群②:6690706 QQ群③:168085569 QQ群④:415230207(新) 微信公众号:ttlsacom)文章源自运维生存时间-https://www.ttlsa.com/mysql/mysql-distributed-database-and-table-reduce-capacity/
感觉本文内容不错,读后有收获?文章源自运维生存时间-https://www.ttlsa.com/mysql/mysql-distributed-database-and-table-reduce-capacity/
逛逛衣服店,鼓励作者写出更好文章。文章源自运维生存时间-https://www.ttlsa.com/mysql/mysql-distributed-database-and-table-reduce-capacity/ 文章源自运维生存时间-https://www.ttlsa.com/mysql/mysql-distributed-database-and-table-reduce-capacity/

1F
缩容的原理是啥?
业务上一般不会进行物理上的删除操作的,只是逻辑上屏蔽,不在前段展示,数据库上还是存在的。
B1
@ 匿名 缩容一般和扩容要结合起来看
比如你在业务高峰期的时候像订单表会变的很繁忙为了,一张订单表会顶不住高峰期的压力。这时候就需要对订单表进行拆分,比如拆分10张表在不同库上。让业务压力分散在不同的订单表中。等高分期过去了,发现之前的分表分库占用了太多的机器等资源。那其实使用3张表就能顶住平时的压力。这时候就可以回收7张表的数据到其中三张。把资源放出来。做其他事情。毕竟购买和租用别人的资源是要花不少钱的。 :mrgreen: