为什么要使用tidb

我只发表自己的看法，同时也欢迎大家发表观点

1. 我使用的是go作为后端语言，业务场景有设计分库分表，订单时间分表等。市面上找不到go编写的mysql代理服务，只有java的 shardingsphere
2. mysql没有采用集群部署，只是在services命令空间下部署一个单机mysql
3. 项目有大量数据分析的场景，可以使用clickhouse,不过要把需要分析的数据也在ck中存一份，tidb 提供了tiflash 会同步数据，这样在聚合分析查表时候就不会锁表。这个很关键

TiDB-Operator 部署

编写tidb-operator-values.yaml
此文件只使用于测试环境，生产环境要根据具体条件配置具体参数

# Default values for tidb-operator

# clusterScoped is whether tidb-operator should manage kubernetes cluster wide tidb clusters
# Also see rbac.create, controllerManager.serviceAccount, scheduler.create and controllerManager.clusterPermissions.
clusterScoped: true

# Also see clusterScoped and controllerManager.serviceAccount
rbac:
  create: true

# timezone is the default system timzone
timezone: UTC

# operatorImage is TiDB Operator image
operatorImage: pingcap/tidb-operator:v1.6.1
imagePullPolicy: IfNotPresent
# imagePullSecrets: []

# tidbBackupManagerImage is tidb backup manager image
tidbBackupManagerImage: pingcap/tidb-backup-manager:v1.6.1

#
# Enable or disable tidb-operator features:
#
#   AdvancedStatefulSet (default: false)
#     If enabled, tidb-operator will use AdvancedStatefulSet to manage pods
#     instead of Kubernetes StatefulSet.
#     It's ok to turn it on if this feature is not enabled. However it's not ok
#     to turn it off when the tidb-operator already uses AdvancedStatefulSet to
#     manage pods. This is in GA phase.
#     Ref: https://docs.pingcap.com/tidb-in-kubernetes/stable/advanced-statefulset
#
#   VolumeModifying (default false)
#     If enabled, tidb-operator support to increase the size or performance of volumes
#     for specific volume provisioner. This is in GA phase for AWS EBS.
#
#   VolumeReplacing (default false)
#     If enabled, tidb-operator support generic volume changes (size, storageclass & number of volumes)
#     by deleting old pod + pvc completely and replacing with new pods/PVCs.
#     pd, tikv, tidb supported. If enabled, takes precedence over volume resizing & modifying.
#     This works by deleting pod+volumes one at a time (similar to scale-in), and recreating it.
#     For PD & TiKV this will first create one new spare replica to take the load before deleting existing ones
#     Safely deleting a volume and replacing them can take a long time (Especially TiKV to move regions).
#     This is in Alpha phase.
#
features: []
# - AdvancedStatefulSet=false
# - VolumeModifying=false
# - VolumeReplacing=false

appendReleaseSuffix: false

controllerManager:
  create: true
  # With rbac.create=false, the user is responsible for creating this account
  # With rbac.create=true, this service account will be created
  # Also see rbac.create and clusterScoped
  serviceAccount: tidb-controller-manager

  # clusterPermissions are some cluster scoped permissions that will be used even if `clusterScoped: false`.
  # the default value of these fields is `true`. if you want them to be `false`, you MUST set them to `false` explicitly.
  clusterPermissions:
    nodes: true
    persistentvolumes: true
    storageclasses: true

  logLevel: 2
  replicas: 1
  resources:
    requests:
      cpu: 80m
      memory: 50Mi
#  # REF: https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/
#  priorityClassName: system-cluster-critical
#

  # REF: https://pkg.go.dev/k8s.io/client-go/tools/leaderelection#LeaderElectionConfig
  ## leaderLeaseDuration is the duration that non-leader candidates will wait to force acquire leadership
  # leaderLeaseDuration: 15s
  ## leaderRenewDeadline is the duration that the acting master will retry refreshing leadership before giving up
  # leaderRenewDeadline: 10s
  ## leaderRetryPeriod is the duration the LeaderElector clients should wait between tries of actions
  # leaderRetryPeriod: 2s
  ## leaderResourceLock is the type of resource object that will be used for locking during leader election
  ## If using "endpoints" before and want to migrate to "leases", you should migrate to "endpointsleases" first
  # leaderResourceLock: "leases"

  ## number of workers that are allowed to sync concurrently. default 5
  # workers: 5

  # autoFailover is whether tidb-operator should auto failover when failure occurs
  autoFailover: true
  # pd failover period default(5m)
  pdFailoverPeriod: 5m
  # tikv failover period default(5m)
  tikvFailoverPeriod: 5m
  # tidb failover period default(5m)
  tidbFailoverPeriod: 5m
  # tiflash failover period default(5m)
  tiflashFailoverPeriod: 5m
  # dm-master failover period default(5m)
  dmMasterFailoverPeriod: 5m
  # dm-worker failover period default(5m)
  dmWorkerFailoverPeriod: 5m
  # detectNodeFailure tells whether tidb-operator should auto detect k8s node failures for recovery of failure pods. Currently it is experimental
  detectNodeFailure: false
  # podHardRecoveryPeriod is the time limit after which a failure pod is forcefully marked as k8s node failure. To be set if detectNodeFailure is true default (24h)
  # podHardRecoveryPeriod: 24h
  ## affinity defines pod scheduling rules,affinity default settings is empty.
  ## please read the affinity document before set your scheduling rule:
  ## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
  affinity: {}
  ## nodeSelector ensure pods only assigning to nodes which have each of the indicated key-value pairs as labels
  ## ref:https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector
  nodeSelector: {}
  ## Tolerations are applied to pods, and allow pods to schedule onto nodes with matching taints.
  ## refer to https://kubernetes.io/docs/concepts/configuration/taint-and-toleration
  tolerations: []
  # - key: node-role
  #   operator: Equal
  #   value: tidb-operator
  #   effect: "NoSchedule"
  ## Selector (label query) to filter on, make sure that this controller manager only manages the custom resources that match the labels
  ## refer to https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#equality-based-requirement
  selector: []
  # - canary-release=v1
  # - k1==v1
  # - k2!=v2
  ## Env define environments for the controller manager.
  ## NOTE that the following env names is reserved: 
  ##  - NAMESPACE
  ##  - TZ
  ##  - HELM_RELEASE
  env: []
  # - name: AWS_REGION
  #   value: us-west-2
  # SecurityContext is security config of this component, it will set template.spec.securityContext
  # Refer to https://kubernetes.io/docs/tasks/configure-pod-container/security-context
  securityContext: {}
  # runAsUser: 1000
  # runAsGroup: 2000
  # fsGroup: 2000
  # PodAnnotations will set template.metadata.annotations
  # Refer to https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
  podAnnotations: {}
  ## KubeClientQPS indicates the maximum QPS to the kubenetes API server from client.
  # kubeClientQPS: 5
  ## Maximum burst for throttle.
  # kubeClientBurst: 10

scheduler:
  create: false
  # With rbac.create=false, the user is responsible for creating this account
  # With rbac.create=true, this service account will be created
  # Also see rbac.create and clusterScoped
  serviceAccount: tidb-scheduler
  logLevel: 2
  replicas: 1
  schedulerName: tidb-scheduler
  resources:
    limits:
      cpu: 250m
      memory: 150Mi
    requests:
      cpu: 80m
      memory: 50Mi
  kubeSchedulerImageName: registry.k8s.io/kube-scheduler
  # This will default to matching your kubernetes version
  # kubeSchedulerImageTag:
  ## affinity defines pod scheduling rules,affinity default settings is empty.
  ## please read the affinity document before set your scheduling rule:
  ## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
  affinity: {}
  ## nodeSelector ensure pods only assigning to nodes which have each of the indicated key-value pairs as labels
  ## ref:https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector
  nodeSelector: {}
  ## Tolerations are applied to pods, and allow pods to schedule onto nodes with matching taints.
  ## refer to https://kubernetes.io/docs/concepts/configuration/taint-and-toleration
  tolerations: []
  # - key: node-role
  #   operator: Equal
  #   value: tidb-operator
  #   effect: "NoSchedule"
  #
  # SecurityContext is security config of this component, it will set template.spec.securityContext
  # Refer to https://kubernetes.io/docs/tasks/configure-pod-container/security-context
  securityContext: {}
  # runAsUser: 1000
  # runAsGroup: 2000
  # fsGroup: 2000
  # PodAnnotations will set template.metadata.annotations
  # Refer to https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
  podAnnotations: {}

  # additional annotations for the configmap, mainly to prevent spinnaker versioning the cm
  configmapAnnotations: {}

# When AdvancedStatefulSet feature is enabled, you must install
# AdvancedStatefulSet controller.
# Note that AdvancedStatefulSet CRD must be installed manually via the following
# command:
#   kubectl apply -f manifests/advanced-statefulset-crd.v1.yaml
advancedStatefulset:
  create: false
  ## resourceLock indicates the type of resource object that will be used for locking during leader election.
  ## If using "endpoints" before and want to migrate to "leases", you should migrate to "endpointsleases" first.
  # resourceLock: "leases"
  image: pingcap/advanced-statefulset:v0.7.0
  imagePullPolicy: IfNotPresent
  serviceAccount: advanced-statefulset-controller
  logLevel: 4
  replicas: 1
  resources:
    limits:
      cpu: 500m
      memory: 300Mi
    requests:
      cpu: 200m
      memory: 50Mi
  ## affinity defines pod scheduling rules,affinity default settings is empty.
  ## please read the affinity document before set your scheduling rule:
  ## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
  affinity: {}
  ## nodeSelector ensure pods only assigning to nodes which have each of the indicated key-value pairs as labels
  ## ref:https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector
  nodeSelector: {}
  ## Tolerations are applied to pods, and allow pods to schedule onto nodes with matching taints.
  ## refer to https://kubernetes.io/docs/concepts/configuration/taint-and-toleration
  tolerations: []
  # - key: node-role
  #   operator: Equal
  #   value: tidb-operator
  #   effect: "NoSchedule"
  #
  # SecurityContext is security config of this component, it will set template.spec.securityContext
  # Refer to https://kubernetes.io/docs/tasks/configure-pod-container/security-context
  securityContext: {}
  # runAsUser: 1000
  # runAsGroup: 2000
  # fsGroup: 2000

admissionWebhook:
  create: true
  replicas: 1
  serviceAccount: tidb-admission-webhook
  logLevel: 2
  rbac:
    create: true
  ## validation webhook would check the given request for the specific resource and operation
  validation:
    ## statefulsets hook would check requests for updating tidbcluster's statefulsets
    ## If enabled it, the statefulsets of tidbcluseter would update in partition by tidbcluster's annotation
    statefulSets: false
    ## validating hook validates the correctness of the resources under pingcap.com group
    pingcapResources: false
  ## mutation webhook would mutate the given request for the specific resource and operation
  mutation:
    ## defaulting hook set default values for the the resources under pingcap.com group
    pingcapResources: true
  ## failurePolicy are applied to ValidatingWebhookConfiguration which affect tidb-admission-webhook
  ## refer to https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#failure-policy
  failurePolicy:
    ## the validation webhook would check the request of the given resources.
    validation: Fail
    ## the mutation webhook would mutate the request of the given resources.
    mutation: Fail
  ## tidb-admission-webhook deployed as kubernetes apiservice server
  ## refer to https://github.com/openshift/generic-admission-server
  apiservice:
    ## apiservice config
    ## refer to https://kubernetes.io/docs/tasks/access-kubernetes-api/configure-aggregation-layer/#contacting-the-extension-apiserver
    insecureSkipTLSVerify: true
    ## The Secret includes the TLS ca, cert and key for the `tidb-admission-webook.<Release Namespace>.svc` Service.
    ## If insecureSkipTLSVerify is true, this would be ignored.
    ## You can create the tls secret by:
    ## kubectl create secret generic <secret-name> --namespace=<release-namespace> --from-file=tls.crt=<path-to-cert> --from-file=tls.key=<path-to-key> --from-file=ca.crt=<path-to-ca>
    tlsSecret: ""
    ## The caBundle for the webhook apiservice, you could get it by the secret you created previously:
    ## kubectl get secret <secret-name> --namespace=<release-namespace> -o=jsonpath='{.data.ca\.crt}'
    caBundle: ""
  ## certProvider indicate the key and cert for the webhook configuration to communicate with `kubernetes.default` service.
  ## If your kube-apiserver's version >= 1.13.0, you can leave cabundle empty and the kube-apiserver
  ## would trust the roots on the apiserver.
  ## refer to https://github.com/kubernetes/api/blob/master/admissionregistration/v1/types.go#L529
  ## or you can get the cabundle by:
  ## kubectl get configmap -n kube-system extension-apiserver-authentication -o=jsonpath='{.data.client-ca-file}' | base64 | tr -d '\n'
  cabundle: ""
  # SecurityContext is security config of this component, it will set template.spec.securityContext
  # Refer to https://kubernetes.io/docs/tasks/configure-pod-container/security-context
  securityContext: {}
  # runAsUser: 1000
  # runAsGroup: 2000
  # fsGroup: 2000
  ## nodeSelector ensures that pods are only scheduled to nodes that have each of the indicated key-value pairs as labels
  ## ref:https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector
  nodeSelector: {}
  ## Tolerations are applied to pods, and allow pods to schedule onto nodes with matching taints.
  ## refer to https://kubernetes.io/docs/concepts/configuration/taint-and-toleration
  tolerations: []
  # - key: node-role
  #   operator: Equal
  #   value: tidb-operator
  #   effect: "NoSchedule"
  #

heml 命令

#安装 TiDB Operator CRDs
kubectl create -f https://raw.githubusercontent.com/pingcap/tidb-operator/v1.6.1/manifests/crd.yaml
#添加pingcap 仓库
helm repo add pingcap https://charts.pingcap.org/

# 更新仓库
helm repo update

helm install --values tidb-operator-values.yaml --namespace tidb  promtail  grafana/promtail