分享知识,分享快乐

0%

tidb备份,还原,cdc实时同步

全量备份

1
2
3
4
#指定时间备份
tiup br backup full --pd "172.20.192.115:2379" \
--storage "s3://tidb/all20240520?access-key=minioadmin&secret-access-key=***&endpoint=http://172.20.192.151:6060&force-path-style=true" \
--backupts='2024/05/18 00:00:00'

增量备份

1
2
3
4
5
6
# 获取上一次的备份时间戳
tiup br validate decode --field="end-version" --storage 's3://tidb/all20240520?access-key=minioadmin&secret-access-key=minioadmin&endpoint=http://172.20.192.151:6060'| tail -n1

tiup br backup full --pd "172.20.192.115:2379" \
--storage "s3://tidb/add20240520?access-key=minioadmin&secret-access-key=***&endpoint=http://172.20.192.151:6060&force-path-style=true" \
--lastbackupts='449829037670400000'

cdc实时同步

1
2
3
4
# 获取上一次的备份时间戳
tiup br validate decode --field="end-version" --storage 's3://tidb/all20240520?access-key=minioadmin&secret-access-key=***&endpoint=http://172.20.192.151:6060'| tail -n1

tiup cdc cli changefeed create --server=http://172.20.192.108:8300 --sink-uri="mysql://root:***@172.20.192.233:32570" --changefeed-id="prod-to-k8s" --start-ts="449887328375668790"

– 对于错误代码为 8138、8139 和 8140 的错误,可以通过设置 set @@tidb_enable_mutation_checker=0 跳过检查。
– 对于错误代码为 8141 的错误,可以通过设置 set @@tidb_txn_assertion_level=OFF 跳过检查。

“error”: {
“time”: “2024-05-20T18:08:00.547340271+08:00”,
“addr”: “172.20.192.107:8300”,
“code”: “CDC:ErrChangefeedUnretryable”,
“message”: “[CDC:ErrMySQLTxnError]MySQL txn error: context deadline exceeded”
}

tiup cdc cli changefeed create --server=http://172.20.192.107:8300 --sink-uri=“mysql://root:***@172.20.192.233:32570?max-txn-row=20” --changefeed-id=“prod-to-k8s” --start-ts=“449889998692417548” --config /home/tidb/cdc-prod-to-k8s.toml

阅读全文 »

TIDB搭建双集群主从复制

官网参考文档

https://docs.pingcap.com/zh/tidb/v6.5/replicate-between-primary-and-secondary-clusters#搭建双集群主从复制

TiCDC 安装部署与集群运维

https://docs.pingcap.com/zh/tidb/v6.5/deploy-ticdc

  1. 备份数据。

    在上游集群中执行 BACKUP 语句备份数据:

    1
    MySQL [(none)]> BACKUP DATABASE * TO '`s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://${HOST_IP}:6060&force-path-style=true`' RATE_LIMIT = 120 MB/SECOND;
    1
    2
    3
    4
    5
    6
    +----------------------+----------+--------------------+---------------------+---------------------+
    | Destination | Size | BackupTS | Queue Time | Execution Time |
    +----------------------+----------+--------------------+---------------------+---------------------+
    | local:///tmp/backup/ | 10315858 | 431434047157698561 | 2022-02-25 19:57:59 | 2022-02-25 19:57:59 |
    +----------------------+----------+--------------------+---------------------+---------------------+
    1 row in set (2.11 sec)

    备份语句提交成功后,TiDB 会返回关于备份数据的元信息,这里需要重点关注 BackupTS,它意味着该时间点之前数据会被备份,后边的教程中,将使用 BackupTS 作为数据校验截止时间TiCDC 增量扫描的开始时间

  2. 恢复数据。

    在下游集群中执行 RESTORE 语句恢复数据:

    1
    mysql> RESTORE DATABASE * FROM '`s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://${HOST_IP}:6060&force-path-style=true`';
    1
    2
    3
    4
    5
    6
    +----------------------+----------+--------------------+---------------------+---------------------+
    | Destination | Size | BackupTS | Queue Time | Execution Time |
    +----------------------+----------+--------------------+---------------------+---------------------+
    | local:///tmp/backup/ | 10315858 | 431434141450371074 | 2022-02-25 20:03:59 | 2022-02-25 20:03:59 |
    +----------------------+----------+--------------------+---------------------+---------------------+
    1 row in set (41.85 sec)
  3. 创建一个 TiCDC 同步任务,实时同步主集群数据到从集群

1
tiup cdc cli changefeed create --server=http://172.20.192.108:8300 --sink-uri="mysql://root:Admi*@172.20.192.101:4000" --changefeed-id="upstream-to-downstream" --start-ts="445309452101091541"

以上命令中:

  • --server:TiCDC 集群任意一节点的地址
  • --sink-uri:同步任务下游的地址
  • --start-ts:TiCDC 同步的起点,需要设置为实际的备份时间点(也就是第 2 步:迁移全量数据提到的 BackupTS)

使用 TiCDC 命令行工具来查看集群状态

阅读全文 »

漫道云环境安装Tidb

安装 TiDB Operator CRDs

1
kubectl create -f https://raw.githubusercontent.com/pingcap/tidb-operator/v1.6.0-beta.1/manifests/crd.yaml

helm delete tidb-operator -n tidb-admin

kubectl create namespace tidb-cluster && \

wget https://raw.githubusercontent.com/pingcap/tidb-operator/v1.6.0-beta.1/examples/advanced/tidb-cluster.yaml

kubectl -n tidb-cluster apply -f tidb-cluster.yaml

kubectl -n tidb-cluster delete -f tidb-cluster.yaml

wget https://raw.githubusercontent.com/pingcap/tidb-operator/v1.6.0-beta.1/examples/basic/tidb-dashboard.yaml

kubectl -n tidb-cluster apply -f tidb-dashboard.yaml

阅读全文 »

tidb 升级

  1. 先升级 TiUP 版本(建议 tiup 版本不低于 1.11.3):

    1
    2
    tiup update --self
    tiup --version
  2. 再升级 TiUP Cluster 版本(建议 tiup cluster 版本不低于 1.11.3):

    1
    2
    tiup update cluster
    tiup cluster --version
1
tiup cluster check tidb-prod-101 --cluster

停止组件cdc

tiup cluster stop tidb-prod -R cdc

1
tiup cluster upgrade tidb-prod-101 v7.5.1

tiup cluster display tidb-prod-101

阅读全文 »

搭建 MinIO 作为备份存储系统 ,兼容S3

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
wget https://dl.min.io/server/minio/release/linux-amd64/minio
chmod +x minio

# 配置访问 minio 的 access-key access-screct-id

export HOST_IP='172.20.192.151'
export MINIO_ROOT_USER='minio'
export MINIO_ROOT_PASSWORD='miniostorage'

# 创建数据目录, 其中 backup 为 bucket 的名称

mkdir -p data/backup

# 启动 minio, 暴露端口在 6060

/opt/module/minio server /opt/module/data --address :6060 &

单节点部署多磁盘

1
/opt/module/minio server --address :6060  /dfs/data1/s3data /dfs/data2/s3data /dfs/data3/s3data &

备份 还原 TIDB数据

1
2
3
4
5
6
7
8
mycli -h172.20.192.70 -P4000 -uroot

BACKUP DATABASE test TO 's3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://172.20.192.151:6060&force-path-style=true' RATE_LIMIT = 120 MB/SECOND;


mycli -h172.20.192.115 -P4000 -uroot

mysql> RESTORE DATABASE test FROM 's3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://172.20.192.151:6060&force-path-style=true';
阅读全文 »

使用Yarn标签机制实现任务资源隔离

官网参考地址: https://docs.cloudera.com/runtime/7.2.0/yarn-allocate-resources/topics/yarn-configuring-node-labels.html

参考地址: https://zhuanlan.zhihu.com/p/674882366

1
2
3
4
[root@bigdata-1 ~]# sudo -u hdfs hadoop fs -mkdir -p /yarn/node-labels
[root@bigdata-1 ~]# sudo -u hdfs hadoop fs -chown -R yarn:yarn /yarn
[root@bigdata-1 ~]# sudo -u hdfs hadoop fs -chmod -R 700 /yarn
[root@bigdata-1 ~]# hadoop fs -ls /yarn

YARN Service Advanced Configuration Snippet (Safety Valve) for yarn-site.xml

add the following:

  • Set the following property to enable Node Labels:

    1
    2
    Name: yarn.node-labels.enabled
    Value: true
  • Set the following property to reference the HDFS node label directory

    1
    2
    Name: yarn.node-labels.fs-store.root-dir
    Value: hdfs://:/

    For example,

    1
    2
    Name: yarn.node-labels.fs-store.root-dir
    Value: hdfs://node-1.example.com:8020/yarn/node-labels/

使用命令方式给yarn集群添加标签

1
sudo -u yarn yarn rmadmin -addToClusterNodeLabels "x(exclusive=true),y(exclusive=false)"

使用命令方式节点关联标签:

阅读全文 »

Apache Kyuubi on CDH 部署

https://shmily-qjj.top/ee1c2df4/

Apache Kyuubi on Spark 在 CDH 上的深度实践

https://www.slidestalk.com/openLooKeng/22

vi kyuubi-env.sh

1
2
3
4
5
6
7
8
9
export JAVA_HOME=/usr/java/jdk1.8.0_181-cloudera
export SPARK_HOME=/opt/cloudera/parcels/CDH/lib/spark3
export FLINK_HOME=/opt/cloudera/parcels/FLINK
export HIVE_HOME=/opt/cloudera/parcels/CDH/lib/hive
export HADOOP_CONF_DIR=/etc/hadoop/conf
export YARN_CONF_DIR=/etc/hadoop/conf
export KYUUBI_JAVA_OPTS="-Xmx10g -XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=4096 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSConcurrentMTEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled
-XX:+CMSParallelRemarkEnabled -XX:+UseCondCardMark -XX:MaxDirectMemorySize=1024m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./logs -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -Xloggc:./logs/kyuubi-server-gc-%t.log -XX:+Us
eGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=5M -XX:NewRatio=3 -XX:MetaspaceSize=512m"

vi conf/kyuubi-defaults.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
kyuubi.frontend.bind.host                10.0.0.1
kyuubi.frontend.protocols THRIFT_BINARY
kyuubi.frontend.thrift.binary.bind.port 10009
#
# kyuubi.engine.type SPARK_SQL
# kyuubi.engine.share.level USER
# kyuubi.session.engine.initialize.timeout PT3M
#
kyuubi.ha.addresses zk1:2181,zk2:2181,zk3:2181
kyuubi.ha.namespace kyuubi

# 不指定 spark就是local模式运行了
spark.master=yarn
spark.submit.deployMode=cluster


kyuubi.authentication=LDAP
kyuubi.authentication.ldap.baseDN=dc=org
kyuubi.authentication.ldap.domain=apache.org
kyuubi.authentication.ldap.binddn=uid=kyuubi,OU=Users,DC=apache,DC=org
kyuubi.authentication.ldap.bindpw=kyuubi123123
kyuubi.authentication.ldap.url=ldap://hostname.com:389/

重启

1
2
3
4
5
注意 :kyuubi 停止的时候   spark on yarn的  kyuubi_application  并没有停掉,   需要在yarn里kill,  这样重启  才能加载新加入的jar包和新的配置文件。

sudo -u hdfs bin/kyuubi start
sudo -u hdfs bin/kyuubi stop
sudo -u hdfs bin/kyuubi restart
阅读全文 »

CDH6.3.2 升级 Spark3.3.0 版本

https://juejin.cn/post/7140053569431928845

根据上面的文档进行部署 还有下列操作需要补充

上传到要部署 spark3 的客户端机器

1
2
3
tar -zxvf spark-3.3.0-bin-3.0.0-cdh6.3.2.tgz -C /opt/cloudera/parcels/CDH/lib
cd /opt/cloudera/parcels/CDH/lib
mv spark-3.3.0-bin-3.0.0-cdh6.3.2/ spark3

配置 conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
shell复制代码cd /opt/cloudera/parcels/CDH/lib/spark3/conf
## 开启日志
mv log4j2.properties.template log4j2.properties
## spark-defaults.conf 配置
cp /opt/cloudera/parcels/CDH/lib/spark/conf/spark-defaults.conf ./

# 修改 spark-defaults.conf
vim /opt/cloudera/parcels/CDH/lib/spark3/conf/spark-defaults.conf
删除 spark.extraListeners、spark.sql.queryExecutionListeners、spark.yarn.jars
添加 spark.yarn.jars=hdfs://ns1/user/spark/3versionJars/*

hadoop fs -mkdir -p /spark/3versionJars
cd /opt/cloudera/parcels/CDH/lib/spark3/jars
hadoop fs -put *.jar hdfs://ns1/user/spark/3versionJars

优化设置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
spark.kryoserializer.buffer.max 512m
spark.serializer org.apache.spark.serializer.KryoSerializer
spark.authenticate false (关闭数据块传输服务SASL加密认证)
spark.io.encryption.enabled false (关闭I/O加密)
spark.network.crypto.enabled false (关闭基于AES算法的RPC加密)
spark.shuffle.service.enabled true (启用外部ShuffleService提高Shuffle稳定性)
spark.shuffle.service.port 7337 (这个外部ShuffleService由YarnNodeManager提供,默认端口7337)
spark.shuffle.useOldFetchProtocol true (兼容旧的Shuffle协议避免报错)
spark.sql.cbo.enabled true (启用CBO基于代价的优化-代替RBO基于规则的优化-Optimizer)
spark.sql.cbo.starSchemaDetection true (星型模型探测,判断列是否是表的主键)
spark.sql.datetime.java8API.enabled false
spark.sql.sources.partitionOverwriteMode dynamic
spark.sql.orc.mergeSchema true (ORC格式Schema加载时从所有数据文件收集)
spark.sql.parquet.mergeSchema false (根据情况设置,我们集群大多数都是parquet,从所有文件收集Schema会影响性能,所以从随机一个Parquet文件收集Schema)
spark.sql.parquet.writeLegacyFormat true (兼容旧集群)
spark.sql.autoBroadcastJoinThreshold 1048576 (当前仅支持运行了ANALYZE TABLE <tableName> COMPUTE STATISTICS noscan的Hive Metastore表,以及直接在数据文件上计算统计信息的基于文件的数据源表)
spark.sql.adaptive.enabled true (Spark AQE[adaptive query execution]启用,AQE的优势:执行计划可动态调整、调整的依据是中间结果的精确统计信息)
spark.sql.adaptive.forceApply false
spark.sql.adaptive.logLevel info
spark.sql.adaptive.advisoryPartitionSizeInBytes 256m (倾斜数据分区拆分,小数据分区合并优化时,建议的分区大小,与spark.sql.adaptive.shuffle.targetPostShuffleInputSize含义相同)
spark.sql.adaptive.coalescePartitions.enabled true (是否开启合并小数据分区默认开启,调优策略之一)
spark.sql.adaptive.coalescePartitions.minPartitionSize 1m (合并后最小的分区大小)
spark.sql.adaptive.coalescePartitions.initialPartitionNum 1024 (合并前的初始分区数)
spark.sql.adaptive.fetchShuffleBlocksInBatch true (是否批量拉取blocks,而不是一个个的去取,给同一个map任务一次性批量拉取blocks可以减少io 提高性能)
spark.sql.adaptive.localShuffleReader.enabled true (不需要Shuffle操作时,使用LocalShuffleReader,例如将SortMergeJoin转为BrocastJoin)
spark.sql.adaptive.skewJoin.enabled true (Spark会通过拆分的方式自动处理Join过程中有数据倾斜的分区)
spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes 128m
spark.sql.adaptive.skewJoin.skewedPartitionFactor 5 (判断倾斜的条件:分区大小大于所有分区大小中位数的5倍,且大于spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes的值)

将 CDH 集群的 spark-env.sh 复制到 /opt/cloudera/parcels/CDH/lib/spark3/conf 下:

阅读全文 »

HiveMetaStore状态不良导DDLSQL耗时200s以上

HMS进程报错:hive metastore server Failed to sync requested HMS notifications up to the event ID xxx

原因分析:查看sentry异常CounterWait源码发现传递的id比currentid大导致一直等待超时,超时时间默认为200s(sentry.notification.sync.timeout.ms)。 开启了hdfs-sentry acl同步后,hdfs,sentry,HMS三者间权限同步的消息处理。当突然大批量的目录权限消息需要处理,后台线程处理不过来,消息积压滞后就会出现这个异常。这个异常不影响集群使用,只是会导致create,drop table慢需要等200s,这样等待也是为了追上最新的id。我们这次同时出现了HMS参与同步消息处理的线程被异常退出,导致sentry的sentry_hms_notification_id表数据一直没更新,需要重启HMS。如果积压了太多消息,让它慢慢消费处理需要的时间太长,可能一直追不上,这时可以选择丢掉这些消息。

解决:

①可以通过设置sentry.notification.sync.timeout.ms参数调小超时时间,减小等待时间,积压不多的话可以让它自行消费处理掉。

②丢掉未处理的消息,在sentry的sentry_hms_notification_id表中插入一条最大值(等于当前消息的id,从notification_sequence表中获取) ,重启sentry服务。(notification_log 表存储了消息日志信息)

1
2
SELECT * from  NOTIFICATION_SEQUENCE
insert into SENTRY_HMS_NOTIFICATION_ID VALUES (14094172);

Hive开启自动获取表上次访问时间(lastAccessTime)

1
2
3
4
5
6
7
8
9
<property>
<name>hive.security.authorization.sqlstd.confwhitelist.append</name>
<value>hive\.exec\.pre\.hooks</value>
</property>

<property>
<name>hive.exec.pre.hooks</name>
<value>org.apache.hadoop.hive.ql.hooks.UpdateInputAccessTimeHook$PreExec</value>
</property>

Spark

阅读全文 »