主页 / server / 问题

问题[galera](server)

Martin Hope
TarabydaVllasıCafcaflıAtArabsı
Asked: 2021-04-07 03:27:46 +0800 CST
  • 0

我在我的数据库服务器上打开了 UFW，我看到了很多 UFW_BLOCK 日志。对所有被阻止的 IP 地址使用“ufw allow from xx.xx.xx.xx”和“ufw allow to xx.xx.xx.xx”命令是否安全或正确？我允许在 iptables 上使用端口 112 阻止 IP 地址，但我很困惑哪个是最佳做法？

ubuntu-20.04 ufw mariadb galera
Martin Hope
Niko
Asked: 2021-03-11 03:44:37 +0800 CST
  • 0

内联解决方案

我们遇到了一个奇怪的问题，现在基本上没有想法：

我们为客户设置了一个 galera 集群（3 个节点 + MaxScale LB），他报告速度很慢。我们无法确定问题，因此我们设置了一个测试场景以深入挖掘：

  • 我们将完整的集群 + 应用程序服务器克隆到一个单独的子网中，以防止当前用户的任何干扰
  • 我们设法重现了缓慢：操作大约 10 秒
  • 为了减少变量，我们在其中一个集群节点上安装了应用程序，以允许我们使用 db 连接到 localhost 进行测试

经过广泛的测试、调整和研究，我们决定在 VmWare ESX 上尝试相同的设置。所以我们将集群+应用程序迁移到 ESX 并进行了完全相同的测试 - 结果很奇怪......

从那里我们做了以下测试：

测试 结果 HyperV 结果 ESX
应用程序 -> 负载均衡器 10s 6s
应用程序 -> 直接数据库（本地主机） 6.5s 3,6s
App -> Direct DB（其他节点） 9s 5s
应用程序->本地主机；没有集群 1.5s 1.3s
应用程序 (HyperV) -> LB (ESX) 13s

我们尝试的结果没有任何实际变化：

  • 将所有集群节点移动到相同的硬件上
  • 在循环和读写拆分之间切换 maxscale
  • 应用各种 mariadb/galera 设置
  • 在 hyperV 中应用了各种设置
    • VMQ 设置1 2
    • SET 虚拟交换机
    • 巨型帧
    • 我们添加了物理网卡而不是绑定
    • 激活内部交换机而不是使用 NIC
    • 安装了所有最新的补丁和更新的网卡驱动程序
    • 安装 linux-cloud-tools 和 linux-azure 内核

以下设置：

  • HyperV Windows 服务器 2019
  • Ubuntu 20.04 上的 MariaDb
  • 全闪存高清
  • 16GB 光纤通道
  • 间网卡
  • 主机（实际上是虚拟机）上的负载可以忽略不计

我们完全被难住了，因为我们无法解释为什么 hyperV 和 ESX 之间的时序差异如此之大。我们认为它一定是网络 IO，但无法确定哪个设置有问题。

从数字/测试中，我们可以断定哪些部分没有故障：

  • HD/IO：因为每次添加“网络”节点时性能都会急剧下降
  • CPU：这些数字是可重现的，我们在没有任何其他负载的虚拟机上进行了测试
  • 慢速数据库查询：因为数字会根据我们是直接连接到集群节点之一还是使用本地主机而改变 - 可以排除

任何人都可以给我们指点，我们可以尝试什么或如何加速hyperv？还是我们搞砸了一些 galera/maxscale 设置？

编辑：我们检查了坏段并发现（netstat -s | grep 段）：

超级V ESX
已收到 2448010940 2551382424
发送 5502198473 2576919172
重传 9054212 7070
坏段 83 0
% 重传 0.16% 0.00027%

解决方案

多亏了 Mircea 的投入，我们终于在 hyperV 上获得了大幅下降的数字。

以下配置更改有帮助：

  • 释放默认 Windows 绑定
  • 激活 SET 团队
  • 在 SET 团队上激活：RDMA 和巨型帧

有了这个，hyperV 上的数字基本上等同于 ESX

hyper-v galera
Martin Hope
LubieCiastka
Asked: 2020-04-28 08:36:22 +0800 CST
  • 1

简而言之，我有一个由 3 个节点组成的 MariaDB Galera 集群。
我有 3 台运行 MaxScale 的独立服务器。

将三个独立的 MaxScale 实例连接到单个数据库集群有什么缺点吗？
在配置过程中我应该注意什么吗？

我现在不是在问 HA，我的意思是 3 个独立的 MaxScale 实例。

我正在寻找文档，但没有找到任何具体的内容。

cluster mariadb galera
Martin Hope
Ror
Asked: 2020-04-07 00:30:29 +0800 CST
  • 0

我在 MariaDB 服务器上有一个数据库，我需要将它复制到其他机器上的 Galera 集群上。我使用 HeidiSQL 创建了一个实际上非常快的转储文件。数据库大约500Mb。但是，当我尝试在另一台服务器上导入它（仍然使用 HeidiSQL）时，大约需要 8 个小时才能完成。我也尝试在经典的 MariaDB 服务器上导入它，同样的问题。

有没有办法减少导入时间？

debian database mariadb galera
Martin Hope
georgealton
Asked: 2016-10-13 08:31:43 +0800 CST
  • 1

我正在使用多机 VagrantFile 在 Vagrant 下配置 Galera MySQL 集群。

我认为问题不在于 Vagrant

流浪版

流浪者版本 1.8.6

流浪文件

Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/trusty64"

  config.vm.provider "virtualbox" do |vb|
     vb.memory = "2048"
  end

  config.ssh.forward_agent = true

  if Vagrant.has_plugin?("vagrant-cachier")
    config.cache.scope = :box
    config.cache.enable :apt
  end

  config.vm.define "core0" do |core0|
      core0.vm.network "private_network", ip: "192.168.50.3"
      core0.vm.hostname = "core0"
      core0.vm.provision :hosts, :sync_hosts => true
      core0.vm.provision "shell", inline: <<-SHELL
          sudo python /vagrant/bootstrap.pex --core-nodes core0 core1 core2 --node-zero
      SHELL
  end

  config.vm.define "core1" do |core1|
      core1.vm.network "private_network", ip: "192.168.50.4"
      core1.vm.hostname = "core1"
      core1.vm.provision :hosts, :sync_hosts => true
      core1.vm.provision "shell", inline: <<-SHELL
          sudo python /vagrant/bootstrap.pex --master core0 --core
      SHELL
  end

  config.vm.define "core2" do |core2|
      core2.vm.network "private_network", ip: "192.168.50.5"
      core2.vm.hostname = "core2"
      core2.vm.provision :hosts, :sync_hosts => true
      core2.vm.provision "shell", inline: <<-SHELL
          sudo python /vagrant/bootstrap.pex --master core0 --core
      SHELL
  end

end

流浪插件

我在流浪者中使用vagrant-cachierand 。vagrant-hostsVagrant 依次运行并创建每个 VM，然后我进行 2 阶段配置以确保在尝试集群之前建立盒子之间的网络。

vagrant up --provision-with hosts && vagrant provision --provision-with shell

shell 配置器使用 salt 来创建和安装 mariadb 和 gluster

Mariadb 版本

vagrant@core0:~$ sudo apt-cache policy mariadb-server-core-10.1 
mariadb-server-core-10.1:
  Installed: 10.1.18+maria-1~trusty
  Candidate: 10.1.18+maria-1~trusty

vagrant@core0:~$ sudo apt-cache policy galera-3       
    galera-3:
      Installed: 25.3.18-trusty
      Candidate: 25.3.18-trusty

我将集群地址配置为 galera.cnf

wsrep_cluster_address = gcomm://core2,core0,core1

当主机core1并core2尝试加入core0他们无法加入时。

core1 加入集群

core1 能够找到 core0 并检索当前集群状态。

Oct 12 15:15:02 core1 mysqld: 2016-10-12 15:15:02 140403237877696 [Note] WSREP: gcomm: connecting to group 'TestSystem', peer 'core2:,core0:,core1:'
Oct 12 15:15:02 core1 mysqld: 2016-10-12 15:15:02 140403237877696 [Note] WSREP: (a61950db, 'tcp://0.0.0.0:4567') connection established to a61950db tcp://127.0.0.1:4567
Oct 12 15:15:02 core1 mysqld: 2016-10-12 15:15:02 140403237877696 [Note] WSREP: (a61950db, 'tcp://0.0.0.0:4567') connection established to a61950db tcp://127.0.1.1:4567
Oct 12 15:15:02 core1 mysqld: 2016-10-12 15:15:02 140403237877696 [Warning] WSREP: (a61950db, 'tcp://0.0.0.0:4567') address 'tcp://127.0.1.1:4567' points to own listening address, blacklisting
Oct 12 15:15:02 core1 mysqld: 2016-10-12 15:15:02 140403237877696 [Note] WSREP: (a61950db, 'tcp://0.0.0.0:4567') connection established to a5301480 tcp://192.168.50.3:4567
Oct 12 15:15:02 core1 mysqld: 2016-10-12 15:15:02 140403237877696 [Note] WSREP: (a61950db, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: 
Oct 12 15:15:03 core1 mysqld: 2016-10-12 15:15:03 140403237877696 [Note] WSREP: declaring a5301480 at tcp://192.168.50.3:4567 stable
Oct 12 15:15:03 core1 mysqld: 2016-10-12 15:15:03 140403237877696 [Note] WSREP: Node a5301480 state prim

核心2不可用

正如预期的那样，此时 core2 不可用

Oct 12 15:15:03 core1 mysqld: 2016-10-12 15:15:03 140403237877696 [Note] WSREP: discarding pending addr without UUID: tcp://192.168.50.5:4567
Oct 12 15:15:03 core1 mysqld: 2016-10-12 15:15:03 140403237877696 [Note] WSREP: gcomm: connected

SST 失败

core1 尝试使用10.0.2.15Vagrant NAT 地址连接到 core0

Oct 12 15:15:03 core1 mysqld: 2016-10-12 15:15:03 140403237563136 [Note] WSREP: State transfer required: 
Oct 12 15:15:03 core1 mysqld: #011Group state: a530f9fd-908d-11e6-a72a-b2e3a6b91029:1113
Oct 12 15:15:03 core1 mysqld: #011Local state: 00000000-0000-0000-0000-000000000000:-1
Oct 12 15:15:03 core1 mysqld: 2016-10-12 15:15:03 140403237563136 [Note] WSREP: New cluster view: global state: a530f9fd-908d-11e6-a72a-b2e3a6b91029:1113, view# 2: Primary, number of nodes: 2, my index: 1, protocol version 3
Oct 12 15:15:03 core1 mysqld: 2016-10-12 15:15:03 140403237563136 [Warning] WSREP: Gap in state sequence. Need state transfer.
Oct 12 15:15:03 core1 mysqld: 2016-10-12 15:15:03 140402002753280 [Note] WSREP: Running: 'wsrep_sst_xtrabackup-v2 --role 'joiner' --address '10.0.2.15' --datadir '/var/lib/mysql/'   --parent '9043' --binlog '/var/log/mariadb_bin/mariadb-bin' '
Oct 12 15:15:03 core1 mysqld: WSREP_SST: [INFO] Logging all stderr of SST/Innobackupex to syslog (20161012 15:15:03.985)
Oct 12 15:15:03 core1 -wsrep-sst-joiner: Streaming with xbstream
Oct 12 15:15:03 core1 -wsrep-sst-joiner: Using socat as streamer
Oct 12 15:15:04 core1 -wsrep-sst-joiner: Evaluating timeout -k 110 100 socat -u TCP-LISTEN:4444,reuseaddr stdio | xbstream -x; RC=( ${PIPESTATUS[@]} )
Oct 12 15:15:04 core1 mysqld: 2016-10-12 15:15:04 140403237563136 [Note] WSREP: Prepared SST request: xtrabackup-v2|10.0.2.15:4444/xtrabackup_sst//1
Oct 12 15:15:04 core1 mysqld: 2016-10-12 15:15:04 140403237563136 [Note] WSREP: REPL Protocols: 7 (3, 2)
Oct 12 15:15:04 core1 mysqld: 2016-10-12 15:15:04 140402075592448 [Note] WSREP: Service thread queue flushed.
Oct 12 15:15:04 core1 mysqld: 2016-10-12 15:15:04 140403237563136 [Note] WSREP: Assign initial position for certification: 1113, protocol version: 3
Oct 12 15:15:04 core1 mysqld: 2016-10-12 15:15:04 140402075592448 [Note] WSREP: Service thread queue flushed.
Oct 12 15:15:04 core1 mysqld: 2016-10-12 15:15:04 140403237563136 [Warning] WSREP: Failed to prepare for incremental state transfer: Local state UUID (00000000-0000-0000-0000-000000000000) does not match group state UUID (a530f9fd-908d-11e6-a72a-b2e3a6b91029): 1 (Operation not permitted)
Oct 12 15:15:04 core1 mysqld: #011 at galera/src/replicator_str.cpp:prepare_for_IST():482. IST will be unavailable.
Oct 12 15:15:04 core1 mysqld: 2016-10-12 15:15:04 140402019526400 [Note] WSREP: Member 1.0 (core1) requested state transfer from '*any*'. Selected 0.0 (core0)(SYNCED) as donor.
Oct 12 15:15:04 core1 mysqld: 2016-10-12 15:15:04 140402019526400 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 1113)
Oct 12 15:15:04 core1 mysqld: 2016-10-12 15:15:04 140403237563136 [Note] WSREP: Requesting state transfer: success, donor: 0
Oct 12 15:15:04 core1 mysqld: 2016-10-12 15:15:04 140402019526400 [Warning] WSREP: 0.0 (core0): State transfer to 1.0 (core1) failed: -32 (Broken pipe)
Oct 12 15:15:04 core1 mysqld: 2016-10-12 15:15:04 140402019526400 [ERROR] WSREP: gcs/src/gcs_group.cpp:gcs_group_handle_join_msg():736: Will never receive state. Need to abort.

core0 上的 wsrep 状态

在 core0 上登录 mysql 并运行

SHOW GLOBAL STATUS LIKE 'wsrep_%'


+------------------------------+--------------------------------------+
| Variable_name                | Value                                |
+------------------------------+--------------------------------------+
...
| wsrep_cluster_state_uuid     | a530f9fd-908d-11e6-a72a-b2e3a6b91029 |
| wsrep_cluster_status         | Primary                              |
| wsrep_gcomm_uuid             | a5301480-908d-11e6-a84e-0b2444c3985f |
| wsrep_incoming_addresses     | 10.0.2.15:3306                       |
| wsrep_local_state            | 4                                    |
| wsrep_local_state_comment    | Synced                               |
| wsrep_local_state_uuid       | a530f9fd-908d-11e6-a72a-b2e3a6b91029 |
...
+------------------------------+--------------------------------------+

因此，core0 似乎将其 wsrep 传入地址宣传为10.0.2.15:3306，这不是我期望的地址 - 192.168.0.3:3306。

在 core0 上的 ifconfig

这显示了 eth0 上的 NAT

vagrant@core0:~$ ifconfig 
eth0      Link encap:Ethernet  HWaddr 08:00:27:de:04:89  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fede:489/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:218886 errors:0 dropped:0 overruns:0 frame:0
          TX packets:81596 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:205966097 (205.9 MB)  TX bytes:6015101 (6.0 MB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:bc:f7:ee  
          inet addr:192.168.50.3  Bcast:192.168.50.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:febc:f7ee/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:261637 errors:0 dropped:0 overruns:0 frame:0
          TX packets:244284 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:59467905 (59.4 MB)  TX bytes:114065906 (114.0 MB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:246320 errors:0 dropped:0 overruns:0 frame:0
          TX packets:246320 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:64552545 (64.5 MB)  TX bytes:64552545 (64.5 MB)

如何/为什么将地址设置为此？有没有办法让地址成为正确的地址？

更新

如何设置 wsrep_incoming_addresses

虽然 wsrep_cluster_address 必须在节点开始时指定，但 wsrep_incoming_addresses 是在初始化期间内部确定的。在 linux 操作系统上，用于确定 IP 地址的命令从接口列表中选择第一个可用的全局 IP 地址。

ip addr show | grep '^\s*inet' | grep -m1 global | awk '
{print $2 }
' | sed 's/\/.*//'

https://mariadb.atlassian.net/browse/MDEV-5487

我的输出

vagrant@core0:~$ ip addr show | grep '^\s*inet' | grep -m1 global | awk '
> {print $2 }
> ' | sed 's/\/.*//'
10.0.2.15
vagrant mariadb galera xtrabackup
Martin Hope
karthik v
Asked: 2016-09-20 11:10:33 +0800 CST
  • 1

我的 HAProxy 正在运行VIP:192.168.61.32，我也检查过netstat -tulnp|grep 3306

 tcp    0    0   192.168.61.32:3306    0.0.0.0:*  LISTEN      7895/haproxy

但是当我跑步时

mysql -h 192.168.61.32 -u root -p:

ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0

192.168.61.30 & 192.168.61.31当我尝试连接到数据库时，HA 代理节点位于&

root@haproxy1:~# mysql -h 192.168.61.30 -u root -p
Enter password: 
ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.61.30' (111)
root@haproxy1:~# mysql -h 192.168.61.31 -u root -p
Enter password: 
ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.61.31' (111)

我的后端 Mysql 节点位于192.168.61.33 & 192.168.61.34,我可以使用直接连接到它们

mysql -h 192.168.61.33 -u root -p

mysql -h 192.168.61.34 -u root -p

haproxy.conf的配置细节：

global
        log /dev/log    local0
#       log /dev/log    local1 notice
        chroot /var/lib/haproxy
        user haproxy
        group haproxy
        daemon
        log 192.168.61.31 local0
        stats socket /var/lib/haproxy/stats
        maxconn 4000

defaults
        log     global
#       mode    http
#       option  httplog
        option  dontlognull
        contimeout 5000
        clitimeout 50000
        srvtimeout 50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

listen stats 192.168.61.31:80
        mode http
        option  httplog
        stats enable
        stats uri /stats
        stats realm HAProxy\ Statistics
        stats auth admin:admin

listen galera 192.168.61.32:3306
               balance source
               mode tcp
               option tcpka
               option mysql-check user haproxy
               server mysql1 192.168.61.33:3306 check weight 1
               server mysql2 192.168.61.34:3306 check weight 1

这就是我在第二个 HA-Proxy 服务器中的 haproxy.conf 的配置，第一个 HA-Proxy 服务器配置是相同的，除了global & stats 部分中的 Ip 地址是 192.168.61.30 [First HA-Proxy Server]

mysql haproxy mariadb keepalived galera