MySQL 允許外部連入

google "mysql 8 remote access"
google "mysql 8 remote access ssl"
google "gcp mysql 遠程連接"


MySQL 8 的新特性與解決方式
http://www.manongjc.com/article/13483.html

* 創建用戶與授權方式的改變
* 遠程連結強制加密
* 預設為 caching_sha2_password



Mysql 允許外部連入
https://contemplator.github.io/blog/2018/06/06/Mysql-%E5%85%81%E8%A8%B1%E5%A4%96%E9%83%A8%E9%80%A3%E5%85%A5/

* 修改 Mysql 設定檔 - /etc/mysql/mysql.conf.d/mysqld.cnf
註解原本的 bind-address

* 修改後需要重啟 mysql
$ sudo service mysql restart

* 開通防火牆
如果是 Google Cloud ,就是去開通防火牆端口,
如果是其他的 VPS ,則可能是參考如下: 
$ /sbin/iptables -A INPUT -i eth0 -p tcp --destination-port 3306 -j ACCEPT
eht0 是 網路卡名稱,比如說查出來的結果是 ens3
查詢的方式,在 VPS server 輸入以下指令
$ ifconfig

* 測試是否可以連到 mysql,先不論帳號密碼和權限
telnet <your-mysql-ip> 3306



如何在 Google Compute Engine 上安裝最新版 MySQL

免費 Instance 的記憶體太小不足以運作 MySQL 8,需要先規劃虛擬記憶體 Swap 以增加記憶體,否則啟動 MySQL 伺服器時會失敗:
https://21st.each1.net/2018/03/swap.html

然後以官方文件為基礎:
https://cloud.google.com/solutions/setup-mysql?hl=zh-tw

再以下篇更完整的概念去客製化:
https://www.itread01.com/article/1535250863.html

在 CLI 查詢 MySQL/MariaDB 版本 (不需要登入 MySQL):
mysql -V

以 CentOS 7 安裝 MySQL 8 為例:

# 先查出 CentOS 7 預設的資料庫 MariaDB、以及可能已安裝的 MySQL
rpm -qa | grep mysql
rpm -qa | grep mariadb

# 通過下面的命令進行刪除
sudo yum remove mysql-xxx-xxx-

然後,

1. 更新套件管理員以納入 MySQL。
sudo rpm -Uvh http://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm

2. 安裝 MySQL。
sudo yum -y install mysql-community-server

3. 啟動 MySQL 伺服器。
sudo /usr/bin/systemctl start mysqld

# 啟動成功後可以檢視 初始化密碼 ,這是在安裝時隨機生成的
sudo cat /var/log/mysqld.log | grep password

# 提升 MySQL 安裝的安全性
sudo mysql_secure_installation


配置檔
在 Windows 上,位置是
C:\ProgramData\MySQL\MySQL Server 8.0/my.ini

在 Linux 上,位置是
/etc/my.cnf


Linux 作業系統比較

http://mitblog.pixnet.net/blog/post/41037058


適合一般使用者的:
--------------
(1) Ubuntu:簡單、易上手、很多人用。是 Linux 初學者相當推薦的一套入門 Linux 流通版。

(2) Fedora:會將最新版的軟體,在還沒穩定前就包入發行。適合喜歡嘗鮮的玩家。

(3) OpenSUSE:使用與 Red Hat Enterprise Linux、CentOS 等伺服器等級相同的核心,但卻包裝得非常簡單易用。適合喜歡穩定、不找麻煩作業系統的使用者。

(4) Arch Linux:特點是非~常小!除了必要的軟體外,不包含華而不實的任何套件。適合想把 Linux 安裝在 4GB 隨身碟上,到處執行的使用者。


適合系統管理員的:
-------------
(1) Debian:特點就是穩!缺點就是操作沒有其它 Linux 流通版那麼友善。適合不怕下繁複命令列指令的系統管理員,當成桌機或伺服器系統之用。

(2) Red Hat Enterprise Linux:穩定、支援叢集伺服器、雲端運算等企業用得到的特性。很適合拿來架設伺服器。不過想取得這個版本,是要收費的。

(3) CentOS:一套由 Red Hat Enterprise Linux 改造而來、但卻不用收費的 Linux 作業系統。特色也是穩到一個不行。有「萬年不掛伺服器」之美稱。適合想嘗試 Red Hat Enterprise Linux,卻無力負擔花錢購買該 Linux 的人使用。


為特殊用途而開發的:
---------------
(1) Gentoo:以支援軟體套件眾多、傲視所有 Linux 作業系統聞名。不過它很要求整套系統要提供原始碼這件事,導致安裝時,常常需要從「原始碼」編譯成「執行檔」後,才能使用。從另一面來看,這會迫使用它的人,培養出從原始碼編出執行檔的能力,也算是蠻好的教育訓練平台。因此,Gentoo 有「學其它 Linux 版本,你就是學會該版本而已。學會 Gentoo,你就學會所有的 Linux」之美稱。

(2) Damn Vulnerable Linux(DVL):從字面上翻譯,就是「他媽的超脆弱 Linux」。這個版本故意裝了老舊、破損、有臭蟲的各種軟體套件。因此你可以拿它來訓練系統管理員,將它修補到穩定為止。

(3) Kali Linux:由 Debian 改寫、前身是「Backtrack」、故意留下各種網路漏洞、讓你拿來訓練駭客「入侵技巧」之用的 Linux。它本身可以直接接受任何 Debian 的軟體,適合拿來做「入侵測試(Penetration Test)」之用。

go 語言操作 MySQL 範例

MySQL 本身的相關知識:
http://www.runoob.com/mysql/mysql-transaction.html
https://blog.longwin.com.tw/2006/03/innodb_transaction_2006/
https://xyz.cinc.biz/2013/05/mysql-transaction.html

Golang 操作相關知識:
https://ithelp.ithome.com.tw/articles/10207409
https://segmentfault.com/a/1190000003036452

https://www.jianshu.com/p/bc8120bec94e
http://hopehook.com/2017/08/21/golang_transaction/
https://www.cnblogs.com/hupengcool/p/4143238.html
https://www.kancloud.cn/liupengjie/go/570128

* 事務處理 ( transaction )

tx, err := db.Begin()
...
...
...

tx.Commit()


* tx对象

一般查询使用的是db对象的方法,事务则是使用另外一个对象。sql.Tx对象。使用db的Begin方法可以创建tx对象。tx对象也有数据库交互的Query,Exec和Prepare方法。用法和db的相关用法类似。查询或修改的操作完毕之后,需要调用tx对象的Commit提交或者Rollback方法回滚。

一旦创建了tx对象,事务处理都依赖与tx对象,这个对象会从连接池中取出一个空闲的连接,接下来的sql执行都基于这个连接,直到commit或者rollback调用之后,才会把连接释放到连接池。

在事务处理的时候,不能使用db的查询方法,虽然后者可以获取数据,可是这不属于同一个事务处理,将不会接受commit和rollback的改变,一个简单的事务例子如下:

tx, err := db.Begin()
tx.Exec(query1)
tx.Exec(query2)
tx.Commit()

在tx中使用db是错误的:

tx, err := db.Begin()
db.Exec(query1)
tx.Exec(query2)
tx.commit()

上述代码在调用db的Eexc方法的时候,tx会绑定连接到事务中,db则是额外的一个连接,两者不是同一个事务。需要注意,Begin和Commit方法,与 sql 语句中的 BEGIN 或 COMMIT 语句没有关系。

關於事務的相關細節應該詳閱 https://www.jianshu.com/p/bc8120bec94e
涉及到 Transaction 事务、tx对象、事务与连接、事务并发、实践。


* 如果在rows遍历结束之前退出循环,必须手动关闭Resultset,并且接收error。

for rows.Next() {
    // ...
    break; // whoops, rows is not closed! memory leak...
}
// do the usual "if err = rows.Err()" [omitted here]...
// it's always safe to [re?]close here:
if err = rows.Close(); err != nil {
    // but what should we do if there's an error?
    log.Println(err)
}


* 如果id为1的不存在,err为sql.ErrNoRows,一般应用中不存在的情况都需要单独处理。此外,Query返回的错误都会延迟到Scan被调用,所以应该写成如下代码:

var name string
err = db.QueryRow("select name from users where id = ?", 1).Scan(&name)
if err != nil {
    if err == sql.ErrNoRows {
        // there were no rows, but otherwise no error occurred
        // 把空结果当做Error处理是为了强行让程序员处理结果为空的情况
    } else {
        log.Fatal(err)
    }
}
fmt.Println(name)




https://blog.csdn.net/jesseyoung/article/details/40398321
https://studygolang.com/articles/5402

go官方仅提供了database package,database package下有两个包sql,sql/driver。这两个包用来定义操作数据库的接口,这就保证了无论使用哪种数据库,他们的操作方式都是相同的。
    但go官方并没有提供连接数据库的driver,如果要操作数据库,还需要第三方的driver 包,最常用的有:
    https://github.com/Go-SQL-Driver/MySQL支持database/sql,全部采用go写。
    https://github.com/ziutek/mymysql 支持database/sql,也支持自定义的接口,全部采用go写。
    推荐使用前者,因为前者的效率更高一点,二者效率的对比可参考benchmark测试结果:https://github.com/go-sql-driver/sql-benchmark

    go连接其他主流数据库的驱动介绍可参考:
    https://code.google.com/p/go-wiki/wiki/SQLDrivers


user:password@tcp(localhost:5555)/dbname?charset=utf8&autocommit=true
user:password@tcp([de:ad:be:ef::ca:fe]:80)/dbname?charset=utf8mb4




golang 的 包 還不支援 MySQL 8 以上的一個新特性,所以需要如下措施:
https://blog.pilipala.co/articles/2019/02/14/1550128481833

mysql 在 8.0 之后将用户使用的 plugin 更新成 caching_sha2_password。而在之前用的是 mysql_native_password。

在 MySQL 內
use mysql;
select user,host,plugin from user;

可以看到相關資訊

接著利用修改密碼的語法順便將 root 從 caching_sha2_password 改回到 mysql_native_password

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';

最後需要再將 golang 內的連結語法加上一個參數 &allowNativePasswords=true

user:password@tcp([de:ad:be:ef::ca:fe]:80)/dbname?charset=utf8mb4&allowNativePasswords=true

分庫分表之後,ID 主鍵如何產生

https://blog.csdn.net/qq_42882671/article/details/86478990
https://zhuanlan.zhihu.com/p/54838983

1. 數據庫自增 id
2. UUID
3. 獲取系統當前時間:將別的業務字段值跟當前時間拼接起來,組成一個全局唯一的編號。
4. snowflake 算法


關聯式資料庫 - 分庫分表 的其中一種思維參考

分库分表?如何做到永不迁移数据和避免热点?
http://database.51cto.com/art/201904/595550.htm








文中提到的 小伙伴们在开发的时候不要每次都去查询三张关联表,可以保存到缓存中(本地jvm缓存),这样不会影响性能。

以 golang 做 本地缓存 的參考如下:
https://blog.csdn.net/lanyang123456/article/details/86766069

group和DB的关系

table和db的关系



TiDB 使用坑记录

https://blog.csdn.net/yajie_12/article/details/82773813

1、对硬盘要求很高,没上SSD硬盘的不建议使用

2、不支持分区,删除数据是个大坑。
解决方案:set @@session.tidb_batch_delete=1;

3、插入数据太大也会报错
解决方案:set @@session.tidb_batch_insert=1;

4、删除表数据时不支持别名
delete from 表名 表别名 where 表别名.col = ‘1’ 会报错

5、内存使用有问题,GO语言导致不知道回收机制什么时候运作。内存使用过多会导致TIDB当机(这点完全不像MYSQL)
测试情况是,32G内存,在10分钟后才回收一半。

6、数据写入的时候,tidb压力很大, tikv的CPU也占用很高

7、不支持GBK

8、不支持存储过程

9、列数支持太少,只支持100列,和oralce/mysql的1000列少太多(Oracle 最大列数为 1000;MySQL对于每个表具有4096个列的硬限制, 其中InnoDB每个表的限制为1017列, 最大行大小限制为65,535字节)

其他文章的一些建议

3TiKV+3PD+2TiDB

在有了 TiSpark 之后,我们便利用 TiSpark 将中间表缓存为 Spark 的内存表,只需要将最后的数据落地回 TiDB,再执行 Merge 操作即可,这样省掉了很多中间数据的落地,大大节省了很多脚本执行的时间

在查询速度解决之后,我们发现脚本中会有很多针对中间表 update 和 delete 的语句。目前 TiSpark 暂时不支持 update 和 delete 的操作(和 TiSpark 作者沟通,后续会考虑支持这两个操作),
我们便尝试了两种方案,一部分执行类似于 Hive,采用 insert into 一张新表的方式来解决;另外一部分,我们引入了 Spark 中的 Snappydata 作为一部分内存表存储,
在 Snappydata 中进行 update 和 delete,以达到想要的目的。因为都是 Spark 的项目,因此在融合两个项目的时候还是比较轻松的。

最后,关于实时的调度工具,目前我们是和离线调度一起进行调度,这也带来了一些问题,每次脚本都会初始化一些 Spark 参数等,这也相当耗时。在未来,我们打算采用 Spark Streaming 作为调度工具,
每次执行完成之后记录时间戳,Spark Streaming 只需监控时间戳变化即可,能够避免多次初始化的耗时,通过 Spark 监控,我们也能够清楚的看到任务的延迟和一些状态,这一部分将在未来进行测试。

TiDB 架构的演进和开发哲学

TiDB 架构的演进和开发哲学
https://segmentfault.com/a/1190000008288188


十问 TiDB :关于架构设计的一些思考
https://juejin.im/entry/5b29bde4518825749725c28f

其实并没有什么技术是完美和包治百病的,在存储领域更是如此,如果你的数据能够在一个 MySQL 装下并且服务器的压力不大,或者对复杂查询性能要求不高,其实分布式数据库并不是一个特别好的选择。 选用分布式的架构就意味着引入额外的维护成本,而且这个成本对于特别小的业务来说是不太划算的,即使你说需要高可用的能力,那 MySQL 的主从复制 + GTID 的方案可能也基本够用,这不够的话,还有最近引入的 Group Replication。而且 MySQL 的社区足够庞大,你能 Google 找到几乎一切常见问题的答案。

我们做 TiDB 的初衷并不是想要在小数据量下取代 MySQL,而是尝试去解决基于单机数据库解决不了的一些本质的问题。

有很多朋友问我选择分布式数据库的一个比较合适的时机是什么? 我觉得对于每个公司或者每个业务都不太一样,我并不希望一刀切的给个普适的标准(也可能这个标准并不存在),但是有一些事件开始出现的时候:比如是当你发现你的数据库已经到了你每天开始绞尽脑汁思考数据备份迁移扩容,开始隔三差五的想着优化存储空间和复杂的慢查询,或者你开始不自觉的调研数据库中间件方案时,或者人肉在代码里面做 sharding 的时候,这时给自己提个醒,看看 TiDB 是否能够帮助你,我相信大多数时候应该是可以的。

而且另一方面,选择 TiDB 和选择 MySQL 并不是一刀切的有你没他的过程,我们为了能让 MySQL 的用户尽可能减小迁移和改造成本,做了大量的工具能让整个数据迁移和灰度上线变得平滑,甚至从 TiDB 无缝的迁移回来,而且有些小数据量的业务你仍然可以继续使用 MySQL。所以一开始如果你的业务和数据量还小,大胆放心的用 MySQL 吧,MySQL still rocks,TiDB 在未来等你。


TiDB 安裝部署

https://php.wiki/tidb

TiDB 是新一代开源分布式 NewSQL 数据库,模型受 Google Spanner / F1 论文的启发,实现了自动的水平伸缩,强一致性的分布式事务,基于 Raft 算法的多副本复制等重要 NewSQL 特性。TiDB 结合了 RDBMS 和 NoSQL 的优点,部署简单,在线弹性扩容和异步表结构变更不影响业务, 真正的异地多活及自动故障恢复保障数据安全,同时兼容 MySQL 协议,使迁移使用成本降到极低。

安装部署

TiDB 官方提供了支持 Linux 版本的二进制安装包,官方推荐使用 Redhat 7+、CentOS 7+ 以上版本的操作系统,不推荐在 Redhat 6、CentOS 6 上部署 TiDB 集群。
操作系统:Linux ( Redhat 7+,CentOS 7+ )
执行步骤:

下载压缩包

wget http://download.pingcap.org/tidb-latest-linux-amd64.tar.gz
wget http://download.pingcap.org/tidb-latest-linux-amd64.sha256

检查文件完整性

,返回 ok 则正确
sha256sum -c tidb-latest-linux-amd64.sha256

解开压缩包

tar -xzf tidb-latest-linux-amd64.tar.gz
cd tidb-latest-linux-amd64

单节点方式快速部署

在获取 TiDB 二进制文件包后,我们可以在单机上面,运行和测试 TiDB 集群,请按如下步骤依次启动 PD,TiKV,TiDB。
注意:以下启动各个应用程序组件实例的时候,请选择后台启动,避免前台失效后程序自动退出。
步骤一. 启动 PD:
./bin/pd-server --data-dir=pd --log-file=pd.log
步骤二. 启动 TiKV:
./bin/tikv-server --pd="127.0.0.1:2379" --data-dir=tikv --log-file=tikv.log
步骤三. 启动 TiDB:
./bin/tidb-server --store=tikv  --path="127.0.0.1:2379"   --log-file=tidb.log
步骤四. 使用 MySQL 客户端连接 TiDB:
mysql -h 127.0.0.1 -P 4000 -u root -D test

参考链接

MySQL vs. TiDB

https://zhuanlan.zhihu.com/p/25657799

https://db-engines.com/en/system/MySQL%3BTiDB

https://opensource.com/article/18/11/key-differences-between-mysql-and-tidb

https://www.zhihu.com/question/58767602
TiDB 具备如下 NewSQL 核心特性:

SQL支持 (TiDB 是 MySQL 兼容的)---->基本上没有学习成本和开发改造成本,可以实现无缝后端存储迁移,这一点对开发哥来说太太太重要了。

水平线性弹性扩展            ---->无限的计算能力,无限的存储能力,虽然是理论上的,但是不觉得很牛逼的样子吗?

分布式事务                      -->适配OLTP场景

跨数据中心数据强一致性保证            ---->某些场景下很有用

故障自恢复的高可用            ---->永远挂不了的系统,是不是很酷?

TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景。

没有学习成本和接入成本,不需要运维,随意扩展,支持事务,原生高可用,mysql遇到的问题在tidb里基本都解决了。



TiDB 在小米的应用实践
https://zhuanlan.zhihu.com/p/51472404

目前 TiDB 主要应用在:

小米手机桌面负一屏的快递业务
商业广告交易平台素材抽审平台

这两个业务场景每天读写量均达到上亿级,上线之后,整个服务稳定运行;接下来我们计划逐步上线更多的业务场景,小米阅读目前正在积极的针对订单系统做迁移测试。

TiDB 结合了传统的 RDBMS 和 NoSQL 的最佳特性,兼容 MySQL 协议,支持无限的水平扩展,具备强一致性和高可用性。

具有如下的特性:

高度兼容 MySQL,大多数情况下无需修改代码即可从 MySQL 轻松迁移至 TiDB,即使已经分库分表的 MySQL 集群亦可通过 TiDB 提供的迁移工具进行实时迁移。

水平弹性扩展,通过简单地增加新节点即可实现 TiDB 的水平扩展,按需扩展吞吐或存储,轻松应对高并发、海量数据场景。

分布式事务,TiDB 100% 支持标准的 ACID 事务。

真正金融级高可用,相比于传统主从(M-S)复制方案,基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证,且在不丢失大多数副本的前提下,可以实现故障的自动恢复(auto-failover),无需人工介入。

TiDB 的架构及原理官网有详细介绍(https://pingcap.com/)。


TiDB 基础架构图

跟绝大数互联网公司一样,小米关系型存储数据库首选 MySQL,单机 2.6T 磁盘。由于小米手机销量的快速上升和 MIUI 负一屏用户量的快速增加,导致负一屏快递业务数据的数据量增长非常快,每天的读写量级均分别达到上亿级别,数据快速增长导致单机出现瓶颈,比如性能明显下降、可用存储空间不断降低、大表 DDL 无法执行等,不得不面临数据库扩展的问题。比如,我们有一个业务场景(智能终端),需要定时从几千万级的智能终端高频的向数据库写入各种监控及采集数据,MySQL 基于 Binlog 的单线程复制模式,很容易造成从库延迟,并且堆积越来越严重。

对于 MySQL 来讲,最直接的方案就是采用分库分表的水平扩展方式,综合来看并不是最优的方案,比如对于业务来讲,对业务代码的侵入性较大;对于 DBA 来讲提升管理成本,后续需要不断的拆分扩容,即使有中间件也有一定的局限性。同样是上面的智能终端业务场景,从业务需求看,需要从多个业务维度进行查询,并且业务维度可能随时进行扩展,分表的方案基本不能满足业务的需求。

了解到 TiDB 特点之后,DBA 与业务开发沟通确认当前 MySQL 的使用方式,并与 TiDB 的兼容性做了详细对比,经过业务压测之后,根据压测的结果,决定尝试将数据存储从 MySQL 迁移到 TiDB。经过几个月的线上考验,TiDB 的表现达到预期。

兼容性对比

TiDB 支持包括跨行事务、JOIN、子查询在内的绝大多数 MySQL 的语法,可以直接使用 MySQL 客户端连接;对于已用 MySQL 的业务来讲,基本可以无缝切换到 TiDB。
二者简单对比如下几方面:

1. 功能支持

TiDB 尚不支持如下几项:

增加、删除主键
非 UTF8 字符集
视图(即将支持)、存储过程、触发器、部分内置函数
Event
全文索引、空间索引

2. 默认设置

字符集、排序规则、sql_mode、lower_case_table_names 几项默认值不同。

3. 事务

TiDB 使用乐观事务模型,提交后注意检查返回值。
TiDB 限制单个事务大小,保持事务尽可能的小。

4. TiDB 支持绝大多数的 Online DDL。

5. 另,一些 MySQL 语法在 TiDB 中可以解析通过,不会产生任何作用,例如: create table 语句中 engine、partition 选项都是在解析后忽略。

6. 详细信息可以访问官网:https://pingcap.com/docs-cn/sql/mysql-compatibility/ 。




關於 LevelDB

https://juejin.im/post/5c22e049e51d45206d12568e

它是 Google 开源的 NOSQL 存储引擎库,是现代分布式存储领域的一枚原子弹。在它的基础之上,Facebook 开发出了另一个 NOSQL 存储引擎库 RocksDB,沿用了 LevelDB 的先进技术架构的同时还解决了 LevelDB 的一些短板。你可以将 RocksDB 比喻成氢弹,它比 LevelDB 的威力更大一些。现代开源市场上有很多数据库都在使用 RocksDB 作为底层存储引擎,比如大名鼎鼎的 TiDB。


程式語言編年史

程式語言編年史原文 下面這張圖片描繪了整個程式語言的歷史。包括各種程式語言的發明人、程式語言的特點和適用領域、被什麼網站或公司使用等 (檢視 完整高清圖 )。 之所以會有那麼多不同的程式語言是因為設計程式語言的初衷不同、對語言學習曲線的追求不同、不同程式之間的執行成本差異...