首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Discuz X3.2 论坛搬家教程「建议收藏」

    大家好,又见面了,我是你们的朋友全栈君。 很多站长第一次做网站的时候,无奈选择了速度不是很稳定的空间,慢慢会发现有很多物美价廉速度相当快的空间 这个时候,站长在网站搬家的过程中就会遇到很多困难,今天老袋鼠给大家详细讲解一下discuz 论坛 搬家的详细过程 第一步:备份网站数据 进入后台—站长—数据库—备份,数据备份类型选择“Discuz!和 UCenter数据”,备份成功以后,数据自动保存在data文件夹下。 第二步:网站文件下载 把整个网站文件打包(虚拟主机管理控制面板一般都有整站压缩和解压的功能,在控制面板选择压缩,压缩之后的文件一般在FTP DB文件夹里面,然后把压缩包下载到本地电脑,如果虚拟主机没有在线压缩功能那就直接使用FTP下载文件到本地保存。 第三步:整理下载到本地的网站文件 1.把下载下来的文件里面的下列文件删除,请完全放心删除掉这几个文件,重新装上的时候会自动产生新的文件。 /install/install.lock (有的下载下来之后就没有这个文件,如果没有就不用管)   /config/config_global.php   /config/config_ucenter.php   /uc_server/data/config.inc.php 2.到官方下载一个Discuz! X3.2的安装包,把 upload里的/install/文件夹复制过来覆盖你下载下来的网站文件。 3.把从官方下载下来的Discuz! X3.2安装包里面的 utility/restore.php 文件放到你网站文件的/data/文件夹内,这是用于数据库还原。 第四步:将整理好的网站文件包上传到新主机空间(放网页资料的文件夹下) 建议压缩之后在使用FTP上传,上传完成之后进入虚拟主机控制面板在线解压,这样可以节约很多时间,目前几乎所有的虚拟主机都有在线解压功能,格式一般是rar格式,不过有的部分虚拟主机如linux主机就只支持.zip格式,所以打包前请注意。 第五步:域名解析及空间绑定域名 进入域名控制面板把域名解析到你新的虚拟主机IP上,然后在进入虚拟主机空间绑定域名。 第六步:重新安装discuz http://你的域名/instal/进行安装,填入你新的虚拟主机数据库名和用户名及数据库密码,注意数据库的数据表前缀和以前一样,一般你之前的数据表如果没有改动的话,你重新安装的时候默认的就是和你以前的一样,所以可以不用改。当你安装的时候可能会提示要你删除data/install.lock这个文件才可以继续安装,那么你可以进入FTP删除之后然后返回安装页面刷新一下再继续安装,这就可以安装了。 第七步:还原数据库 安装成功后,用你安装的时候填写的管理员帐号和密码登录,进入后台—站长—数据库—恢复—数据恢复,选中要恢复的数据然后点击右边导入,点击确定即可恢复数据,为了安全起见当成功恢复数据后进入FTP删除/data/restore.php这个文件。 有时候进入之后数据恢复,发现没有可供还原的数据,那么你可以看到下面这一行文字,那你直接点击你的网址在浏览器当中恢复数据即可,为了安全起见当成功恢复数据后进入FTP删除/data/restore.php这个文件。 您可以在本页面数据备份记录处导入备份恢复数据,也可以通过在浏览器中执行 http://www.你的域名.com/data/restore.php 恢复数据 第八步:检查UCenter能否登陆 提示:1、检查UCenter 访问地址设置是否正确(没有更换域名做第六步安装,一般不会出错) 2、创始人密码和admin管理员密码不是同一个,创始人密码是上面第六步重新安装discuz程序时设置的密码。 第九步:检查UCenter应用是否通讯成功 后台——UCenter——应用管理,查看通讯情况,若通讯失败,请检查通信密钥设置是否相同。 后台——站长——UCenter设置,检查UCenter 通信密钥是否和UCenter应用设置相同 第十步:更新缓存 数据还原成功之后,在后台退出帐号,用你原来的后台管理员帐号登陆,进入后台更新缓存,网站搬家成功结束。

    02

    存储知识:数据一致性、分级存储、分层存储与信息生命周期管理

    一、概述 数据一致性是指关联数据之间的逻辑关系是否正确和完整。问题可以理解为应用程序自己认为的数据状态与最终写入到磁盘中的数据状态是否一致。比如一个事务操作,实际发出了五个写操作,当系统把前面三个写操作的数据成功写入磁盘以后,系统突然故障,导致后面两个写操作没有写入磁盘中。此时应用程序和磁盘对数据状态的理解就不一致。当系统恢复以后,数据库程序重新从磁盘中读出数据时,就会发现数据再逻辑上存在问题,数据不可用。 二、Cache引起的数据一致性问题 引起数据一致性问题的一个主要原因是位于数据I/O路径上的各种Cache或Buffer(包括数据库Cache、文件系统Cache、存储控制器 Cache、磁盘Cache等)。由于不同系统模块处理数据IO的速度是存在差异的,所以就需要添加Cache来缓存IO操作,适配不同模块的处理速度。这些Cache在提高系统处理性能的同时,也可能会“滞留”IO操作,带来一些负面影响。如果在系统发生故障时,仍有部分IO“滞留”在IO操作中,真正写到磁盘中的数据就会少于应用程序实际写出的数据,造成数据的不一致。当系统恢复时,直接从硬盘中读出的数据可能存在逻辑错误,导致应用无法启动。尽管一些数据库系统(如Oracle、DB2)可以根据redo日志重新生成数据,修复逻辑错误,但这个过程是非常耗时的,而且也不一定每次都能成功。对于一些功能相对较弱的数据库(如SQL Server),这个问题就更加严重了。 解决此类文件的方法有两个,关闭Cache或创建快照(Snapshot)。尽管关闭Cache会导致系统处理性能的下降,但在有些应用中,这却是唯一的选择。比如一些高等级的容灾方案中(RPO为0),都是利用同步镜像技术在生产中心和灾备中心之间实时同步复制数据。由于数据是实时复制的,所以就必须要关闭Cache。 快照的目的是为数据卷创建一个在特定时间点的状态视图,通过这个视图只可以看到数据卷在创建时刻的数据,在此时间点之后源数据卷的更新(有新的数据写入),不会反映在快照视图中。利用这个快照视图,就可以做数据的备份或复制。那么快照视图的数据一致性是如何保证的呢?这涉及到多个实体(存储控制器和安装在主机上的快照代理)和一系列的动作。典型的操作流程是:存储控制器要为某个数据卷创建快照时,通知快照代理;快照代理收到通知后,通知应用程序暂停IO操作(进入 backup模式),并flush数据库和文件系统中的Cache,之后给存储控制器返回消息,指示已可以创建快照;存储控制器收到快照代理返回的指示消息后,立即创建快照视图,并通知快照代理快照创建完毕;快照代理通知应用程序正常运行。由于应用程序暂停了IO操作,并且flush了主机中的 Cache,所以也就保证了数据的一致性。 创建快照是对应用性能是有一定的影响的(以Oracle数据库为例,进入Backup模式大约需要2分钟,退出Backup模式需要1分钟,再加上通信所需时间,一次快照需要约4分钟的时间),所以快照的创建不能太频繁。 三、时间不同步引起的数据一致性问题 引起数据不一致性的另外一个主要原因是对相关联的多个数据卷进行操作(如备份、复制)时,在时间上不同步。比如一个Oracle数据库的数据库文件、 Redo日志文件、归档日志文件分别存储在不同的卷上,如果在备份或复制的时候未考虑几个卷之间的关联,分别对一个个卷进行操作,那么备份或复制生成的卷就一定存在数据不一致问题。 此类问题的解决方法就是建立“卷组(Volume Group)”,把多个关联数据卷组成一个组,在创建快照时同时为组内多个卷建立快照,保证这些快照在时间上的同步。之后再利用卷的快照视图进行复制或备份等操作,由此产生的数据副本就严格保证了数据的一致性。 四、文件共享中的数据一致性问题 通常所采用的双机或集群方式实现同构和异构服务器、工作站与存储设备间的数据共享,主要应用在非线性编辑等需要多台主机同时对一个磁盘分区进行读写。

    03
    领券