When performing a dump to setup a slave, I'm currently using
mariadb-dump --gtid --opt --apply-slave-statements --all-databases --flush-logs --master-data
But I don't seem to see a way to specify the "connection-name", so it is generating
CHANGE MASTER TO MASTER_USE_GTID=slave_pos;
Instead of the wanted
CHANGE MASTER "connection-name" TO MASTER_USE_GTID=slave_pos;
Related
I'm trying to make DB read-only for MariaDB, but it is not working correctly until we restart the service (Spring Boot application). The service keeps writing the data until we restart.
How can we make DB read-only so that it immediately stops writing regardless of service restart?
I tried commands:
1.
FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = 1;
FLUSH TABLES WITH READ LOCK;
None of the above fulfills the requirement. Please suggest if there's a different approach to do that.
We are using MariaDB v10.5.15 and clustering of Galera-4 v26.4.11.
The cluster is in the weighted quorum mode so that the primary site has more votes than the non-primary. During a network outage, the primary site with more votes prevails and continues service without the other peer.
The system needs to undergo a regular disaster recovery examination, including switching the primary site to the other peer. So, we need to change the weight assignments for the design reasons explained above.
Within MySQL client, we can set pc.weight dynamically by command like set global wsrep_provider_options="pc.weight=2";. However, this command only changes the in-memory configuration. So, if reboot the host, the MariaDB will start again with the old value written in the configuration file /etc/my.cnf.d/server.cnf.
To make the new weights non-volatile, we need to edit the below part of the configuration file. And the edit is error-prone because the file contains many other items in the same line of wsrep_provider_options, with pc.weight in the middle.
[galera]
...
wsrep_provider_options="socket.ssl=true; socket.ssl_key=/etc/pki/galera/server-key.pem; socket.ssl_cert=/etc/pki/galera/server-cert.pem; socket.ssl_ca=/etc/pki/galera/ca-cert.pem; pc.weight=2"
...
I am wondering:
Is it possible to set the pc.weight non-volatile without editing the configuration files?
Otherwise, is it possible to separate pc.weight into another .cnf file while keeping the other items of wsrep_provider_options in the original file?
We highly appreciate your help and suggestions.
No pc.weight cannot be non-volatile without editing a configuration file.
If you put it into another configuration file and start the server with --defaults-extra-file=/path/to/other/file.cnf that would pick it up.
Another option is to start another node, even an arbitrator node, on the secondary site during DR/DR testing. That node might need more than a 2 weight.
How does the primary site know the weight of a node it hadn't seen? I'm not sure. So be careful.
I have a number of files that I need to transfer to specific minion hosts in a secure manner, and I would like to automate that process using Salt. However, I am having trouble figuring out the best means of implementing a host restricted transfer.
The salt fileserver works great for non-host-specific transfers. However, some of the files that I need to transfer are customer specific and so I need to ensure that they are only accessible from specific hosts. Assumedly Pillar would be the ideal candidate for minion specific restrictions, but I am having trouble figuring out a means of specifying file transfers using pillar as the source.
As far as I can tell Pillar only supports SLS based dictionary data, not file transfers. I’ve tried various combinations of file.managed state specifications with paths constructed using various convolutions (including salt://_pillar/xxx), but thus far I have not been able to access anything other than token data defined within an SLS file.
Any suggestions for how to do this? I am assuming that secure file transfers should be a common enough need that there should be a standard means of doing it, as opposed to writing a custom function.
The answer depends on what exactly you're trying to secure. If only a part of the files involved are "sensitive" (for example, passwords in configuration files), you probably want to use a template that pulls the sensitive parts in from pillar:
# /srv/salt/app/files/app.conf.jinja
[global]
user = {{ salt['pillar.get']("app:user") }}
password = {{ salt['pillar.get']("app:password") }}
# ...and so on
For this case you don't need to care if the template itself is accessible to minions.
If the entire file(s) involved are sensitive, then I think you want to set up the file_tree external pillar, and use file.managed with the contents_pillar option. That's not something I've worked with, so I don't have a good example.
Solution Synopsis: Using PILLAR.FILE_TREE
A: On your master, set-up a directory from which you will server the private files (e.g: /srv/salt/private).
B: Beneath that create a “hosts” subdirectory, and then beneath that create a directory for each of the hosts that will have private files.
/srv/salt/private/hosts/hostA
/srv/salt/private/hosts/hostB
… where hostA and hostB are the ids of the target minions.
See the docs if you want to use node-groups instead of host ids.
C: Beneath the host dirs, include any files you want to transfer via pillar.
echo “I am Foo\!” > /srv/salt/private/hosts/hostA/testme
D: In your master config file (e.g: /etc/salt/master), include the following stanza:
ext_pillar:
- file_tree:
root_dir: /srv/salt/private
follow_dir_links: False
keep_newline: True
debug: True
E: Create a salt state file to handle the transfer.
cat > /srv/salt/files/base/foo.sls << END
/tmp/pt_test:
file.managed:
- contents_pillar: testme
END
F: Run pillar refresh, and then run your state command:
salt hostA state.apply foo
Following the last step, hostA should have a file named /tmp/pt_test that contains the text “I am Foo!”.
I am newbie to the beats. I am using topbeat to monitor the system health.
Up to this point everything is fine.
Now I need to monitor the resource utilization of a java process, so I configured topbeat.yml as: procs: ["java"]
In my linux box there are 4 java processes are running but I am interested in only one java process. So,
Is there any way to monitor specific java process using regex?
Is there any way to differentiate the processes by name [not with pid]?
If you wish to view certain processes then you can use sample topbeat dashboards and in that dashboard there is one search which is for proc stats. From there select proc.name from the available fields and further filter it to select your relevant proc.name
Suggestion from elastic forum: https://discuss.elastic.co/t/topbeat-monitor-specific-java-process/65594/2 Try MetricBeat and see if it helps.
We have increased the -n parameter in broker/db.pf file.We restarted the server and when we check in promon its still showing the same number of users. How do we increase the -n parameter?
I know you answered this yourselves but for future users a real answer can be good. There are several ways to set parameters like -n. This answer really applies to changing all startup parameters (but not what values are "good").
How you change this value depends on how you start your database. See below.
NB 1: you should be aware of your licensing plan before changing this number and contact your sales contact if needed.
NB 2: you should be aware that changing startup parameters can affect performance etc. Test new values in a separate environment before moving them to production.
NB 3: backup all files before messing around...
Managed Database
A managed database is a database that is handled by the AdminServer. OE Management is not needed for this approach. A working installation of OE Explorer is however recommended.
The managed database is started (and stopped etc) via either the web based OE Explorer interface or the dbman command line utility.
Settings are stored in conmgr.properties under your Progress installation. You can edit this file manually (save a copy first...) or via the OE Explorer (recommended way).
You will have a line like this in the file:
maxusers=20 # -n
Edit the number to your liking with your favourite editor.
You can also change this in the OE Explorer:
Log in to OE Explorer. Default location is http://servername:9090/.
Locate and click on the database (if it's not there it's not handled by the adminserver - see below).
Select Configuration
Select Configuration (again, not "servergroup")
Click EDIT
-n (or Max users) is located in the first group of settings ("General"). See picture below.
Edit the value and don't forget to save.
Scripted Database
A scripted database is a database that started with a custom script (or also directly from command line). The actual startup could be handled by crontab, a user, the server generic startup script etc.
The OE AdminServer is not "aware" of this database. (You can make the AdminServer "a little" aware of it by running the dbagent command line utility with certain parameters. Read more about this in the manual).
You could generally divide into two ways of handling the script: with parameters in it or with parameters in a separate parameter file (often with the extension .pf).
Script with parameters in it
With this approach you store all parameters in the actual startup script.
proserve <dbname> -H <hostname> -S <serviceport> -n 10 -B 10000 -spin 10000 etc..
Script with a separate parameter file
With this approach you store the parameters in a separate file.
proserve <dbname> -pf /path/to/file/file.pf
The .pf-file can be formatted like the parameters in the command line:
-db <dbname> -H <hostname> -S <service> etc.
Or with newlines (this allows for comments in the file):
# Main database
-db <dbname>
-H <hostname>
-S <service>
You can also mix these two approaches.
Sources:
OE Management and OE Explorer
OE Database Management