福州做网站建设服务商,wordpress制作的网站,域名一定要备案才能用吗,牛商网做的网站如何趁机房搬迁的机会#xff0c;打算做一次业务整合。现有的架构是在2010年规划并运营起来的#xff0c;随着时间的推移#xff0c;项目也越来越多。打开Nginx配置文件#xff0c;有四十多行Include包含存在#xff0c;每一个包含就是一个项目#xff08;有些是Web#xff… 趁机房搬迁的机会打算做一次业务整合。现有的架构是在2010年规划并运营起来的随着时间的推移项目也越来越多。打开Nginx配置文件有四十多行Include包含存在每一个包含就是一个项目有些是Web有些是APP。一整个机柜老旧的设备负载均衡高可用架构。 为保证业务一致性和降低成本业务数据包括开发的应用程序及用户上传数据共享一套NFS各业务共享同一套物理数据库一台物理服务器MySQL创建多个库。随着业务和访问量的增长这种隐患越来越令人担忧主要表现在安全问题及性能问题这两个方面。 1、安全问题 数十个站点共享目录以NFS方式共享给各物理服务器这几十个项目只要任何一个有安全漏洞存在有心人都能进来为所欲为让站点全部沦陷。时不时的被人注入恶意代码针对性地进行清除但没多久又被注入篡改。 大家心里都有数存在漏洞的地方不一定是被篡改的那个。但站点太多又没有隔离根本无法用安全工具扫描一个站点进行扫描平均花费一天。 [rootweb57 ~]# more /usr/local/nginx/conf/nginx.confuser www www;worker_processes 6;worker_rlimit_nofile 51200;events {use epoll;#use kqueue; #FreeBSD systemworker_connections 51200;}http {include mime.types;default_type application/octet-stream;#charset gb2312;server_names_hash_bucket_size 256;client_header_buffer_size 256k;large_client_header_buffers 4 256k;client_max_body_size 500m;…………………………………………省略若干…………………………………include vhosts/faxian.quanzhen.com.conf;include vhosts/www.quanzhen.com.conf;include vhosts/news.quanzhen.com.conf;include vhosts/s.quanzhen.com.conf;include vhosts/down.quanzhen.com.conf;include vhosts/static.quanzhen.com.conf;include vhosts/image.quanzhen.com.conf;include vhosts/3g.quanzhen.com.conf;include vhosts/mini.quanzhen.com.conf;include vhosts/xml.quanzhen.com.conf;include vhosts/mayiapi.quanzhen.com.conf;include vhosts/www.android77.com.conf;include vhosts/fahongbao.android77.com.conf;include vhosts/update.android77.com.conf;include vhosts/dev.quanzhen.com.conf;include vhosts/qr.110.cc.conf;include vhosts/110.cc.conf;include vhosts/eggserver.quanzhen.com.conf;include vhosts/apkegg.quanzhen.com.conf;include vhosts/eggserver.yidong7.cn.conf;include vhosts/www.yidong7.cn.conf;include vhosts/down.yidong7.cn.conf;include vhosts/wan.quanzhen.com.conf;include vhosts/open.quanzhen.com.conf;include vhosts/bakdown.yidong7.cn.conf ;include vhosts/hanhua.quanzhen.com.conf;include vhosts/mpk.quanzhen.com.conf;include vhosts/android.quanzhen.com.conf;include vhosts/pay.quanzhen.com.conf;include vhosts/cmstop.quanzhen.cn.conf;include vhosts/news.quanzhen.cn.conf;include vhosts/pingce.quanzhen.cn.conf;include vhosts/gonglue.quanzhen.cn.conf;include vhosts/hao.quanzhen.cn.conf;include vhosts/all.quanzhen.cn.conf;include vhosts/s.quanzhen.cn.conf;include vhosts/apkz.quanzhen.com.conf;include vhosts/ajax.quanzhen.com.conf;include vhosts/union.quanzhen.com.conf;include vhosts/mai.quanzhen.com.conf;include vhosts/blog.quanzhen.com.conf;include vhosts/guazi.quanzhen.com.conf;include vhosts/lockscreen.yidong7.cn.conf;include vhosts/dsp.pujia8.com.conf;include vhosts/3svx4haii9.quanzhen.com.conf;include vhosts/u.quanzhen.com.conf;include vhosts/bianji.quanzhen.com.conf;include vhosts/default.conf;}2、性能问题 性能问题主要集中在数据库上边只要有一个库出现问题引起锁表或者其它竞争全部相关业务都会挂起大伙儿都是烦不胜烦。 迁移过程 想进行拆分决策人认为本来就满机柜了如果再新家机器得另租机柜考虑到成本等其它问题只求不出事即可。 整合的计划是迁移部分业务到公有云上腾出服务器后对现有的设备进行扩充配置拼内存、硬盘等古旧的机器直接下架。留下配置高的进行虚拟化既能减少设备数量托管费降低又有利于日常维护。 前边说了这么多似乎与技术关系不大但对于一些有遗留问题的项目还是具有参考意义。接下来我们就进入正题看看我们要迁移的项目状况。要往云上迁移的数据包括网站数据及数据库数据网站数据比较好办rsync同步到对应的目录而数据库相对而言要麻烦不少。 两个数据库一个容量38G另一个29G不算太大但公用的IBData1文件却有123G最初是尝试把这两个库直接导入到阿里云的RDS在进行数次操作失败后咨询客服得到的答复是RDS暂时不支持分表的数据库。为节省成本购买一个配置高一点的云主机cpu 8core内存32G1T高效云盘部署上MySQL5.6供两个数据库使用。 1、第一次尝试 预估了一下200G的数据贪心一把看一次性能不能迁移完。提前几天把云上的环境全部准备妥当能出来测试页运营部门把通知发下去然后某天夜里0:30分一些人在办公室一些人在家里眯着眼庄重地在键盘敲入“screen”这几个字符。在qq群里得到一致许可可以进行数据库导出操作以后小弟小心翼翼地发来一条指令 [rootdb-209 ~]# innobackupex --userroot --passwori%KGb76 \--defaults-file/etc/my.cnf \--databases“quanzhen_mobile7lockscreen quanzhen_equipment” /data/bakmysql/InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oyand Percona Ireland Ltd 2009-2012. All Rights Reserved.This software is published underthe GNU GENERAL PUBLIC LICENSE Version 2, June 1991.180618 00:30:31 innobackupex: Starting mysql with options: --defaults-file/etc/my.cnf --passwordxxxxxxxx --userroot --unbuffered --180618 00:30:31 innobackupex: Connected to database with mysql child process (pid20090)180618 00:30:37 innobackupex: Connection to database server closedIMPORTANT: Please check that the backup run completes successfully.At the end of a successful backup run innobackupexprints completed OK!.innobackupex: Using mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1innobackupex: Using mysql server version Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.innobackupex: Created backup directory /data/bakmysql/2018-06-18_00-30-37180618 00:30:37 innobackupex: Starting mysql with options: --defaults-file/etc/my.cnf --passwordxxxxxxxx --userroot --unbuffered --180618 00:30:37 innobackupex: Connected to database with mysql child process (pid20123)180618 00:30:39 innobackupex: Connection to database server closed180618 00:30:39 innobackupex: Starting ibbackup with command: xtrabackup_55 --defaults-file/etc/my.cnf --defaults-groupmysqld --backup --suspend-at-end --target-dir/data/bakmysql/2018-06-18_00-30-37 --tmpdir/tmpinnobackupex: Waiting for ibbackup (pid20132) to suspendinnobackupex: Suspend file /data/bakmysql/2018-06-18_00-30-37/xtrabackup_suspendedxtrabackup_55 version 2.0.7 for Percona Server 5.5.16 Linux (x86_64) (revision id: 552)xtrabackup: uses posix_fadvise().xtrabackup: cd to /data/mysql_dbxtrabackup: Target instance is assumed as followings.xtrabackup: innodb_data_home_dir ./xtrabackup: innodb_data_file_path ibdata1:10M:autoextendxtrabackup: innodb_log_group_home_dir ./xtrabackup: innodb_log_files_in_group 2xtrabackup: innodb_log_file_size 5242880 log scanned up to (601191481892)[01] Copying ./ibdata1 to /data/bakmysql/2018-06-18_00-30-37/ibdata1 log scanned up to (601191481892) log scanned up to (601191481892) log scanned up to (601191481892) log scanned up to (601191481892) log scanned up to (601191481892) log scanned up to (601191481892) log scanned up to (601191481892)…………………………………省略……………………………………………乐观估计上午7点前能完成整个迁移几个人商量轮流监看进展程度等进行完一步后叫醒休息的人以便进行下一步。结果到凌晨六点多才执行完这个innobackupex还差好几步呢每一步都同样耗时只能宣告迁移暂时失败选个黄道吉日分两次进行迁移。 2、第二次分拆迁移 万年历排除近期诸事不宜的日子再摇卦选利用用神的地支选定日志约上相关人等继续进行迁移。有了上一次的教训在迁移前又对要迁移的库做了清理删掉了一些无用的数据省出来好几个G的空间。在源数据库执行指令 [rootdb-209 ~]#innobackupex --userroot --passwori%KGb76 \--defaults-file/etc/my.cnf --databases“quanzhen_equipment” /data/bakmysql/我交代好以后就躺下睡觉到凌晨三点电话响了告知第一步完成。 [rootdb-209 ~]#innobackupex --apply-log /data/bakmysql/2018-06-18_00-30-37日志应用倒是执行的很快回车即完。然后进行tar打包和复制文件到目标服务器由于租赁的出口带宽太小总带宽30M现在读者知道为什么要夜间访问低谷进行迁移了吧复制文件到目标服务花了一些时间。 目标服务器仅仅需要安装好MySQL软件创建好目录/data/mysql_db不需要执行数据库初始化操作因为Innobackupex导入时要求数据目录必须为空。阿里云的配置比源服务器配置高解压文件很快就完成。 检查一下MySQL选项文件/etc/my.cnf注意是选项文件。 设定“—datadir/data/mysql_db”就可执行导入操作指令如下 [rootmsyql mysql_db]# innobackupex --defaults-file/etc/my.cnf \--copy-back /data/db_bk/2018-06-18_00-30-37源数据导出时没有把库MySQL一并导出这倒不是什么要紧的事情反正只有一个账户需要创建。接下来初始化数据库并创建应用帐号具体操做如下 [rootmsyql mysql_db]#cd /usr/local/mysql/[rootmsyql ~]#scripts/mysql_install_db --usermysql --datadir/data/mysql_db[rootmsyql ~]#mysqlmysqlgrant all on quanzhen_equipment.* to ……还要记得给MySQL空密码消除掉。 源库与目标库比对一下表的数量以及随机抽取一些大表对记录数进行比较。确认数据完整以后一帮去调试应用后续工作就没我什么事。 3、第三次分拆迁移 有了上一次的成功经验这次信心满满了不过担心还是有的就是那个目标库导入时要求数据目录为空。小弟在未开始时就来征求我的意见我担心可能会有障碍就对他说你只要把源站数据导出准备好放到目标数据库余下的我亲自搞定。 自己的选择有两个一个是使用选项“--force-non-empty-directories”如果不行就再弄一个MySQL实例启用3307端口双实例运行。先尝试第一个选项看能不能进行下去具体指令为 [rootmsyql db_bk]# pwd/data/db_bk[rootmsyql db_bk]#innobackupex --defaults-file/etc/my.cnf --copy-back \--force-non-empty-directories 2018-06-22_00-24-52180623 23:31:57 innobackupex: Starting the copy-back operationIMPORTANT: Please check that the copy-back run completes successfully.At the end of a successful copy-back run innobackupexprints completed OK!.innobackupex version 2.4.11 based on MySQL server 5.7.19 Linux (x86_64) (revision id: b4e0db5)innobackupex: Cant create/write to file /data/mysql_db/ib_logfile0 (Errcode: 17 - File exists)[01] error: cannot open the destination stream for ib_logfile0[01] Error: copy_file() failed.悲催了有同名文件存在不行直接终止运行。好吧我把文件“ib_logfile0、ib_logfile1”挪走再执行还是不行提示文件“ibdata1”存在这可是个大家伙。虽然担心新导入的ibdata1可能不包含现有数据库相关信息但忍不住想试一把。可能有读者会问这样搞可能把数据库原有的数据破坏掉了其实我想到这一层了老早我就把整个库做了备份买了保险的。 正全神贯注盯着屏幕查看输出希望进展顺利突然qq群有消息传来问进展如何啥时能完成。一看时间六点了北方大地已经一片光明。时间来不及了停掉进程试试直接复制文件不使用Innobuckupex。心中没底就去仔细比较了数据库目录与导出数据目录中的三个文件“ibdata1、ib_logfile0、ib_logfile1”发现其大小完全相同。不管了把现有数据库里的这几个文件搬走从导出目录cp来着三个文件。复制完执行mysqld_safe启动服务失败提示ib_logfile0无写入权限这好办一条chown指令而已。再执行启动MySQL服务正常。 那么数据对不对呢我不能确定万一不对就再配一个MySQL导入数据以双实例启动后边再想法整合阿里云购买的服务器相互通信是内网不会在传输上浪费太多时间。 既然服务正常就对一下数据吧万一运气爆棚前几天夜里梦到自己能飞抓住一只巨型天鹅我美美地搂着天鹅的脖子…数据完整可用呢 我自己悄悄对比了一阵没发现差异又到qq群呼叫其它人说导入有障碍数次不成功后边采取了一些不确定的手段MySQL服务是起来了请大家核实一下数据看是否完整可用。几个程序员一阵忙碌得到答复数据是完整可用的。到此我的工作完成了。 有人可能要鄙视我一番为什么不先测试不制定完善的流程这个问题问得好我数次建议决策人准备点资源说白了就是准备1台空闲服务器再内网演练就算白天也能能进行复制数据走内网不在用户访问的带宽但是没有资源给我啊事情又不得不做。虽然累点折腾一番反过来想咱玩悬的也获得经验不然也没有这个文章问世你们觉得呢 原文发布时间为2018-07-02本文作者sery本文来自云栖社区合作伙伴“DBAplus社群”了解相关信息可以关注“DBAplus社群”。
