189 8069 5689
1、同时按下键盘上的win＋r按键，调出运行框，并在弹出的运行框中输入cmd后按下回车按键。
德兴网站制作公司哪家好，找创新互联公司！从网页设计、网站建设、微信开发、APP开发、响应式网站开发等网站项目制作，到程序开发，运营维护。创新互联公司从2013年成立到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选创新互联公司。
2、在弹出的页面中输入mysql -u root -p命令，并点击键盘上的回车按键。
3、在弹出的页面中输入需要查询的账号的密码并按下键盘上的回车按键。
4、这样就可以查看到所有的数据库。
1、先链接进主库
2、点击查询》输入：show databases;》执行
如果是linux下面的：
先链接进主库，进入XX库》use XX》输入 show tables; 回车
在实际的生产中，为了解决Mysql的单点故障，一般都会采用「主备模式」。
MySQL几乎所有的高可用架构，都直接依赖于 binlog。虽然这些高可用架构已经呈现出越来越复杂的趋势，但都是从最基本的一主一备演化过来的。
下图为主备切换流程
在状态 1 中，客户端的读写都直接访问节点 A，而节点 B 是 A 的备库，只是将 A 的更新都同步过来，到本地执行。这样可以保持节点 B 和 A 的数据是相同的。
当需要切换的时候，就切成状态 2。这时候客户端读写访问的都是节点 B，而节点 A 是 B 的备库。
在状态 1 中，虽然节点 B 没有被直接访问，但是依然建议把节点 B（也就是备库）设置成只读（readonly）模式。这样做，有以下几个考虑：
图下图 中画出的就是一个 update 语句在节点 A 执行，然后同步到节点 B 的完整流程图。
备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程，专门用于服务备库 B 的这个长连接。一个事务日志同步的完整过程是这样的：
在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量。
在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io_thread 和 sql_thread。其中 io_thread 负责与主库建立连接。
主库 A 校验完用户名、密码后，开始按照备库 B 传过来的位置，从本地读取 binlog，发给 B。
备库 B 拿到 binlog 后，写到本地文件，称为中转日志（relay log）。
sql_thread 读取中转日志，解析出日志里的命令，并执行。
主库需要复制新增binlog到从库才能完成同步，这个同步过程就是同步延迟。主从延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产 binlog 的速度要慢。
「同步策略」：Master会等待所有的Slave都回应后才会提交，这个主从的同步的性能会严重的影响。
「半同步策略」：Master至少会等待一个Slave回应后提交。
「异步策略」：Master不用等待Slave回应就可以提交。
「延迟策略」：Slave要落后于Master指定的时间。
对于不同的业务需求，有不同的策略方案，但是一般都会采用最终一致性，不会要求强一致性，毕竟强一致性会严重影响性能。
很多时候需要把一个从库提升为主库，但对从库和主库的数据一致性不敢保证，这时我们就可以利用 pt-table-checksum来检查主库数据的一致性，如果存在不一致的数据，我们可以利用pt-table-sync来修复这些不一致的数据。
在主（master）上通过执行校验的查询对复制的一致性进行检查，对比主从的校验值，从而产生结果。
下面通过实际的例子来解释该工具如何使用：
主库（10.8.23.209）数据：
从库（10.8.23.208）数据：
从库（10.8.23.210）数据：
很明显主备数据不一致，我们使用工具来检测下：
校验命令参数解释：
校验结果字段解释：
好了，命令以及常用参数都介绍了，一起解释下上面执行的效果，通过DIFFS 是1 就可以看出主从的表数据不一致。怎么不一致呢？ 通过指定—replicate=test.checksums 参数，就说明把检查信息都写到了checksums表中。
进入备库（10.8.23.208）中查看checksums表的信息：
进入备库（10.8.23.210）中查看checksums表的信息：
通过上面找到了这些不一致的数据，如何修复呢？利用另外一个工具 pt-table-sync。
高效的同步MySQL表之间的数据，他可以做单向和双向同步的表数据。他可以同步单个表，也可以同步整个库。它不同步表结构、索引、或任何其他模式对象。所以在修复一致性之前需要保证他们表存在。接着上面的复制情况，主库和从库的aaa表数据不一致，需要修复。
参数解释：
命令介绍完了，一起解释下执行的效果：通过（--print）打印出来了修复数据的sql语句，可以手动的去从行执行，让他们数据保持一致性。那能否直接执行？当然可以，通过(--execute)
没发现任何异常，然后检查主从数据的一致性：
主库（10.8.23.209）数据：
从库（10.8.23.208）数据：
从库（10.8.23.210）数据：
OK，数据已经保持一致了。
不过建议还是--print 打印出来的好，这样就可以知道那些数据有问题，可以人为的干预下。
不然直接执行了，出现问题之后不好处理。总之还是在处理之前做好数据的备份工作。