小心 spring.jpa.open-in-view 導致 DB connection 被拿光

 spring.jpa.open-in-view

• spring boot 的 property, spring.jpa.open-in-view 預設是開啟的
• 開啟的話, OpenSessionInViewInterceptor 就會介入
• 收到 web request 的時候, 會開一個 Hibernate Session
• 如果用到 DB, 就會拿一個 DB Connection
• 完成 request, 就把 connection 關閉

目的

• 原本一個 entity 有像是 OneToMany 的關聯時, 預設都會 lazy.
• 需要特別啟用這個 collection, 就需要特別去初始化, 例如 Hibernate.initialize
• 如果沒有初始化就會遇到 LazyInitializationException

問題

• 如果處理一個 request 的時候會需要比較長的時間, 那 DB connection 就會被卡住
• BTW, 預設 DB connection 是 10條 ( https://github.com/brettwooldridge/HikariCP )
• 如果需要呼叫外部服務, 或是外部服務遇到 connection timeout 之類的問題, 會導致一個 request 花很多時間才結束
• 而導致 connection 很快被拿光, 而且無法拿到新的 connection 而爆炸..

怎麼辦?

disable open-in-view

• 把 spring.jpa.open-in-view, 把這個設成 false, 可以避免 connection 跟著 request
• 可是要注意如果有 lazy 的地方要 initialize 否則會遇到 lazy exception

限制 request 的時間

• 把時間可能拉長的設計跟 DB access 分開來
• 例如把對外部系統的呼叫分開來

Reference

更多OSIV細節: https://www.baeldung.com/spring-open-session-in-view

可能會需要調整 HikariCP 的 pool size, 參考: https://github.com/brettwooldridge/HikariCP

Spring Boot 的 open-in-view property: https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html#application-properties.data.spring.jpa.open-in-view

新團隊快速貢獻

前篇

分工不設限

前言

自從開始與新團隊合作後, 產品也即將 GA release.

GA 之後又會有新的不同的挑戰. 在新挑戰之前, 是時候紀錄一下這段時間發生的事情.

挑戰

1. 產品本身
1. 由於架構改變加上優化, 整個 backend 幾乎全部改寫, 而且加上支援 HA. 有大量還沒經過 QA 驗證的程式
   (全部改寫, 都只有 unit test, 所以算是全部都還沒驗證過 :P).
2. 這個產品開發需要了解另一個產品才可以整合
2. 人員改變
1. 原本的核心團員一人
2. 新外包團隊五個人加入, 四個工程師與一個 QA.
3. Functional QA 與 Performance QA
3. 同時間 (同個禮拜加入)
1. 需要帶領新團隊五人從無到有了解產品並加以貢獻
2. Functional QA 開始列 functional testcase 測試, 這是公司內經驗老到的 QA
3. Scaling QA 開始列 performance criteria & testcase 開始測試效能, 這也是公司內經驗老到的 QA
4. 時程
1. 由於來支援的 QA 手上還有其他重要的事情, 所以我們不該耽誤他們太久
2. 因此不論 scaling QA or functional QA 的時間都非常寶貴 (大家的時間本來就都非常寶貴)
3. 必須特別注意不可以有 blocking issue, 有 blocking issue 就需要立馬解決

接受挑戰

規劃

Thread 1-1: 新團隊成員

1. 協助裝機, 介紹開發環境
2. 講解原理, 提供文件
3. 拍影片, 介紹產品基礎設定與整合測試方法
4. 下載程式後, 介紹程式架構, 依照 use case 介紹程式位子

Thread 1-2: Functional QA

1. 介紹產品背景與 trade-off
2. 解釋功能, 提供文件
3. 討論 testcase 以及測試的範圍

Thread 1-3: Scaling QA

1. 介紹產品背景與 trade-off
2. 解釋功能, 提供文件
3. 討論需要的 capacity 以及效能測試的方法

Thread 2-1: 新團隊成員

1. 確認基本操作完成後, 開始安排 Functional QA 開的 bug中比較單純的部分交給新成員處理
2. 由於每個人開始透過不同的 bug 來熟悉系統, 為了快速掌握進度, 開始進行 daily meeting
3. 透過由淺入深的 bug, 來觀察還有甚麼地方不懂, 就一次講解給所有人聽, 期望盡早把知識都散布出去

Thread 2-2: Scaling QA

1. 一開始 Scaling QA 遇到的問題最棘手, 因為效能大多就是測 critical path
2. scaling test 的特性是: 一旦遇到一個量上不去, 測試幾乎就卡住了, 需要立即處理
3. 力求每天 Scaling QA 遇到新瓶頸, 當天或隔天就可以有新的 release 可以繼續測試
4. 由於新團隊成員掌握度還不高, 因此這類問題都要先讓原本的隊員與我來處理

Thread 2-3: Functional QA

1. Functional QA 開的 issue 很多, 需要盡早判斷是屬於新團隊成員可以練習的, 還是需要與原本的隊員一起先解決的
2. 新隊員摸索時期大多是從 NodeJS or Angular 起頭去看 application logic, 因此就先都安排在 NodeJS 或 UI 上可以看到程式的 issue 給新成員
3. 如果跟 Linux system call 或是 IPv6 或是 Java/Groovy 做的比較偏系統操作的 bug, 就由我與原始隊員先排除
4. 初期雖然大部分時間都在與 Scaling QA 合作, 但隨時要注意 Functional QA 有沒有遇到 blocking issue

Thread 3-1: 新團隊成員逐漸上手

1. 上手後能協助的問題就變多了
2. 定調 release 的節奏為每週一次, 簡化流程
3. 開始把一些比較系統面的工作也指派出去
4. 當遇到問題的時候就一起看
5. 有經驗的人與我一樣先挑比較麻煩的 bug, 讓新團隊可以先熟悉 application code.
6. 慢慢有些麻煩的 issue 試著交給新團員後, 有問題就分享平常解決問題的方式
7. 阻止外部的人催促新團隊成員時程, 爭取按步就班上手的時間

Thread 3-2: Scaling QA

1. Scaling test 尾聲, 與 Scaling QA 討論測試的上限
2. 完成測試

Thread 3-3: Functional QA

1. 持續把新成員有能力處理的 issue 指派過去
2. 持續自行處理棘手的 bug

成就

終於, 在經歷了一百多個大大小小的 bug 後, 得到 GA candidate

1. 通過 Scaling QA 安排的測試
2. 通過 Functional QA test pass rate over 96%

過程中

1. 原本的隊員與我在過程中一度需要去支援別的案子, 當下壓力頗大.
2. 秉持著 "培養新團員就有 capacity 來處理更多 issue" 的精神, 繼續投資時間在與新團隊的溝通與分享上
3. 最終果然有的新成員逐漸上手, 可以把更多事情安排出去, 討論的內容也愈來愈進階
4. 時程快到之前, 每天都看著 scrum board 沙盤推演誰的 issue 做完之後可以提升 pass rate
5. 直到有天 pass rate 超過了 96%

插曲

1. 原本新團隊的隊長, 突然要離開公司, 搬回馬來西亞
2. 新團隊的 QA 節奏有點跟不上, 協助幾次之後, 在與新團隊成員討論之後, 提出了 PIP, 最終我們好聚好散
3. 新隊長會再找人補上空缺

後續

1. 為了要 GA, 新團隊還沒有接觸較底層的東西
2. 新團隊即將成為產品的下個版本的主力開發人員, 需要盡早掌握所有部份的技術
3. 新上任的隊長還沒有帶隊經驗, 因此還需要協助建立新的 working model
4. 也要協助新隊長理解新產品需求, 並規劃好 milestones. 讓團隊每個人都能 on the same page.

心得

時間一樣短短的 (2-3個月), 想不到列下來發生這麼多事情.

有人支援是很好的事情, 可是也需要注意釋放出來的知識需要按部就班規劃.

同時間要頂住壓力, 避免 QA 的 issue 壓太多給新隊員導致消化不良, 又要避免卡住 QA 浪費時間.

讓每個人都能處在剛好可以提出貢獻, 又有一點挑戰的狀態就很重要.

為了做到這點, 需要不停地從他人的角度來看待, 持續溝通, 想辦法讓人 on the same page.

很感謝不論是 QA, 原核心成員與新團員都很給力, 在許多混亂的資訊攤在檯面上的時候,

依然能一起持續討論, 找出有意義的目標與問題加以克服.

之後還有很新挑戰, 又是一輪新的動態搭配.

Dependency Inversion Principle 避免過度依賴外部

Introduction

DIP 應該很常見, 只是常常在談的時候會發現大家忘記了.

因此特別紀錄一下使用 DIP 實質上的好處.

Assumption

1. 我們大多會希望 business logic code 可以乾淨穩定
2. 有乾淨穩定的 business logic code, 就可以寫穩定的 unit test code
3. 如此未來商業邏輯有改變的時候, 如果邏輯有衝突, 或是程式有問題很快就可以 flush

Reality

1. 在沒有仔細思考的情況下, 分層式規劃結果無法有乾淨的 business logic code
2. 例如, 假設 DB 是 PostgreSQL, MQ 則是 Kafka
3. 很容易程式會出現 MyDomainService depends on MyDomainRepositoryHibernateImpl
4. 這樣的架構就變成 business logic code depends on implementation
5. 如此, 無法寫出穩定的 business logic test code, 因為都"必須"直接由 domain code 直接依賴 Hibernate & Kafka...
6. 一個是需要準備 Hibernate & Kafka 的環境 or mock, 可能有些細微的調整沒藏好, 會導致一點小調整都可以讓測試壞掉

Solution

1. 為了區隔出乾淨的 business logic code, 我們可以替 repository 提出一個 interface
2. 如此, business logic code 僅止於 MyDomainRepository 以及 MyDomainMessageSender
3. 同時, 也要注意 interface 上不可以出現底層的相關資訊
4. 例如 MyDomainMessageSender 的 interface 不該出現 topic 這種 Kafka 概念的資訊 (除非我們自己訂一層 abstraction layer)
5. 這時候就會看到為何像是 spring-data 會支援直接訂一個 interface 就可以透過 convention access DB

Besides

1. 同樣的概念也可以套用在不同的 component
2. 例如 application 跟很多外部系統界接, 所以程式裡面有分成不同的 component
3. 透過 DIP, 可以把其他 system 的實作與主要的 business logic 獨立開來
4. 如此就可以直接在測試描述對於外部喜統的 expectation, 而且不用為了 business logic test code 準備外部系統的細節
   (在目前的例子, 不用準備 gRPC and Kafka)

Spring Cloud Stream Introduction - 1

Goal

描述如何套用 spring cloud stream + Kafka 以及概念.
適合只面對 Kafka, 不涵蓋進階議題

Example

https://github.com/axxdeveloper/study-practice/tree/spring-cloud-stream

Concepts

• 一個 application 的架構: 外部系統(middleware) -> input -> application process -> output -> 外部系統
• 在 Spring Cloud Stream
• 透過 Binder 來處理外部系統的細節. ex. spring-cloud-stream-binder-kafka
• 透過 Binding 來處理 input.

Example

• Setup
• Spring Boot Application

@SpringBootApplication

public class DemoApplication {

    public static void main(String[] args) {

        SpringApplication.run(DemoApplication.class, args);

    }

}

• Empty application.properties

Kafka topic consumer

• Consumer method (注意! 這裡的 method name: status 就是 Binding name, 會影響 application.properties)

@Bean

public Consumer<String> status() {

    return status -> System.out.println("Received " + status);

}

• 指定 input topic application.properties

# 如果會從多個 topic 拿 message 就需要在 spring.cloud.function.definition 這個 attribute 指定, 並且用分號隔開. 這裡是預先指定一個

spring.cloud.function.definition=status

# 可以看到這的 pattern: spring.cloud.stream.bindings.{bindingName}-in-0.destination, 用來指定 topic name

# in 的部分是說 input topic

# 0 則是這個 binding 的第一個 input

spring.cloud.stream.bindings.status-in-0.destination=status

• 再來就可以發訊息給 status 這個 topic

Function

透過 Function 可以處理 input -> process -> output

• Function: 收到一個訊息後, 在尾巴貼上 random suffix, 然後回傳

@Bean

public Function<String, String> randomNumberSuffix() {

    return val -> val + " => append suffix " + Math.random();

}

• 指定 input & output topic in application.properties

# 注意此時我們已經加上第二個 binding

spring.cloud.function.definition=status;randomNumberSuffix

# 指定 randomNumberSuffix 的 intput topic 是 randomNumberSuffix, output topic 則是 status, 也就是同一個 application 的另一個 binding

spring.cloud.stream.bindings.randomNumberSuffix-in-0.destination=randomNumberSuffix

spring.cloud.stream.bindings.randomNumberSuffix-out-0.destination=status

• 發訊息給 randomNumberSuffix topic

Supplier

Supplier 是會被系統自動 polling, 預設一秒 poll 一次, 也可以指定 cron, 要 3.2 版之後才支援 custom binding polling configuration.

• Supplier

@Bean

public Supplier<Date> mydate() {

    return () -> new Date();

}

• 指定 output topic 給 mydate 這個 Supplier binding

# 此時已經增加第三個 binding definition

spring.cloud.function.definition=status;randomNumberSuffix;mydate

# 指定 output topic 為 status, 就是同個 app 的 topic

spring.cloud.stream.bindings.mydate-out-0.destination=status

# 改變預設的 poll config 為 2 秒 poll 一次

spring.cloud.stream.poller.fixed-delay=2000

• Supplier 只要打開 app 就會自動被執行

Other Concepts

• Consumer Group
• 跟 Kafka Consumer Group 的概念一樣
• 同一個 group 裡面只會有一個 consumer 收到 message
• 不同 group 則都會收到訊息
• 預設每個 consumer 都是不同的 group (anomymous group)
• 透過 {binding}.group=xxx 來指定 groupName
• Durability
• 有指定 group, 則對 consumer 的 subscription 就會被保留, 即使這個 group 目前沒有 consumer, 等 consumer 回來, 就會接著收到訊息
• anonymous group 的 subscription 就不會被保留, 因此 anonymous group 容易收到 duplicated message
• Partition
• 一個 topic 可以被切成多個 partition, 每個 partition 會由固定的一個 consumer 接收資料

 

分工不設限

 

前言

去年一些巧合, 跟團隊幾個人接手一個案子, 這個案子原本算是服務客戶特定需求的 POC, 但由於客戶愈來愈依賴這個工具, 因此交到我們手上.

PS. 在我加入之前, 已經有人辛苦耕耘了好一陣子. 不過也因緣際會離開這個案子. 一個案子要成功, 從來不是誰可以獨立勝任. 享受合作的當下, 同時也要記得這是很多默默付出的人辛勞的結果, 而非甚麼簡單的水到渠成.. 

挑戰

1. 技術背景不同
1. 案子用到的技術是 NodeJS, Angular, MongoDB
2. 成員技術背景是 Java, Cassandra
2. 需求大: 要把 MongoDB 換成 PostgreSQL
3. 技術債: 由於是個 POC 的案子, 所以程式結構沒有特別維護, 整組就是典型的 callback hell, 經常性的 callback 到第四第五層
4. 沒有統一的 build flow: 原本交付的方式就是從某個工程師的電腦打包出一個 image 給客戶安裝, 在 POC 也還合理, 但要產品化就無法接受了
5. 概括承受 bug, 當前客戶在用的系統如果遇到問題, 就需要與 technical support, customer support 一起討論與解決問題

接受挑戰

初期

1. Study: 由於技術不熟悉, 所以大家還是花時間學一下 NodeJS, Angular, MongoDB.
2. List features: 一起把功能使用一番, 列出來

規劃

Thread-1-1: 換資料庫

1. 一開始我們把所有的 table 列出來, 想要"縱切"來分開發方式. 也就是一個 table 一個 table 的把程式從面對 MongoDB 改為面對 PostgreSQL
2. 做一段時間後, 深感部分 Data Access layer 面對 MongoDB, 部分面對 PostgreSQL, 常常碰到一些因為資料不一致出現的錯誤.
   這種錯誤讓人無法確認現在的開發是好了沒有, 所以我就決定開始衝刺把所有的 Data Access Layer 通通轉成面對 PostgreSQL, 而不理會功能是否損毀.
3. 同時間, 另一個成員深受 callback hell 的困擾, 因此在討論後, 開始大幅度的將 callback hell 改為 controller -> service -> dao 這樣的三層式架構

Thread-1-2: build script

團隊內的大神基於興趣, 接手了 build flow 的規劃. 將原本由工程師在自己電腦上 build image 的方式, 轉為

1. 準備 docker 環境
2. 在 docker 內準備好 CentOS, PostgreSQL, NodeJS, Angular 的環境
3. 安裝好後 build 出客戶需要的 vmware image
4. 準備 CLI 讓客戶裝好 image 後, console 上能跳出 setup 的 CLI.
5. 支援 join 第二台 PostgreSQL
6. 在 Jenkins 上執行 build script

Thread-1-3: nginx

1. 專案原本用 openresty 在 nginx 寫程式 access MongoDB
2. 我們認為這設計導致不容易管理資料庫由誰存取
3. 因此規劃改寫 openresty 從直接存取資料庫, 改為存取 API 來存取資料.

Thread-2-1: data migration

在 Data Access Layer 改為面向 PostgreSQL 之後, 接下來需要處理怎麼從 MongoDB 轉移過來, 因此規劃了

1. 把 MongoDB 資料轉出
2. 建構 PostgreSQL 的 migration script, 包含建立 schema 的 DDL
3. 提供 user import MongoDB data 的功能

Thread-2-2: licensing

原本的案子沒有 license 的功能, 因此也照公司其他產品的方式規劃了 license

Thread-3-1: documentation

慢慢功能都快補好了, 開始需要與 document team 溝通與準備需要的文件

Thread-3-2: unit test

過去缺乏 unit test, 因此大量地補上

成就與心得

1. 像這樣分很多個 thread 做了非常多的事情, 一切只發生在大概五個月內, 而且我們成員就五個人, 且大多都還有其他在進行的專案.
2. 通常一個案子在進行的時候, 很多人可能會想要把要做的事情都規範好, 希望能夠營造一個 "我都規畫好了, 你照做就沒問題"
3. 但我們的作法則是: "目標就這些, 一起來看怎麼處理"
4. 在執行過程中, 每個人都在貢獻自己能做的事情, 而且當遇到覺得有問題的地方, 提出來後大家就能一起討論做決定, 接著繼續分頭進行
5. 由於能夠參與決定, 大家就更有 ownership, 就會提出非常多很好的意見
6. 我自己就很開心能享受到架構與流程的改善, 而且完全是大家自發性的改變, 回想這一段時間, 很短, 但很充實愉快

後記

這個案子, 因為一些因素, 人員變動, 在我們做完之後暫時告一段落.

大家繼續各自去忙不同的案子.

後來公司找了外包團隊.

所以接下來我還會一次與公司突然開始加入的外包團隊, functional QA & performance QA 一起合作.

正在如火如荼, 再次經歷一段美好的團隊合作經驗.

應用 XOR 特性取出相字元或數字

1. XOR 的特性, 相同的值 XOR 會變成 0

0^0=0

1^0=1

0^1=1

1^1=0

// code

int n = 0;

for (int i = 0; i < 10000; i++) {

    n ^= i;

}

for (int i = 0; i < 10000; i++) {

    if (i == 999) continue;

    n ^= i;

}

System.out.println(n); // print 999

2. 應用: 兩個字串只有一個字元不同的時候, 可以用來找出該不同的字元為何.
   (https://leetcode.com/problems/find-the-difference/)

class Solution {

    // ex. s = "abc", t="ab", then ch = 'c'

    public char findTheDifference(String s, String t) {

        char ch = 0;

        for (Character c: s.toCharArray()) {

            ch ^= c;

        }

        for (Character c: t.toCharArray()) {

            ch ^= c;

        }

        return ch;

    }

}

Explain - LeetCode 525 Contiguous Array

題目: Given a binary array nums, return the maximum length of a contiguous subarray with an equal number of 0 and 1

解法:

1. 當遇到 0 就 -1, 遇到 1 就 +1, 計算每個陣列位置的加總
2. 最重要的概念就是: 當遇到相同的加總數字, 表示中間經歷了相同的 1 & 0.
3. 因此解法就是:
1. 走過所有的陣列, 計算每個位子的 count. 遇到 0 就 -1, 遇到 1 就 +1
2. 最重要的概念是: 當過程中出現相同的 count (不管正負) 就表示過程中有相同的 0 與 1
3. 因此解法就是一邊算與紀錄 count, 如果遇到相同的 count 就算距離, 把最長的距離記錄下來

Code

public class Solution {

    public static void main(String[] args) {

        new Solution().findMaxLength(new int[]{0,0,1,0,0,0,1,1});

    }

    public int findMaxLength(int[] nums) {

        Map<Integer, Integer> map = new HashMap<>();

        map.put(0, -1);

        int maxlen = 0, count = 0;

        for (int i = 0; i < nums.length; i++) {

            count = count + (nums[i] == 1 ? 1 : -1);

            if (map.containsKey(count)) { 2. 如果以前有過跟現在相同的 count, 表示過程中經歷了相同的 0 & 1

                maxlen = Math.max(maxlen, i - map.get(count)); // 3. 以此計算距離

            } else {

                map.put(count, i); // 1. 紀錄目前的 count 的位置

            }

        }

        return maxlen;

    }

}

PostgreSQL version schema performance comparison

Requirement

1. Developers keep releasing new software, the version format was {major}.{minor}.{micro}.{build}
2. When a device ask for upgrade information, we need figure out the latest versions of software
3. But not only the latest one, we may need to know following version information, so that we can provide suitable recommendation
1. is there are 3 newer versions of software?
2. How many newer software versions?

Challenge

1. Database sort text by "Natural Sorting"
2. These 2 versions, the older version will be treated as the newer one if we use natural sorting
1. 1.2.3.100 => Will be treated as older because 2 > 1
2. 1.2.3.20 => So the version 20 will be treated as newer

Ideas

1. Persist major, minor, micro, build in different columns
2. Calculate versions to be a number, which can be sorted correctly
3. Merge versions to be a single text, and need to be sorted correctly (We need padLeft 0 to let all versions become the same length)
4. Persist major, minor, micro, build in a byte array (BLOB),
   assume the natural sorting will compare BLOB from the first element of an array.

Test Steps

1. Prepare TestContainer for PostgreSQL testing
2. Generate 10000 records
1. major 0
2. minor 0-9
3. micro 0-9
4. build 0-99
3. Compare with a specified version: 0.6.7.58
4. Compare query plan and query result (Query the latest 3 records)

Code for the test

https://github.com/axxdeveloper/postgresql-schema-testing/tree/master/src/test/java/com/shooeugenesea/dao

Tables

Version1

DDL

CREATE TABLE version1 (

id uuid PRIMARY KEY,

major int,

minor int,

micro int,

build int

);

CREATE INDEX version1_major_idx ON version1 (major DESC);

CREATE INDEX version1_major_minor_idx ON version1 (major DESC, minor DESC);

CREATE INDEX version1_major_minor_micro_idx ON version1 (major DESC, minor DESC, micro DESC);

CREATE INDEX version1_major_minor_micro_build_idx ON version1 (major DESC, minor DESC, micro DESC, build DESC);

SQL

String sql = "SELECT * FROM Version1 " +

"WHERE (major > 0) " +

"OR (major = 0 AND minor > 6) " +

"OR (major = 0 AND minor = 6 AND micro > 7) " +

"OR (major = 0 AND minor = 6 AND micro = 7 AND build > 58) " +

"ORDER BY major DESC, minor DESC, micro DESC, build DESC " +

"LIMIT 3";

Query Plan

QUERY PLAN: Limit (cost=0.29..1.16 rows=3 width=32) (actual time=0.065..0.193 rows=3 loops=1)

QUERY PLAN: -> Index Scan using version1_major_minor_micro_build_idx on version1 (cost=0.29..982.84 rows=3366 width=32) (actual time=0.051..0.073 rows=3 loops=1)

QUERY PLAN: Filter: ((major > 0) OR ((major = 0) AND (minor > 6)) OR ((major = 0) AND (minor = 6) AND (micro > 7)) OR ((major = 0) AND (minor = 6) AND (micro = 7) AND (build > 58)))

QUERY PLAN: Planning Time: 0.920 ms

QUERY PLAN: Execution Time: 0.307 ms

QUERY RESULT: {major=0, minor=9, micro=9, build=99, id=7e5878ff-9d25-46dc-a0c0-79196fd8c5d3}

QUERY RESULT: {major=0, minor=9, micro=9, build=98, id=ee2097ef-fe86-491e-869b-afda5976a354}

QUERY RESULT: {major=0, minor=9, micro=9, build=97, id=ada64c48-72e2-4a39-a6b0-5eabda135d0d}

Version2

DDL

CREATE TABLE version2 (

id uuid PRIMARY KEY,

build int

);

CREATE INDEX version2_order_idx ON version2 (build DESC);

SQL

String sql = "SELECT * FROM Version2 " +

"WHERE build > " + getVersion2Number(0,6,7,58) +

" ORDER BY build DESC" +

" LIMIT 3";

Query Plan

QUERY PLAN: Limit (cost=0.29..0.61 rows=3 width=20) (actual time=0.053..0.124 rows=3 loops=1)

QUERY PLAN: -> Index Scan using version2_order_idx on version2 (cost=0.29..391.76 rows=3627 width=20) (actual time=0.037..0.060 rows=3 loops=1)

QUERY PLAN: Index Cond: (build > 6758)

QUERY PLAN: Planning Time: 0.388 ms

QUERY PLAN: Execution Time: 0.195 ms

QUERY RESULT: {build=9999, id=e32b8067-9cae-4c49-b776-372e8a2137e4}

QUERY RESULT: {build=9998, id=c2902963-6579-48d3-bb91-deac6a8528bd}

QUERY RESULT: {build=9997, id=de28843c-b245-4b46-8e2d-7e549f0b862e}

Version3

DDL

CREATE TABLE version3 (

id uuid PRIMARY KEY,

build bytea

);

CREATE INDEX version3_order_idx ON version3 (build DESC);

SQL

String sql = "SELECT * FROM Version3 " +

"WHERE build > ?" +

" ORDER BY build DESC" +

" LIMIT 3";

Query Plan

QUERY PLAN: Limit (cost=0.28..0.77 rows=3 width=48) (actual time=0.063..0.130 rows=3 loops=1)

QUERY PLAN: -> Index Scan using version3_order_idx on version3 (cost=0.28..368.24 rows=2283 width=48) (actual time=0.047..0.068 rows=3 loops=1)

QUERY PLAN: Index Cond: (build > '\x000506073a'::bytea)

QUERY PLAN: Planning Time: 0.329 ms

QUERY PLAN: Execution Time: 0.214 ms

[0, 9, 9, 99]

[0, 9, 9, 98]

[0, 9, 9, 97]

Version4

DDL

CREATE TABLE version4 (

id uuid PRIMARY KEY,

build VARCHAR

);

CREATE INDEX version4_build_idx ON version4 (build DESC);

SQL

String sql = "SELECT * FROM Version4 " +

"WHERE build > '" + getVersion4Text(0, 6, 7, 58) + "'" +

" ORDER BY build DESC" +

" LIMIT 3";

Query Plan

QUERY PLAN: Limit (cost=0.29..0.80 rows=3 width=48) (actual time=0.074..0.137 rows=3 loops=1)

QUERY PLAN: -> Index Scan using version4_build_idx on version4 (cost=0.29..512.72 rows=2996 width=48) (actual time=0.060..0.079 rows=3 loops=1)

QUERY PLAN: Index Cond: ((build)::text > '0000000600070058'::text)

QUERY PLAN: Planning Time: 0.313 ms

QUERY PLAN: Execution Time: 0.256 ms

QUERY RESULT: {build=0000000900090099, id=29f9f1a0-40eb-4a31-873f-ff04868fa3d1}

QUERY RESULT: {build=0000000900090098, id=1ead5f4d-73d9-4cda-b899-f745b90f8598}

QUERY RESULT: {build=0000000900090097, id=bc9a4dfe-12c9-4c34-8925-836e8c4a7ad3}

Comparison

Options	cost	Pros & Cons
Version1 (split columns)	(cost=0.29..982.84 rows=3366 width=32)	Pros: Flexible, can change SQL easily Cons: Slow
Version2 (calculate to number)	(cost=0.29..391.76 rows=3627 width=20)	Pros: Fast Cons: Need calculate before persist and may need migrate if the logic to compare changed Sorting will be broken if the number exceed max number
Version3 (calculate to string)	(cost=0.28..368.24 rows=2283 width=48)	Pros: Fast and don't have max number issue Cons:  Need calculate before persist and may need migrate if the logic to compare changed
Version4 (calculate to byte array)	(cost=0.29..512.72 rows=2996 width=48)	Pros: Don't need extra calculation Cons: Easy to exceed max byte number, so still need extra calculation Slow

Kafka - Pick a transaction.id

Intention: Why I need Kafka Transaction

• 需求中收到 message 並處理之後, application 需要另外傳送訊息出去給多個 topic.
• 不管遇到任何錯誤, 我都希望訊息就不要送出去.
• 除此之外, 原本 consume 的訊息也不要收下來

How it works

1. Producer initTransaction with transaction.id
2. TransactionCoordinator close existing pending transactions with same transaction.id
3. Producer send message, the message will be wrote to topic
4. Producer commitTransaction, the TransactionCoordinator will start the 2 phase commit process
1. Write PREPARE_COMMIT to the "transactionLog" topic
2. Mark "commit" status in topic partitions
3. write COMMITTED to transactionLog
5. After these steps, transaction was pretty much to be finished

Note: transactionLog 是 internal topic, 用 transaction.id 作為 partition key, 因此可以保證狀態的順序

如果有兩個 Producer 共用 transaction.id, 當 Kafka 發現有相同的 transaction.id 存在的時候, 就會把先前的 transaction close,

因此如果 transaction.id 沒有規劃好就會遇到 transaction 莫名的被 abort 的 error.

Atomic Read-Process-Write

• Consumer 收訊息下來後透過呼叫 commit offset 來標記已經處理完
• 這個 offset 其實也是個 topic
• 藉由前面介紹的 transaction 處理機制, 可以讓 "commitOffset" 也只是發訊息到一個 topic, 也可以被包在同一個 transaction 中

適當的 transaction.id

• transaction.id 需要夠 unique, 如此才能避免 Producer 共用 transaction.id 而被 close
• 由於每個 transaction 都需要一些額外的 request 才能完成, 所以如果 transaction.id 定太細導致一堆 transaction 會使效能大幅降低
• tx-{consumeTopic}-{consumePartition} 是一個折衷的 transactionid, 因為一個 consumer 只會對應到一個 topic 以及 partition.
  在 read-process-write 的 pattern 下, 這個 transaction.id 會被該 topic & partition 的 consumer 使用, 不會有 multi-thread producer with same transaction.id 的情況.
  也不會過於分散 (同樣是在 read-process-write pattern 下, 一個 consumer thread 會一個一個訊息處理, 每個 consumed message 都值得一個 transaction (id).

KafkaTemplate 有個設定: producerPerConsumerPartition 就是拿來建立 tx-{consumeTopic}-{consumePartition} 這樣的 transaction.id.

它的做法就是在接收訊息的時候, 把 topic & partition 記錄下來, 好在發送訊息的時候 append 到 transaction.id prefix 後面

SpringBoot + Flyway + Kafka + PostgreSQL + Testcontainers

Source Code: https://github.com/axxdeveloper/study-practice/tree/testcontainer

在一個 sharing session 分享如何使用 testcontainer 輔助 SpringBoot application 開發測試 Kafka & PostgresSQL  相關的邏輯.

用 TestContainer 沒甚麼問題, 主要是多個 test class 開關 Kafka & Postgres 之後要重新讓 SpringBoot 連線比較麻煩, 這時候用了 DirtiesContexts

 

用 protobuf Any 來 parse byte array

第一次錄影片分享技術議題.

Source code: https://github.com/axxdeveloper/study-practice/tree/gpb 

主要其實就是之後可以用 Any.pack( gpbEntity ).toByteArray 傳送出去.
接收端也適用 Any.parseFrom( byteArray ).unpack( gpbEntity.class ).

這樣可以用 Any.parseFrom (byteArray).is( gpbEntity.class ) 來判斷應該要用哪個 gpbEntity 來讀資料.

PostgreSQL Replication

 

• WAL - Write Ahead Log, or xlog, or transaction log.
• WAL 就像是 Cassandra 的 CommitLog, 會先被存起來, 再寫進資料庫, 使 Postgres 不管何時被關閉, 重啟後都可以恢復資料.
• WAL 存在 pg_wal folder 下
• Postgres 13, 放在 /var/lib/pgsql/13/data/pg_wal
• WAL 檔案預設 16MB
• WAL 是用 binary format 寫入的
• Checkpoint
• 用來清除 WAL. 確認 WAL 已經寫入 data 就可以把 WAL 清掉了
• 由系統自動驅動, 不過可以在 postgresql.conf 裡面設定驅動的參數.
  例如可以指定 Checkpoint 之間的週期, 或是 wal 檔案大小的區間.

# - Checkpoints -

#checkpoint_timeout = 5min # range 30s-1d

max_wal_size = 1GB

min_wal_size = 80MB

#checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0

#checkpoint_flush_after = 256kB # measured in pages, 0 disables

#checkpoint_warning = 30s # 0 disables

• WAL file 會被排序過再寫到硬碟, 來增加寫入的效能
• 比較長的 Checkpoint 區間會減少 WAL file 的數量
• PITR: point-in-time-recovery
• 做 HA 需要 PITR backup/restore, 因為 standby node 在剛啟動的時候需要先有一個從 primary node 建立的 base backup
• PITR 的設定在 postgresql.conf (擷取部分)

#------------------------------------------------------------------------------

# WRITE-AHEAD LOG

#------------------------------------------------------------------------------

wal_level = replica

#------------------------------------------------------------------------------

# REPLICATION

#------------------------------------------------------------------------------

max_wal_senders = 10

max_replication_slots = 10

• wal_level = replica (https://docs.postgresql.tw/server-administration/server-configuration/write-ahead-log) 預設 replica 使能夠準備足夠的 transaction log 給 PITR restore 使用, 如果設定成
• max_wal_senders = 10 (https://docs.postgresql.tw/server-administration/server-configuration/replication) 最大的寫量, 注意不能大於 max_connection
• max_replication_slots = 10 (https://docs.postgresql.tw/server-administration/server-configuration/replication) 指定最大的 replication slot, 就是一份寫入的資料, 要 replica 到幾個 node 才可以 (或是 replica 到所有的 standby)
• Archive transaction log
• 設定在 postgresql.conf

# - Archiving -

archive_mode = on # enables archiving; off, on, or always

# (change requires restart)

archive_command = 'cp "%p" "/var/lib/pgsql/archivedir/%f"' # command to use to archive a logfile segment

# placeholders: %p = path of file to archive

# %f = file name only

# e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'

#archive_timeout = 0 # force a logfile segment switch after this

# number of seconds; 0 disables

• 以這預設值, Postgres 會持續把 WAL 寫入 /var/lib/pgsql/archivedir/%f

[admin@rnd1 ~]$ sudo ls -l /var/lib/pgsql/13/data/pg_wal

total 32772

-rw------- 1 postgres postgres 337 Jun 9 08:40 000000010000000000000002.00000028.backup

-rw------- 1 postgres postgres 16777216 Jun 10 04:21 000000010000000000000003

-rw------- 1 postgres postgres 16777216 Jun 9 08:40 000000010000000000000004

drwx------ 2 postgres postgres 59 Jun 9 08:45 archive_status

[admin@rnd1 ~]$ sudo ls -l /var/lib/pgsql/archivedir/

total 49156

-rw------- 1 postgres postgres 16777216 Jun 9 08:40 000000010000000000000001

-rw------- 1 postgres postgres 16777216 Jun 9 08:40 000000010000000000000002

-rw------- 1 postgres postgres 337 Jun 9 08:40 000000010000000000000002.00000028.backup

-rw------- 1 postgres postgres 16777216 Jun 9 08:32 000000010000000000000003

[admin@rnd1 ~]$

• pg_hba.conf (host-based authentication)
• 如果要用 pg_basebackup 就需要設定 pg_hba.conf

local database user auth-method [auth-options]

host database user address auth-method [auth-options]

hostssl database user address auth-method [auth-options]

hostnossl database user address auth-method [auth-options]

hostgssenc database user address auth-method [auth-options]

hostnogssenc database user address auth-method [auth-options]

host database user IP-address IP-mask auth-method [auth-options]

hostssl database user IP-address IP-mask auth-method [auth-options]

hostnossl database user IP-address IP-mask auth-method [auth-options]

hostgssenc database user IP-address IP-mask auth-method [auth-options]

hostnogssenc database user IP-address IP-mask auth-method [auth-options]

Ex. 從 local or 127.0.0.1 or ::1 來的, 用來 replication 的 user 為 postgres 的連線都一律通過

# Allow replication connections from localhost, by a user with the

# replication privilege.

local replication postgres trust

host replication postgres 127.0.0.1/32 trust

host replication postgres ::1/128 trust

• https://www.postgresql.org/docs/13/auth-pg-hba-conf.html
• 執行 pg_basebackup
• https://www.postgresql.org/docs/13/app-pgbasebackup.html
• 這段指令會把 Postgres 的資料複製到 /some_target_dir 下

pg_basebackup -D /some_target_dir -h localhost --checkpoint=fast --wal-method=stream

• PITR restore
• 指定 restore_command 與 recovery_target_timeline

restore_command = 'cp /mnt/server/archivedir/%f "%p"'

recovery_target_timeline = latest

• 啟動後等關鍵字 "consistent recovery state reached"
• Ex. 用 pg_basebackup 要求 standby 去 sync data

pg_basebackup -D /target -h master.example.com --checkpoint=fast --wal-method=stream -R

• 使用 pg_basebackup 的時候可以 -R, 如此會把 standby configuration 寫進 postgresql.conf

standby_mode = on

primary_conninfo = ' ...'

• Debug
• pg_stat_replication ( *_lsn, lsn 是 location 的意思, 所以 sent_lsn 就是 sent_location )

select * from pg_stat_replication;

pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | backend_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_l

ag | sync_priority | sync_state | reply_time

-------+----------+---------+------------------+---------------+-----------------+-------------+-------------------------------+--------------+-----------+-----------+-----------+-----------+------------+-----------+-----------+---------

---+---------------+------------+-------------------------------

13594 | 16385 | repl | 10.206.79.240 | 10.206.79.240 | | 50462 | 2021-06-09 10:21:35.997181+00 | | streaming | 0/30255F8 | 0/30255F8 | 0/30255F8 | 0/30255F8 | | |

| 0 | async | 2021-06-13 18:06:50.870681+00

(1 row)

• pg_stat_wal_receiver (可以在 standby 查)

select * from pg_stat_wal_receiver;

pid | status | receive_start_lsn | receive_start_tli | written_lsn | flushed_lsn | received_tli | last_msg_send_time | last_msg_receipt_time | latest_end_lsn | latest_end_time | slot_name | send

er_host | sender_port | conninfo

------+-----------+-------------------+-------------------+-------------+-------------+--------------+-------------------------------+-------------------------------+----------------+-------------------------------+---------------+------

---------+-------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------

1598 | streaming | 0/3000000 | 1 | 0/30255F8 | 0/30255F8 | 1 | 2021-06-13 18:12:41.476929+00 | 2021-06-13 18:12:41.477835+00 | 0/30255F8 | 2021-06-10 04:21:07.190989+00 | 10_206_79_240 | 10.20

6.79.197 | 5432 | user=repl passfile=/var/lib/pgsql/.pgpass channel_binding=prefer dbname=replication host=10.206.79.197 port=5432 application_name=10.206.79.240 fallback_application_name=walreceiver sslmode=prefer sslcompression=

0 ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=postgres target_session_attrs=any

(1 row)

• Timeline
• 一開始 Postgres primary 的 timeline 是 1, transaction log 的檔名像是0000000100000000000000F5
• 當 standby 被 promote 了, timeline 會變成 2, transaction log 的檔名像是0000000200000000000000F5
• hot_standby_feedback = off
• 由於 primary 與 standby 的狀態是單方面從 primary sync to standby, 所以如果 standby 做了一些 transaction 相關的事情, 會因為 primary 同時間也有動作而產生錯誤.
• 為了能夠修正這個錯誤, 透過 hot_standby_feedback = on, 使 standby 可以定期傳"最後一筆 transaction log" 給 primary, 如此 primary 就有機會可以補救 (例如因為注意到 standby 的 transaction log 有差距而避免 delete data)
• 不過為了避免 standby 長時間的 transaction 影響效能, hot_standby_feedback 是被關掉的 (相較於 transaction log streaming 效能好)
• anyway, 如果在 OLTP 的情況下, select 花很久時間, 就可以考慮改這個設定

Angular - Built-in directives

ngIf

true => Host div will be included in the HTML elements

false => Host div will be excluded in the HTML elements

<div *ngIf="needShow(4)" class="bg-info p-2 mt-1"> Check need to show if pass 4 </div>

<div *ngIf="doNotShow()" class="bg-info p-2 mt-1"> Expect do not show this element </div>

ngSwitch

Same, only matched element will be included in the HTML elements.

However the ngSwitch host element will always be included in HTML element.

<div class="bg-info p-2 mt-1" [ngSwitch]="howManyPeople()"> 

    <span *ngSwitchCase="2">There are two people</span> 

    <span *ngSwitchCase="5">There are five people</span> 

    <span *ngSwitchDefault>This is the default</span> 

</div>

Need double quote when comparing string

<div class="bg-info p-2 mt-1" [ngSwitch]="whatIsYourName()">

    <span *ngSwitchCase="'Anderson'">I know you!!</span>

    <span *ngSwitchCase="'QQ'">Hi, nice to meet you</span>

    <span *ngSwitchDefault>Hello?</span>

</div>

ngFor

repeats a section of content for each object in an array, providing the template equivalent of a foreach loop.

Template variables: index (zero based number), odd (boolean), even (boolean), first (boolean), last (boolean)

<tr *ngFor="let item of getProducts(); let i = index; let odd = odd; let even = even"> 

    <td>{{item.name}}</td> 

    <td>{{item.category}}</td>

    <td>{{item.price}}</td> 

</tr>

由於 ngFor 需要 iterate data, 當 data source 改變的時候, ngFor 需要重新跑一次 data source 會讓效能變差.

為了提升效能, 可以在 component 訂一個 method, 例如 getKey (注意 signature 第一個參數是 index, 第二個參數是 object), 然後在 ngFor 裡面定義 trackBy:getKey, 如此就能讓 ngFor 了解雖然是從 data source 拿到新的物件, 但其實是同一筆資料

1. define getKey method

import { ApplicationRef, Component } 

from "@angular/core"; 

import { Model } from "./repository.model"; 

import { Product } from "./product.model"; 

@Component({ 

    selector: "app", 

    templateUrl: "template.html" 

})

export class ProductComponent { 

model: Model = new Model(); 

    // ...constructor and methods omitted for brevity... 

    getKey(index: number, product: Product) { 

        return product.id; 

    } 

}

2. 定義 trackBy:getKey

<tr *ngFor="let item of getProducts();let i = index;let odd = odd;let even = even;trackBy:getKey">

    <td>{{item.name}}</td>

    <td>{{item.category}}</td>

    <td>{{item.price}}</td>

</tr>

ngTemplateOutlet

Used to repeat a block of content in a specified location

1. Define a template and the content

<ng-template #myTemplate> 

    <div>Hello</dic>

</ng-template>

2. Output the template

<ng-template [ngTemplateOutlet]="myTemplate"></ng-template>

<div>KKKKK</div>

<ng-template [ngTemplateOutlet]="myTemplate"></ng-template>

Provide Context Data Binding

1. Define template with context. We defined "text" variable in template, and the value will be the expression result of "title"
   (Use let- to define a variable)

<ng-template #myTemplate let-text="title"> 

    <h4 class="p-2 bg-success text-white">{{text}}</h4> 

</ng-template>

2. Use the defined template and provide data for binding

<ng-template [ngTemplateOutlet]="myTemplate" [ngTemplateOutletContext]="{title: 'Header'}"> </ng-template>

Keep in mind

1. Expressions need to be idempontent
2. Can NOT access objects defined outside of the template's component, and in particular, templates can't access the global namespace.
3. Global namespace must be provided by component, acting as on behalf of the template

import { ApplicationRef, Component }

from "@angular/core";

import { Model } from "./repository.model";

import { Product } from "./product.model";

@Component({

    selector: "app",

    templateUrl: "template.html"

})

export class ProductComponent {

model: Model = new Model();

    // ...constructor and methods omitted for brevity...

    getNumber(): number {

        return Math.floow(1); // The Math can't be accessed by template

    }

    getKey(index: number, product: Product) {

        return product.id;

    }

}

init mongodb data in docker

 1. Given file in project folder ./mongo/docker-entrypoint-initdb.d:/initdb.sh

```

echo '=====================================>'

mongo --eval 'db.getSiblingDB("testqq").createUser({"user": "admin", "pwd": "admin", roles: [{"role": "readWrite","db": "testqq"}]});'

mongo --eval 'db.getSiblingDB("testqq").users.insert({"username" : "admin", "password" : "admin", "email" : "admin@gmail.com"});'

echo '<======================================'

```

2. Given docker-compose.yml

```

services:

  mongo:

    image: mongo:4.4

    ports:

      - "27017:27017"

    volumes:

    - "./mongo/docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d"

```

3. Start docker-compose

```

$ docker-compose up

```

4. Check log, can find following log

```

mongo_1  | /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/initdb.sh

mongo_1  | =====================================>

mongo_1  | MongoDB shell version v4.4.3

mongo_1  | connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb

mongo_1  | {"t":{"$date":"2021-01-25T16:48:42.786+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"127.0.0.1:46062","connectionId":2,"connectionCount":1}}

mongo_1  | {"t":{"$date":"2021-01-25T16:48:42.787+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn2","msg":"client metadata","attr":{"remote":"127.0.0.1:46062","client":"conn2","doc":{"application":{"name":"MongoDB Shell"},"driver":{"name":"MongoDB Internal Client","version":"4.4.3"},"os":{"type":"Linux","name":"Ubuntu","architecture":"x86_64","version":"18.04"}}}}

mongo_1  | Implicit session: session { "id" : UUID("14d8434a-7c74-4509-a5de-d55a4c63bdf4") }

mongo_1  | MongoDB server version: 4.4.3

mongo_1  | {"t":{"$date":"2021-01-25T16:48:42.835+00:00"},"s":"I",  "c":"STORAGE",  "id":20320,   "ctx":"conn2","msg":"createCollection","attr":{"namespace":"admin.system.users","uuidDisposition":"generated","uuid":{"uuid":{"$uuid":"e8923719-dd5a-4a94-a417-bb32a7ca4ebc"}},"options":{}}}

mongo_1  | {"t":{"$date":"2021-01-25T16:48:42.854+00:00"},"s":"I",  "c":"INDEX",    "id":20345,   "ctx":"conn2","msg":"Index build: done building","attr":{"buildUUID":null,"namespace":"admin.system.users","index":"_id_","commitTimestamp":{"$timestamp":{"t":0,"i":0}}}}

mongo_1  | {"t":{"$date":"2021-01-25T16:48:42.854+00:00"},"s":"I",  "c":"INDEX",    "id":20345,   "ctx":"conn2","msg":"Index build: done building","attr":{"buildUUID":null,"namespace":"admin.system.users","index":"user_1_db_1","commitTimestamp":{"$timestamp":{"t":0,"i":0}}}}

mongo_1  | Successfully added user: {

mongo_1  | "user" : "admin",

mongo_1  | "roles" : [

mongo_1  | {

mongo_1  | "role" : "readWrite",

mongo_1  | "db" : "testqq"

mongo_1  | }

mongo_1  | ]

mongo_1  | }

mongo_1  | {"t":{"$date":"2021-01-25T16:48:42.859+00:00"},"s":"I",  "c":"NETWORK",  "id":22944,   "ctx":"conn2","msg":"Connection ended","attr":{"remote":"127.0.0.1:46062","connectionId":2,"connectionCount":0}}

mongo_1  | MongoDB shell version v4.4.3

mongo_1  | connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb

mongo_1  | {"t":{"$date":"2021-01-25T16:48:42.926+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"127.0.0.1:46064","connectionId":3,"connectionCount":1}}

mongo_1  | {"t":{"$date":"2021-01-25T16:48:42.927+00:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn3","msg":"client metadata","attr":{"remote":"127.0.0.1:46064","client":"conn3","doc":{"application":{"name":"MongoDB Shell"},"driver":{"name":"MongoDB Internal Client","version":"4.4.3"},"os":{"type":"Linux","name":"Ubuntu","architecture":"x86_64","version":"18.04"}}}}

mongo_1  | Implicit session: session { "id" : UUID("b0df77be-4789-4cb7-a1d0-6b64717b0207") }

mongo_1  | MongoDB server version: 4.4.3

mongo_1  | {"t":{"$date":"2021-01-25T16:48:42.937+00:00"},"s":"I",  "c":"STORAGE",  "id":20320,   "ctx":"conn3","msg":"createCollection","attr":{"namespace":"testqq.users","uuidDisposition":"generated","uuid":{"uuid":{"$uuid":"fb550551-8a86-4f98-9a93-b324e057084d"}},"options":{}}}

mongo_1  | {"t":{"$date":"2021-01-25T16:48:42.950+00:00"},"s":"I",  "c":"INDEX",    "id":20345,   "ctx":"conn3","msg":"Index build: done building","attr":{"buildUUID":null,"namespace":"testqq.users","index":"_id_","commitTimestamp":{"$timestamp":{"t":0,"i":0}}}}

mongo_1  | WriteResult({ "nInserted" : 1 })

mongo_1  | {"t":{"$date":"2021-01-25T16:48:42.957+00:00"},"s":"I",  "c":"NETWORK",  "id":22944,   "ctx":"conn3","msg":"Connection ended","attr":{"remote":"127.0.0.1:46064","connectionId":3,"connectionCount":0}}

mongo_1  | <======================================

```

5. Access mongo and check db

```

cds % docker exec -it cds_mongo_1 bash

root@186eb2a0f48d:/# mongo

MongoDB shell version v4.4.3

connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb

Implicit session: session { "id" : UUID("59729a8b-ecb1-439a-ab9f-63cc06f30e54") }

MongoDB server version: 4.4.3

Welcome to the MongoDB shell.

For interactive help, type "help".

For more comprehensive documentation, see

https://docs.mongodb.com/

Questions? Try the MongoDB Developer Community Forums

https://community.mongodb.com

---

The server generated these startup warnings when booting:

        2021-01-25T16:52:03.600+00:00: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine. See http://dochub.mongodb.org/core/prodnotes-filesystem

        2021-01-25T16:52:04.496+00:00: Access control is not enabled for the database. Read and write access to data and configuration is unrestricted

---

---

        Enable MongoDB's free cloud-based monitoring service, which will then receive and display

        metrics about your deployment (disk utilization, CPU, operation statistics, etc).

        The monitoring data will be available on a MongoDB website with a unique URL accessible to you

        and anyone you share the URL with. MongoDB may use this information to make product

        improvements and to suggest MongoDB products and deployment options to you.

        To enable free monitoring, run the following command: db.enableFreeMonitoring()

        To permanently disable this reminder, run the following command: db.disableFreeMonitoring()

---

> db.getSiblingDB('testqq').getUsers()

[

{

"_id" : "testqq.admin",

"userId" : UUID("886d3d0f-7457-4724-8ae6-d9494382bce4"),

"user" : "admin",

"db" : "testqq",

"roles" : [

{

"role" : "readWrite",

"db" : "testqq"

}

],

"mechanisms" : [

"SCRAM-SHA-1",

"SCRAM-SHA-256"

]

}

]

>

```