测验考试在线形式修改网页数据库

对付运维来讲，对数据库形式进行更新，是许多十分坚苦的任务之一。将数据库形式与其余更新一块儿进行同步，有几种常见的情形:部署、疾速开发、经由过程修改索引和其余结构优化机能。假设形式更新是一种梗阻操纵(mysql中常规就是如许的)，这就真的成问题了。
将表做得小一点是有很大益处的。存档或删除数据是连结小表的好要领，但另有其余要领，比方，假设应用是分片架构，则将每一个分片做得足够小，从而使得每一个表都不会变得很大。也能够将数据分赴任别的表中，如对付基于日期的数据，天天都创立一个新表。这里的大大都倡议都是比力极真个，其实不引荐处处应用，但假设加之一点缔造性的话，则可以走得更远一点。
innodbi的新版本(称为 innodb插件)，以及xtradb，提供在线添加或删除索引的威力，并且速率很快。这一点的确很好。我依然记得，第一次计较索引更新需求停机多永劫间的情形:客户给了我一个小时，而后运转更新索引的号令，仅仅花了30秒钟，而我记得他们用的是innodb插件。假设你尚未效过的话，我想innodb插件版本(或 xtradb)是一次至关惹人瞩目的降级。
若是表不是足够小，则这些类型的操纵都是不行能的。这个时辰，就需求另设法子。经由过程创立一个有着所需结构的“影子表”，借助于外部工具，在末了时刻对表进行互换与重定名，尽管实际上可行，我依然不以为如许做对每种情形都是可行的解决计划。以是，依然有大量的情况，此中，互换服务器都是首选的计划。
普通的设法是配置主一主复制对，当然此中只要一台服务器可写。在只读服务器上执行更新，但不要复制到可写服务器上。可以经由过程禁止将更新写入日记，或在可写服务器上遏制复制过程来实现。更新一旦完成，则用正常体式格局使应用程序实现失效转移，如许，读者和写者就实现了脚色变换。而后在另外一台网站制作服务器上反复执行更新逐个或许只需求重启复制过程。运用这类体式格局，就实现了对应用程序隐含宕机时间的目的。