Automated Pseudo GTID Injection

[vinay jaiswal]

what is default scheduler time for automatic pseudo GTID injection ? 

Is this suffice to configure auto Pseudo GTID 

Added parameter in  "AutoPseudoGTID": true under orchestrator.conf.json file and given grant to privilege on all mysql servers for orchestrator_client with orchserver host  But it does not work .

GRANT DROP ON _pseudo_gtid_.* to 'orc_client'@'orcserverhost';

[Shlomi Noach]

The default interval is the value of `PseudoGTIDIntervalSeconds` in the config file, and if you didn't specify that, it is 5 seconds.

I assume `orchestrator_client` (or is it `orc_client`? which of the two) is the user for the orchestrator *service*, correct?

Can you please `show grants for  'orc_client'@'orcserverhost'` ?

Also, can you please clarify in what way it does not work? What do you expect and what do you see?

--
You received this message because you are subscribed to the Google Groups "orchestrator-mysql" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orchestrator-mysql+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/orchestrator-mysql/fa88d156-8f25-42c9-840e-3819ecaa5677%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[vinay jaiswal]

Thanks Shlomi for your prompt response. 

The default interval is the value of `PseudoGTIDIntervalSeconds` in the config file, and if you didn't specify that, it is 5 seconds. Ok  will add these parameter in config if required custom interval .

I assume `orchestrator_client` (or is it `orc_client`? which of the two) is the user for the orchestrator *service*, correct?

Can you please `show grants for  'orc_client'@'orcserverhost'` ?

GRANT RELOAD, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO 'orc_client_user'@'orchserverhost' 

GRANT DROP ON `_pseudo_gtid_`.* TO 'orc_client_user'@'orchserverhost' 

Also, can you please clarify in what way it does not work? What do you expect and what do you see?

Not getting dumped  unique pseudo gtid in binlog like pseudo_gtid_hint__7a4e6ead-1240-11e8-a66f-02c124c99ec0` while if i configure manually using meta schema and event scheduler then getting unique pseudo gtid in binlog . 

[Shlomi Noach]

Can you please paste the output of the following:

$ orchestrator -c topology -alias <youralias>

or

$ orchestrator -c topology -i your.master.com

$ orchestrator -c last-pseudo-gtid -i your.master.com

on the orchestrator backend DB:

mysql> select *, now() from cluster_injected_pseudo_gtid;

and please indicate which server is your master? (If you need to redact actual production hostnames, please redact them consistently)

--
You received this message because you are subscribed to the Google Groups "orchestrator-mysql" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orchestrator-mysql+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/orchestrator-mysql/d133719e-12c5-487f-91fb-3e2a933ca3c0%40googlegroups.com.

[Shlomi Noach]

Also, please do all of the above while orchestrator service is running.

On Mon, Feb 19, 2018 at 7:59 PM, Shlomi Noach <shlomi...@gmail.com> wrote:

Can you please paste the output of the following:

$ orchestrator -c topology -alias <youralias>

or

$ orchestrator -c topology -i your.master.com

$ orchestrator -c last-pseudo-gtid -i your.master.com

on the orchestrator backend DB:

mysql> select *, now() from cluster_injected_pseudo_gtid;

and please indicate which server is your master? (If you need to redact actual production hostnames, please redact them consistently)

On Mon, Feb 19, 2018 at 7:23 PM, vinay jaiswal <jaiswa...@gmail.com> wrote:

Thanks Shlomi for your prompt response. 

The default interval is the value of `PseudoGTIDIntervalSeconds` in the config file, and if you didn't specify that, it is 5 seconds. Ok  will add these parameter in config if required custom interval .

I assume `orchestrator_client` (or is it `orc_client`? which of the two) is the user for the orchestrator *service*, correct?

Can you please `show grants for  'orc_client'@'orcserverhost'` ?

GRANT RELOAD, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO 'orc_client_user'@'orchserverhost' 

GRANT DROP ON `_pseudo_gtid_`.* TO 'orc_client_user'@'orchserverhost' 

Also, can you please clarify in what way it does not work? What do you expect and what do you see?

Not getting dumped  unique pseudo gtid in binlog like pseudo_gtid_hint__7a4e6ead-1240-11e8-a66f-02c124c99ec0` while if i configure manually using meta schema and event scheduler then getting unique pseudo gtid in binlog . 

--
You received this message because you are subscribed to the Google Groups "orchestrator-mysql" group.

To unsubscribe from this group and stop receiving emails from it, send an email to orchestrator-mysql+unsubscribe@googlegroups.com.

[matthe...@percona.com]

I'm going to jump in here because AutoPseudoGTID is not working for me either. The binary logs on my master do not contain any PGTID events.

mysql3> show grants for 'orchestrator'@'192.168.70.200';

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

| Grants for orches...@192.168.70.200                                                    |

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

| GRANT RELOAD, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO 'orchestrator'@'192.168.70.200' |

| GRANT SELECT ON `mysql`.`slave_master_info` TO 'orchestrator'@'192.168.70.200'            |

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

2 rows in set (0.00 sec)

[root@manager orchestrator]# ./orchestrator -c topology

2018-11-09 15:35:43 DEBUG Connected to orchestrator backend: sqlite on /usr/local/orchestrator/orchestrator.sqlite3

2018-11-09 15:35:43 DEBUG Initializing orchestrator

2018-11-09 15:35:43 INFO Connecting to backend :3306: maxConnections: 128, maxIdleConns: 32

2018-11-09 15:35:43 DEBUG instanceKey: mysql1:3306

2018-11-09 15:35:43 DEBUG instanceKey: mysql2:3306

2018-11-09 15:35:43 DEBUG instanceKey: mysql3:3306

mysql3:3306   [0s,ok,5.7.23-23-log,rw,ROW]

+ mysql1:3306 [0s,ok,5.7.23-23-log,ro,ROW]

+ mysql2:3306 [0s,ok,5.7.23-23-log,ro,ROW]

[root@manager orchestrator]# ./orchestrator -c last-pseudo-gtid -i mysql3

2018-11-09 15:36:07 DEBUG Hostname unresolved yet: mysql3

2018-11-09 15:36:07 DEBUG Cache hostname resolve mysql3 as mysql3

2018-11-09 15:36:07 DEBUG Connected to orchestrator backend: sqlite on /usr/local/orchestrator/orchestrator.sqlite3

2018-11-09 15:36:07 DEBUG Initializing orchestrator

2018-11-09 15:36:07 INFO Connecting to backend :3306: maxConnections: 128, maxIdleConns: 32

2018-11-09 15:36:07 DEBUG Hostname unresolved yet: mysql1

2018-11-09 15:36:07 DEBUG Cache hostname resolve mysql1 as mysql1

2018-11-09 15:36:07 DEBUG Hostname unresolved yet: mysql2

2018-11-09 15:36:07 DEBUG Cache hostname resolve mysql2 as mysql2

2018-11-09 15:36:07 DEBUG PseudoGTIDPatternIsFixedSubstring: true

2018-11-09 15:36:07 DEBUG Searching for latest pseudo gtid entry in relaylog  of mysql3:3306, up to pos :0

2018-11-09 15:36:07 ERROR getLastPseudoGTIDEntryInBinlog: empty binlog file name for mysql3:3306. maxCoordinates = :0

2018-11-09 15:36:07 FATAL 2018-11-09 15:36:07 ERROR getLastPseudoGTIDEntryInBinlog: empty binlog file name for mysql3:3306. maxCoordinates = :0

[matthe...@percona.com]

Found my answer. I had not granted privs to DROP PGTID views. Once I did that, I started seeing the events in binlog. Sure with Orc would have printed some ERROR messages about "Permissions Denied to DROP VIEW" or something instead of being completely silent.

-Matthew

On Monday, February 19, 2018 at 10:21:23 AM UTC-6, vinay jaiswal wrote: