caching_sha2_password认证插件提供更多的密码加密方式,并且在加密方面具有更好的表现,目前MySQL 80选用caching_sha2_password作为默认的认证插件,MySQL 57的认证插件是MySQL_native_password。如果客户端版本过低,会造成无法识别MySQL 80的加密认证方式,最终导致连接问题。
MySQL存储引擎现在负责提供自己的分区处理程序,而MySQL服务器不再提供通用分区支持,InnoDB和NDB是唯一提供MySQL 80支持的本地分区处理程序的存储引擎。 如果分区表用的是别的存储引擎,存储引擎必须进行修改。要么将其转换为InnoDB或NDB,要么删除其分区。通过MySQLdump从57获取的备份文件,在导入到80环境前,需要确保创建分区表语句中指定的存储引擎必须支持分区,否则会报错。
MySQL 80的默认字符集utf8mb4,可能会导致之前数据的字符集跟新建对象的字符集不一致,为了避免新旧对象字符集不一致的情况,可以在配置文件将字符集和校验规则设置为旧版本的字符集和校验规则。
MySQL 80启动使用的lower_case_table_names值必须跟初始化时使用的一致。使用不同的设置重新启动服务器会引入与标识符的排序和比较方式不一致的问题。
< lower_case_table_names >
>
要避免MySQL 80上的启动失败,MySQL配置文件中的sql_mode系统变量不能包含NO_AUTO_CREATE_USER。
从MySQL 5724和MySQL 8013开始,MySQLdump从存储程序定义中删除了NO_AUTO_CREATE_USER。必须手动修改使用早期版本的MySQLdump创建的转储文件,以删除NO_AUTO_CREATE_USER。
在MySQL 8011中,删除了这些不推荐使用的兼容性SQL Mode:DB2,MAXDB,MSSQL,MySQL323,MySQL40,ORACLE,POSTGRESQL,NO_FIELD_OPTIONS,NO_KEY_OPTIONS,NO_TABLE_OPTIONS。从57到80的复制场景中,如果语句使用到废弃的SQL Mode会导致复制异常。
在执行到MySQL 803或更高版本的in-place升级时,BACKUP_ADMIN权限自动授予具有RELOAD权限的用户。
本文对MySQL 57到MySQL 80的升级过程中出现部分易出现问题进行整理:升级对MySQL版本的要求、升级都做了哪些内容、数据库升级做了哪些步骤以及注意事项,希望对大家版本升级有帮助。
开始菜单--->程序,打开SQL Server Management Studio(即我们的SQL 2005)
连接服务器后,找到我们需要迁移的数据,右键点击属性
在数据库属性里面,点击文件,可查看数据库文件和数据库日志文件的存放路径
确定没有任何其它用户连接到此数据库后,点击该数据库-->任务-->分离
我们可以看到分离以后,刚刚那个数据库,已经不在此列表
进入刚刚我们第3步属性里面看到的数据库文件路径如下图把我们的ZNLCRMmdf数据库文件和ZNLCRM_LogLdf数据库日志文件拷贝到另外一台服务器
在另外台服务器上打开SQL数据库与第1步一样点击数据库--->附加
在附加数据库里面,点击添加,如下图所示
找到刚刚拷贝过来的ZNLCRMmdf文件选中该文件,依次点击确定(注意日志文件会自动一起加载过来)
然后我们就可以看到,一个完整的数据库就直接被迁移过来如下图
如果要快的话可以这样,作个参考吧:1首先把新服务器安装好 *** 作系统按老服务器分好磁盘分区(c,d,e等盘符保持一致)
2把老服务器上除系统盘(c盘)以外的盘上的数据全部复制到新服务器的对应盘上(通过网络共享复制或通过rsync将数据同步过来)
3数据同步完成后把老服务器的 *** 作系统做一个ghost备份恢复到新服务器的C盘上。
4启动新服务器(如果启动正常应该所有的ad,dns等都是可用的,如果新服务器的某些硬件没有驱动,找新服务器的驱动光盘驱动一下就可以了。)
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)