Warning: file_get_contents(/data/phpspider/zhask/data//catemap/8/mysql/70.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181

Warning: file_get_contents(/data/phpspider/zhask/data//catemap/8/mysql/63.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Mysql 如何在实时数据库上运行大型更新?_Mysql_Database_Scalability - Fatal编程技术网

Mysql 如何在实时数据库上运行大型更新?

Mysql 如何在实时数据库上运行大型更新?,mysql,database,scalability,Mysql,Database,Scalability,我正在编写的一个web项目使用复杂的CSV到MySQL转换器来创建他们的数据库。这意味着,为了使用CSV的最新更改更新db内容,将运行一个转换器,该转换器将截断相关表(但保留通过网站填充的其他表),并使用CSV的数据再次填充这些表 是的,这不是一个很好的过程,但是选择这种方法而不是标准的“处理实际数据库”方法有很好的理由 我正在努力的是找出运行此更新过程的最佳方法,而不会对用户体验造成太大伤害。要记住的几个数字: 1) 此过程必须定期运行,每几周/每月一次 2) db转换器目前大约需要一个小时,

我正在编写的一个web项目使用复杂的CSV到MySQL转换器来创建他们的数据库。这意味着,为了使用CSV的最新更改更新db内容,将运行一个转换器,该转换器将截断相关表(但保留通过网站填充的其他表),并使用CSV的数据再次填充这些表

是的,这不是一个很好的过程,但是选择这种方法而不是标准的“处理实际数据库”方法有很好的理由

我正在努力的是找出运行此更新过程的最佳方法,而不会对用户体验造成太大伤害。要记住的几个数字:

1) 此过程必须定期运行,每几周/每月一次
2) db转换器目前大约需要一个小时,将来可能需要15个小时,至少如果对数据库增长的预测是正确的(是的,哎哟!)
3) 完整数据库的sql转储目前不足20MB(这允许通过phpmyadmin轻松导入),但很快就会打破这一障碍。我想这应该不是问题,因为我可以使用SSH上传

下面是我想到的一些备选方案,所有这些方案都使用一个单独的数据库和全局设置(这些设置在站点上的每次读/写都会被检查)。备选方案2似乎是最糟糕的,因为它在整个转换过程中都会阻止读取访问,正如我所说的,这段时间可能相当长。它们都会在相同的时间内阻止写访问,虽然这很好,但不会阻止用户注册或任何类似的重要操作。我很好奇第三种选择的可行性,因为理论上它可以缩短读取功能的停机时间,因为我不需要上传一个大的转储文件

有人做过这样的事吗?如果有更好的选择,或者有任何关于如何改进这些以及是否选择1或3的反馈,我将不胜感激。提前感谢:)

备选方案1
1) 将全局设置布尔值可写设置为0
2) 下载当前数据库(SQL转储)
3) 本地导入下载的数据库
4) 在本地数据库上运行转换器(在更新模式下)
5) 导出本地数据库
6) 将全局设置布尔值可读设置为0
7) 联机导入导出的数据库
8) 将全局设置布尔值可读设置为1
9) 将全局设置布尔值可写设置为1

备选方案2
1) 将全局设置布尔值可写设置为0
2) 将全局设置布尔值可读设置为0
3) 在实时数据库上运行转换器(在更新模式下)
4) 将全局设置布尔值可读设置为1
5) 将全局设置布尔值可写设置为1

备选方案3
1) 将全局设置布尔值可写设置为0
2) 创建数据库的远程副本
3) 在远程拷贝上运行转换器(在更新模式下)
4) 将全局设置布尔值可读设置为0
5) 用远程副本替换远程原件(简单?)
6) 将全局设置布尔值可读设置为1

7) 将globalsettings_booleans_writeable设置为1在我看来,通过检查CSV以查看哪些记录实际会导致数据库更改,可以避免很多排他性。CSV生成器似乎是数据的实际来源,而数据库只是数据的镜像,对吗

如果是这样,则不会导致任何更改的CSV记录可以被忽略,d/b表不会被截断,剩余的CSV记录可以使用备选方案2运行,这大概只需要几分钟


这种方法的主要缺点是如果在源位置删除记录,并且没有迹象表明d/b需要在本地删除记录。

只是为了确保没有误解:没有CSV生成器。CSV是手动创建/更新的,然后通过Java工具转换为数据库。因此,源是由转换器安装在db中的CSV。无论如何,你绝对正确地建议最好的方法是通过只更改必要的内容而不是截断和创建来加快转换器的速度。不幸的是,这几乎是不可能的(是的,在CSV中删除,就像你所说的,还有其他问题),如果不是这样的话,那么这将非常复杂,并且非常容易出错。所以我不想这样。对当前数据库进行了什么样的转换?数据本身是在改变还是结构在改变?