NDB存储引擎也叫NDB Clister 存储引擎，主要用于MySQL Cluster分布式集群环境，Cluster是MySQL从5.0版本才开始提供的新功能，本文并不只是介绍NDB存储引擎，因为离开了MySQL Cluster整个环境，NDB存储引擎也将失去太多意义。

    简单地说，MySQL Cluster就是在无共享存储设备的情况下实现的一种内存数据库Cluster环境，主要是通过NDB Clister 存储引擎来实现的。

    一般来说，一个MySQL Cluster的环境主要由以下三部分组成。

MySQL物理备份所需文件主要包括以下三个方面：MyISAM存储引擎、InnoDB存储引擎、NDB Cluster存储引擎。

    1、MyISAM存储引擎

    MyISAM存储引擎的所有数据都存放在MySQL配置设定的“datadir”目录下。实际上不管使用的是MyISAM存储引擎还是其他任何存储引擎，每一个数据库都会“datadir”目录下有一个文件夹。在各个数据库中每一个MyISAM存储引擎表都会有三个文件存在，分别为记录表结构元数据的“.frm”文件、存储表数据的“.MYD”文件，以及存储索引数据的“.MYI”文件。由于MyISAM属于非事务性存储引擎，所以它没有自己的日志文件。所以MyISAM存储引擎在做物理备份时，除了备份MySQL系统共有的物理文件之外，就只需要备份上面的三种文件。

任何一个系统的硬件环境都会对性能起到非常关键的作用，这一点我想每一位朋友都是非常清楚的。而在数据库应用系统环境中，数据库自身的特点和在系统中的角色决定了它是整个系统中最难以扩展的部分。所以在大多数环境下，数据库服务器主机（或者主机集群）的性能在很大程度上决定了整个应用系统的性能。

    既然数据库主机资源如此重要，肯定很多朋友会希望知道，数据库服务器主机的各部分硬件到底谁最重要，它们对整体性能的影响各自占的比例是多少，以便能够根据这些比例选取合适的主机机型。但是我只能很遗憾的告诉大家，没有任何一个定律或法则可以很准确地给出这个答案。

数据的垂直切分，也可以称为纵向切分，将数据库想象成由很多个一大块一大块的“数据块”（表）组成，垂直地将这些“数据块”切分，然后把它们分散到多台数据库主机上面。这样的切分方法就是垂直（纵向）切分。

    一个架构设计较好的应用系统，其总体功能肯定是由很多个功能模块所组成的，而每一个功能模块所需要的数据对应到数据库中就是一个或多个表。而在架构设计中，各个功能模块相互之间的交互点越统一、越少，系统的耦合度就越低，系统各个模块的维护性及扩展性也就越好。这样的系统，实现数据的垂直切分也就越容易。

数据库主要是为应用程序提供数据存取相应的服务，提高数据库的扩展性，也是为了更好地提供数据存取服务能力，同时包括可靠性、高效性及易用性。所以，最根本的目的就是让数据层的存储服务能力得到更好的扩展性，让投入尽可能与产出成正比。

    我们都明白，数据本身肯定都需要有一个可以持久化地方，但是否有必要让所有冗余数据都进行持久化呢？我想大家肯定都会觉得没有这个必要，只要保证有至少两份冗余的数据进行持久化就足够了。而另外一些为了提高扩展性而产生的冗余数据，完全可以通过一些特别的技术来替代需要持久化的数据库，如内存Cache、Search，以及磁盘文件Cache和Search，等等。

实际上，除了使用比较熟悉的第三方关键的解决方案之外，如果有一定的技术实力，还可以通过自行实现的Cache软件来达到完全相同的效果。当然，也不要被上面所说的“技术实力”吓倒，其实并没有想象中的难。只要您不一开始就希望做出一个能够解决所有问题且包含其他第三方Cache软件的所有优点，还不能遗留任何缺点的软件。从小做起，从精做起，千万别希望一口气吃成一个胖子。自主研发实现Cache服务软件的前提是系统中存在比较特殊的应用场景，通过自主研发可以最大限度地实现个性化的需求。当然，也可以针对自己的应用场景进行特定的优

在数据库运行环境中，需要关注的主机状态主要有网络通信、系统软件错误、磁盘空间、内存使用，进程数量等。

    1、网络通信
   
    网络通信可以说是最容易检测的了，基本上只需要通过网络ping就可以获知是否正常。如果还不放心，或者所属网段内禁止使用了ping，也可以从监控主机进行固定端口的telnet尝试或ssh登录尝试。由于网络出现故障的时候被动的信息采集方式也会失效（无法与外界通信），所以网络通信的检测主要还是依靠主动检测。

当MySQL主机达到一定规模时，基本上很难通过人工到各个主机上面来定时检查各自的状态，不论是运行状态还是性能状态。甚至不能像只有少数MySQL主机的时候那样简单地通过发送邮件的方式将相关信息发出。毕竟，量大了之后，检查邮件的时间成本也是很大的。这时候就需要进行统一的监控信息采集、分析、存储、处理来帮助我们过滤可以忽略的正常信息，并画出相关信息的趋势图，以帮助判断系统的运行状况和发展趋势。

    系统监控在很多人眼中是一个没有多少技术含量的事情，其实并非如此。且不说一个大型网站的所有设备的监控，就是仅仅搭建一个比较完善的几十台MySQL集群系统的监控，很可能就会让很多人束手无策，或者功能不够完善。

我们可以使用浏览器的设置功能来禁止cookie的使用，对于程序设计人员来说，得知客户是否启用了cookie是十分重要的。因为如果用户禁用了cookie，那么对于使用了cookie的网页可能会出现访问错误。
 
       例如，如果用户禁止了cookie，而网页的程序设计却采用session来记录用户信息，并且在session实现时仍然用cookie来保存sessionID。那么，就可能发生用户已经输入了用户名和口令并通过验证之后，在进入新的网页时这些信息都丢失，又要求输入用户名和口令，会让用户觉得十分不方便。另外从服务器的角度来说，它为用户已经保存了一个session，但是因为它的sessionID并没有保存下来，导致用户进入第二个页面以后又要为它建立一个session，这样服务器端的负担就十分大。
 
       又如网页设计人员如果使用cookie来记录用户的某些偏爱，用户花了很长的时间来设定，但是下次再访问时，以前的设置因为没有保存而都不存在，这会让用户感到困惑。
 
       对于网页设计人员来说，如果用户在访问网页时出现了问题，却不知道问题产生的原因，就会让用户觉得十分不方便。设计人员可以使用cookie的功能，但是在用户禁止了这个功能时，网页的程序应该能够测试出来并告知用户问题产生的原因。如果用户希望正确访问网页，可以提示用户重新设置cookie的选项。
 
       1、使用session进行检查
 
       可以使用session对象来检查用户是否启用了会话cookie。当然，如果使用这种方法，就必须采用cookie保存sessionID的方法来实现session。由于这时session的使用是依赖于临时会话cookie的，所以当用户禁止了会话cookie时，session不起作用。这时需要程序能够测试出这个问题。
 
       使用session对象检查cookie是否禁止的技巧是在session中存储某些信息时，它可以在随后的页面中访问。如果在后面的页面中这个值不存在，那么就说明没有启用会话cookie，否则就说明启用了会话cookie。

有些时候，简单地从一个MySQL复制到另一个MySQL的基本Replication架构，可能还会需要在一些特定的场景下进行Master的切换。如在Master端需要进行一些特别的维护操作时，可能需要停止MySQL的服务。这时候，为了尽可能减少应用系统写服务的停机时间，最佳的做法就是将slave节点切换成Master来提供写入的服务。

    但是这样一来，原来Master节点的数据就会和实际的数据不一致了。当原Master启动可以正常提供服务的时候，由于数据不一致，不得不通过反转原Master-slave关系，重新搭建Replication环境，并以Master作为slave来对外提供读服务。重新搭建Replication环境会给我们带来很多额外的工作量，如果没有合适的备份，可能还会让Replication的搭建过程非常麻烦。