tomcat怎么连接mysql

1、安装mysql,并创建数据库和数据表，并插入用户名和密码。

2、然后安装tomcat。

3、修改默认端口号为8010。

4、数据库驱动放到目录：D:\Program Files\Apache Software Foundation\Tomcat 8.0\lib。

5、修改文件tomcat-users.xmlD:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat-users.xml。

6、浏览器中输入：http://localhost:8010/testjdbc.jsp，验证tomcat能否连接mysql，testjdbc.jsp的信息如下所示。

对于组复制这样的集群来说，主要的需求之一就是整个集群内部需要有数据的一致性保证。换句话说，需要保证在集群内不同节点之间的事务的全局一致性。

在单主模式的集群中，如果发生 primary 节点故障转移，将其中一个辅助节点提升为读写节点，对于存在积压事务的（新的 primary 节点和旧的 primary 节点的数据不是追评的状态）情况下新的 primary 节点如何处理新写入的事务，有两种可选的处理方式：

新的primary节点可以立即处理新写入的事务，或者限制该节点的访问，直到队列里积压的事务被应用完毕，集群数据处于追平的状态时，新的primary节点才能开始处理新写入的事务。

例如，如果客户端C1刚好在故障发生前在旧的primary节点上写了A = 2 WHERE A = 1，则当客户端C1重新连接到新的primary节点时，它可能会读取到A = 1，直到新的primary节点应用完队列里积压的事务并追上旧primary节点离开集群之前的状态。

在MySQL 8.0.14之前，不支持配置故障转移策略，默认情况下，采用第一种策略。在MySQL 8.0.14及更高版本中可以使用系统变量group_replication_consistency配置集群节点在primary节点故障转移期间提供的事务一致性保证策略。

由于对集群执行读写 *** 作，因此数据流与集群一致性保证有关，尤其是当这些 *** 作分布在所有节点上时。数据流 *** 作适用于组复制的两种模式：单主模式和多主模式，但是为了使说明更清楚，它仅限于单主模式。

在单主集群的节点之间，通常情况下读事务个写事务会进行严格的划分，将写事务路由到primary节点，然后将读事务平均分配给secondary节点。对于组复制来说，可能存在多个MySQL Server，但是，对应用程序来说，它是作为一个整体对外提供服务，因此，对于应用来说，在primary节点上写入的数据可以在secondary节点上即时查询。

尽管组复制是使用基于Paxos算法的组通讯系统（GCS）协议编写的，但是组复制的某些流程部分是异步的，这意味着primary节点写入的事务在secondary节点中是异步应用的，因此可能出现这样的情况：客户端C2在primary节点上写入B=2 where B=1（将B=1修改为B=2），然后，客户端C2立即连接到其他辅助节点中执行查询可能会读取到B=1，这是由于该事务在secondary节点中可能处于积压状态（在secondary节点中还未来得及应用）。

集群中的访问读多写少，希望在读写事务提交后就应用于所有组成员，以便后续的读取 *** 作能够读取到最新的数据（包括发起事务写入的成员）。这样可确保每个RO事务执行不受到影响，而只影响RW事务的提交时长。

希望工作负载中的特定事务始终从集群中读取最新数据，例如：每当敏感数据被更新时（例如文件或类似数据的凭据）希望强制读取最新数据。

我们可以通过配置 ***group_replication_consistency*** 变量的值来控制事务的一致性级别，可以在session级别根据具体的需求针对某个事务进行设置，可以使用不同的设置来灵活的控制集群中事务一致性的保证。该参数值有如下选项：

RO和RW事务在执行之前都不会等待前面积压的事务回放完成。这是 group_replication_consistency 变量的默认值。RW事务不等待其他节点应用事务。这意味着如果发生primary节点故障转移，则新的primary节点可以先不应用来自于旧的primary节点积压的事务，直接接受新的RO和RW事务。这可能会导致新的 RO事务可能会读取到旧的数据，RW事务可能会由于冲突而导致回滚。

该一致性级别的原理图如下所示：

概述：

事务T1（一致性级别为EVENTUAL）从节点M1开始执行。

事务T1执行到提交点(commit)时，在这里会将事务的变更数据广播发送给集群内所有节点。

事务T1被集群中的所有节点接收到之后，所有节点都会各自对其进行冲突认证检测：如果存在冲突，则对于M1来说，回滚T1事务，对于M2和M3来说，丢弃接收到的T1事务数据包；如果不存在冲突，则对于M1来说，提交T1事务，对于M2和M3来说，对T1事务进行排队等待执行与提交。

事务T2（一致性级别为BEFORE）从节点M3上开始执行，在T2执行之前，会向集群内所有节点发送一条消息，该消息提供了T2事务的全局顺序（从上图中我们可以得知，T1事务的全局顺序在T2之前，因为T1事务先执行）。

集群中的所有节点收到并按顺序处理该消息时，M3将从消息流中获取组复制应用程序的RECEIVED_TRANSACTION_SET（RECEIVED_TRANSACTION_SET是被允许提交的远程事务的集合，无论这些事务是否实际上已经提交，它们都包含在此集合中）。该集合提供了在T2事务之前存在的所有远程事务，由于Server已经确保了本地事务的一致性，所以这里只需要跟踪远程事务。尽管M3之前已经将包含了T2事务的全局顺序的消息发送给了集群中的所有节点，但是只有M3才需要对其进行 *** 作，因此其他节点会丢弃该消息而不采取任何行为。

在M3中，在应用（提交）完成了RECEIVED_TRANSACTION_SET中所有的远程事务之后，事务T2才开始执行，这与可以确保T2不会读取或执行对于全局顺序（这里的全局顺序为：T1->T2）来说已经过时的数据。这种等待仅发生在执行了一致性级别为BEFORE的事务的Server上（这里为执行了一致性级别为BEFORE的T2事务的节点M3），对于组中的其他集群节点（这里指M1和M2）不受此等待的影响。

一旦T2事务开始执行，接下来就会按照步骤2和步骤3继续往下执行。

PS：对于BEFORE这个一致性级别，它涵盖了BEFORE_ON_PRIMARY_FAILOVER提供的一致性保证。

概述：

事务T1（一致性级别为AFTER）从节点M1开始执行。 事务T1执行到提交点(commit)时，在这里会将事务的变更数据广播发送给集群内所有节点。

事务T1被集群中的所有节点接收到之后，所有节点都会各自对其进行冲突认证检测：如果存在冲突，则对于M1来说，回滚T1事务，对于M2和M3来说，丢弃接收到的T1事务数据包；如果不存在冲突，则进入步骤4。在其他节点上（这里指M2和M3），T1事务被排队执行，一旦事务进入prepare阶段（即，数据在等待commit指令的存储引擎上持久化完成），它将向所有的成员发送ACK确认。

一旦所有的节点都接收到来自所有成员的ACK确认（对于M1来说，T1事务是由它自己发起，所以已经隐含确认了prepare状态），此时，所有节点都将继续执行T1事务的提交 *** 作(commit)。

事务T2（一致性级别为EVENTUAL）从节点M3开始执行，此时由于T1事务正在提交过程中（还未提交完成），所以T2事务会持续等待T1事务完成之后才开始执行，这样，就可以确保T1事务之后的任何事务都将读取到T1的最新数据。一旦事务T2开始执行，接下来就会按照"EVENTUAL概述"中的步骤2和步骤3继续往下执行（注意，由于T2事务的一致性级别是EVENTUAL，所以T2事务的后续步骤不会按照"AFTER概述"中的步骤2和步骤3往下执行）。

PS：对于AFTER这个一致性级别，它涵盖了BEFORE_ON_PRIMARY_FAILOVER提供的一致性保证。

- BEFORE_AND_AFTER

一致性级别要求最高，RW和RO事务执行时都要求数据同步，RW事务在执行时需要等待之前的积压事务应用完成，且需要等待自己的数据变更在集群其他所有节点上都应用完成。RO事务在执行时需要等待之前的积压事务应用完成。该一致性级别适合对数据的读写一致性都要求高的场景。BEFORE_AND_AFTER一致性级别的原理图如下所示：

概述：

一致性级别BEFORE和BEFORE_AND_AFTER都可以用于RO和RW事务。但AFTER一致性级别对RO事务没有影响，因为RO事务不会产生数据变更。

如下建议提供了一个根据集群的使用方式来选择不同的一致性级别的方案：

如果将一致性级别设置为全局范围，则会对集群性能产生负面影响。因此，除非必须，否则建议只在会话级别根据需要动态使用系统变量group_replication_consistency来配置集群的一致性级别。

修改某个会话的一致性级别：

修改全局的一致性级别：

注意：所有RW事务在组中都是全局排序的，所以，一旦在当前会话中设置会话级别的一致性级别为AFTER，则在该会话中执行RW事务时会等待其他成员应用完成该事务。也就是说，由于RW事务全局是排序的，而该RW事务是后发起的，所以，实际上等于还需要同时等待该RW事务之前所有的积压事务应用完成，而不仅仅只是该RW事务。

对于BEFORE一致性级别，除了在事务流上排序之外，它只影响本地成员，即，它不需要协调其他成员，也不影响其他成员的事务。换句话说，BEFORE一致性级别只影响使用该一致性级别的事务。

AFTER 和 BEFORE_AND_AFTER 一致性级别对在其他成员上执行的并发事务具有副作用，当执行具有 AFTER 或 BEFORE_AND_AFTER 一致性级别的事务时，即使后续的事务是以EVENTUAL一致性级别运行的也仍然需要等待 AFTER 或 BEFORE_AND_AFTER 一致性级别的事务执行完成。对于其他成员也是如此。

为了进一步说明这一点，请想象一个由3个节点M1，M2和M3组成的集群。在节点M1上执行如下 *** 作：

然后，在应用上述事务时，在节点M2上执行如下 *** 作：

执行DML事务，就可以发现M2执行的事务被阻塞，需要等待上述执行先执行完成。需要注意的是，如果在M2执行事务时，M1中的事务还没有被M2收到时，select语句是可以立即执行成功的，但如果M1中的事务被M2收到并进入队列之后，执行select ... for update语句也会被阻塞。

在这种情况下，即使第二个事务的一致性级别为EVENTUAL，也因为它在第一个事务已经在M2上的提交阶段时开始执行，所以第二个事务必须等待第一个事务完成提交，然后它才能正确执行。

只能在ONLINE节点上使用一致性级别 BEFORE，BEFORE_AND_AFTER ，尝试在其他状态的成员上使用这些级别会导致一个错误。

一致性级别不是EVENTUAL的事务执行时，会一直等待且没有返回结果，直到达到由 wait_timeout 值配置的超时（默认为8小时）。如果达到超时，则抛出ER_GR_HOLD_WAIT_TIMEOUT错误。

本节描述集群的一致性级别如何影响单主集群故障转移后新的primary节点的选举。这样的集群会自动检测故障并调整活跃节点的视图，换句话说，成员资格配置。此外，如果以单主要模式部署组，则只要该组的成员身份发生更改，就会执行检查以检测该组中是否仍存在primary节点。如果没有，则从secondary节点列表中选择一个新的primary节点。通常，这个过程就是选举一个secondary节点成为一个primary节点的过程。

当系统检测到故障并自动重新配置时，用户也许希望一旦secondary节点晋升完成，则新的primary节点与旧的primary节点之间的数据状态相同。换句话说，希望新的primary节点能够对外提供读写访问时，就已经应用完成了所有积压事务，即，一旦应用程序完成了故障转移到新的primary节点时，就不会读取到陈旧的数据记录。

从MySQL 8.0.14版本开始，secondary节点晋升为primary节点之后，可以指定新primary节点的行为，通过新增的系统变量group_replication_consistency来控制新的primary节点采用什么一致性级别（默认为EVENTUAL），如果设置为BEFORE_ON_PRIMARY_FAILOVER，则在对外提供读写访问之前，会先应用完成积压事务。这就确保了客户端完成了故障转移到新primary节点之后，能够查到最新数据。同时，也可以防止出现下列不正常的现象：

RO和RW事务不会读取到陈旧的数据，这可以防止这些陈旧数据被应用程序访问到。

不会导致新执行的RW事务发生回滚，这是因为与远程事务存在写冲突的新的RW事务此时会处于待处理状态，需要先应用积压事务才会处理新的RW事务。

读写事务不会发生读偏差（不会读取到陈旧的数据），如：

假设x=1在t1表中，x=2还在积压事务中，那么，在这里需要等待积压事务应用完成，才能执行查询，以便读取到最新的数据x=2

以上事务如果不使用 BEFORE_ON_PRIMARY_FAILOVER 一致性级别，那么，将导致插入t2表中的值为x=1，而不是x=2（因为发生了读偏差），但是，无论是否设置为 BEFORE_ON_PRIMARY_FAILOVER 一致性级别，都不会导致写冲突，而最多只会发生读偏差，从而导致写入t2表的数据不是最新的。

为了确保集群中所有的节点无论谁被晋升为新的primary节点之后，都会提供相同的一致性级别，集群的所有节点都应该在配置中持久化一致性级别为BEFORE_ON_PRIMARY_FAILOVER（或更高的一致性级别）。这可以防止应用程序故障转移完成之后查询到陈旧的数据，设置语句如下：

上述语句执行完成之后，该系统变量值会被持久化到auto.cnf文件中（该文件是一个JSON格式数组，且其中已经存在了组辅助的一些预设持久化变量，注意：对于使用 SET PERSIST语句持久化系统变量的 *** 作，只会影响到当前成员，其他成员不会进行同步，所以，建议在集群所有节点中都执行相同的 *** 作）。

这样可以确保成员的行为均相同，并且在重新启动成员后仍保留配置。

总而言之，当group_replication_consistency设置为BEFORE_ON_PRIMARY_FAILOVER时，选择优先考虑一致性而不是可用性，因为无论何时选择新的primary节点，都会进行读写 *** 作。这是在配置集群时必须考虑的权衡。还应记住，如果流控正常运行，则积压应该最少。请注意，较高的一致性级别BEFORE，AFTER和BEFORE_AND_AFTER还包括BEFORE_ON_PRIMARY_FAILOVER提供的一致性保证。

尽管在使用BEFORE_ON_PRIMARY_FAILOVER一致性级别时，在未应用完成所有的积压事务之前，所有的写 *** 作都会进入等待状态，但并不是所有的读 *** 作都被阻塞，对于一些不修改数据的查询是允许执行的（例如：对于一些状态表的查询等，这对一些问题排查和性能监控非常有用）。

SHOW 语句

SET 语句

DO 语句

EMPTY 语句

USE 语句

对performannce_schema和sys_schema使用 SELECT 语句

对informationn_schema.processlist表使用SELECT 语句

对不指定表的用户自定义函数使用SELECT 语句

STOP GROUP_REPLICATION 语句

SHUTDOWN 语句

RESET PERSIST 语句

事务不能永远处于待处理状态(on-hold)，如果处于该状态的时间超过系统变量wait_timeout设置的值，则会返回ER_GR_HOLD_WAIT_TIMEOUT错误信息。

致此，在MGR8.0中，故障转移时的事务一致性保障到此结束。

可以。在tomcat软件中可以使用mysql8指令进行快捷 *** 作，Tomcat是Apache软件基金会的Jakarta项目中的一个核心项目，由Apache、Sun和其他一些公司及个人共同开发而成。

---